I haven't used Linux on a desktop/laptop in a decade so it's sad to hear that things are still the same.
This is why I have been using System76 personally for the last 5 years, since I first found out about them when given one by an employer. The first linux box I have had that didn't have little problems like that.
Disclaimer: not affiliated in any way, just a happy customer for work and play.
My personal ThinkPad E495 has pretty much flawless driver support.
Granted, I'm running different distros (Ubuntu on the Dell, Solus on the ThinkPad) but the fact that the Dell Precision is certified specifically for Ubuntu is pretty disappointing.
In general, Linux runs really well if you filter hardware a bit ahead of purchase. For example, an all Intel machine with Intel wireless card will rarely give any trouble.
That being said, after each reboot I do need to put the machine to sleep using the power button once. After that the sleep/wake works perfectly just by closing/opening the lid. It's a minor inconvenience and I'm actually kind of loving the thing!
Edit: yes, it's a model you can buy with Ubuntu pre-installed.
(If someone knows which log file will tell me the exact reason behind a mystery wakeup after it happens, please share!)
https://www.kernel.org/doc/Documentation/acpi/debug.txt
I'm not exactly sure what options you'd need to enable/disable to just catch useful info.
Hopefully you don't need to enable everything, which may produce enough (realtime) logspam to make journald use a noticeable amount of CPU.
* bricks, but can be restarted if one opens the case and resets the BIOS.
Had a Dell XPS before that, it was way worse on the same issue. With MacBooks, I didn't have that issue as much with personal machines, but I mostly used them for travel. I've had pretty bad issues with work MacBooks.
Love my System 76, but there's still work to be done there.
Have you ever gotten the native HDMI port to work in linux?
oh wow, okay I'll definitely try that haha
> Have you ever gotten the native HDMI port to work in linux?
Yes, with the nvidia drivers it works fine
The parent commenter just has higher standards than you: either that software and hardware are relatively easily decoupled and should be, or that laptop manufacturers should competently implement the standards they claim to, or even just that he's never worked at a company whose product was as poorly-made as almost every laptop's compatibility software.
Good sleep on windows has only returned recently.
After years of great sleep on Windows 7, there have been massive changes following the introduction of ACPI S0.
Case in point: I got a nice laptop for classes like 4 years ago and it did NOT implement either S3 or S4 mode, which caused a MASSIVE problem in Linux. I found out about the issue on mailing list: the bios simply didn't implement at all this part of ACPI, instead of exposing the hooks based on the OS detection. It was to reduce problems in theory, but it brought many more in practice.
Connected standby (S0idle) was very flaky on Windows 10, and very often the laptop would eat the battery overnight instead of going to sleep.
I'm not sure if there are direct lessons there for Linux driver handling as Microsoft has huge test labs that do forward these sorts of event logs to the hardware manufacturers and is in a position to expect at least some of them to do better next time (either next driver update or next hardware refresh).
Macs have always nailed it. When I worked at a computer store like 15 years ago, people would bring in their Macs, open up the lid and it would wake instantly after being asleep in someone's bag for 2 weeks and still have a 90% charge. Any Windows PC in that era would have run until it overheated and melted, or ran out of battery, whichever happened first.
My desktop (custom built) refuses to go to sleep when I'm booted into Linux. Straight up just wakes itself immediately.
Over in Windows land I've had this issue on a regular basis with a Thinkpad that keeps waking itself up. I've had this issue occasionally on a Surface Book 2, I suspect due to a finicky monitor attached to the dock. I've had this issue pretty much never on a first gen Surface Book attached to the same dock. Go figure.
It's probably a device that it's waking the computer up. In my case it was a mouse. See https://news.ycombinator.com/item?id=25389048 for a solution.
If I select the sleep option in the start menu it probably won't wake back up and I'll have to unplug it for about 10 minutes to get it to boot again.
Previous causes have been sound drivers, chrome, steam, joysticks, some unknown that an update fixes.
They had no idea what happened or how to fix it.
I doubt this is true. Windows = computing for a good over 80% of humanity. Not markets, not regions. Humanity.
If the OP does some internet research into this topic they will find articles detailing how almost all [1] non-apple laptop makers build to a single target: ms-windows. They also test against a single target: ms-windows. If it works there, they are done. Linux compatibility is not even an afterthought.
And as each makers various models all seem to also have slightly different ways to perform sleep/hibernate and subsequent wakeup, the result is that Linux kernel dev's are playing a continuous game of catch-up. One thing I've found is that upgrading the kernel to a later release sometimes fixes the issues (assuming patches were supplied by someone in the interim to fix them).
[1] Very few makers have any laptops that ship, from the maker, with Linux preinstalled, the few that do (one or two Dell models, the aftermarket "Linux Laptop" vendors, maybe a sliver of others) will more than likely work properly for sleep/wake. The reason why these work better is because the maker should, in theory, test for Linux compatibility and help fix any bugs (or simply build with compatible chipsets from the outset) since they are selling these with "Linux pre-loaded".
But as a user, you do have to pick your hardware.
My ThinkPad X240 has been suspending and resuming reliably for the majority of the last 6 to 7 years. There was a time when the touchpad didn't work after resume without tweaking (in Fedora), which was annoying and surprising and something that IMO shouldn't have happened. But other than that there have been no issues.
See https://starlabs.systems/ and https://starlabs.kb.help/compatibility-reports/
Curiously enough, some of my colleagues which have the same laptop model running Windows, complain that their laptops only wake up about 50% of the time, ever since we had a mandatory upgrade to Windows 10.
Lenovo also certifies ThinkPads for Linux:
https://support.lenovo.com/us/en/solutions/pd031426-linux-fo...
Newer (?) ThinkPads even have a firmware option to switch between the default sleep state and one that is more compatible with Linux.
https://brauner.github.io/2018/09/08/thinkpad-6en-s3.html
I recently bought a T14, which also has this option.
(It enables S3 sleep.)
S0ix is the new standard for W10 and beyond, in which the operating system attempts to itself shut down as many peripherals as possible, downclock the CPU, shut off unnecessary cores - but stay in ACPI S0. Basically just run normally, but try to be as power efficient as possible, following how mobile phones do things. Its big advantage is that it allows for varying levels of background processing (and eg. network connectivity) that just aren't possible with traditional S3. The downside is that it needs great hardware support within the OS and that it's a complex, system-wide effort to implement (like, needs application cooperation). Linux's S0ix support (via s2idle) is quite mediocre right now.
S3 sleep is the same ACPI-driven suspend-to-RAM mode that PCs have been shipping with for decades, in which a complex rube goldberg of DSDT and platform controller pokes ends up making a CPU stop running, having saved its entire state into RAM. The upside of S3 sleep is that it generally works, unless a machine's ACPI DSDT is terribly broken (which still unfortunately happens). The downside is that it's pretty much binary (either you sleep or you don't) and that you can't control what wakes you up. I mean, there's some ACPI mechanisms for it, but they're limited and janky.
New Thinkpad BIOSes can let you choose between either exposing old-school S3 via ACPI for non-W10 systems, or enabling S0ix functionality for W10. The default is generally S0ix/s2idle.
See: https://www.kernel.org/doc/Documentation/power/states.txt
That being said I have not owned a laptop in the past decade that I trusted to sleep when running Linux. I've had nothing but problems with things like WiFi not coming back up or the machine randomly waking up in the middle of the night.
Those machines running Windows are much better. But really the only machines I trust to wake and sleep reliably are Macs. I haven't run into major sleep/wake issues on Mac laptops in twenty years of owning them.
Example: Lenovo ships some Thinkpads with a Fibocom LTE modem. But only Windows has PCIe drivers, Linux needs to use the USB interface. Not a problem one would think, but if you switch the modem to USB mode, the notebook will not boot. Lenovo still uses a whitelist for allowed devices and they forgot to add the USB mode for the modem.
Thread for further reading: https://forums.lenovo.com/t5/Linux-Discussion/Linux-support-...
https://forums.lenovo.com/t5/Other-Linux-Discussions/Linux-d...
They are done via ACPI. ACPI is implemented by the device vendor, is part of BIOS/UEFI and is notoriously buggy.
The runtime_pm framework is for when applications are still running but the device goes to sleep. In S3 suspend first every single user space application freezes, then the drivers go to sleep. S3 is much easier to implement.
That sounds like a brave statement to me.
Without knowing many details I believe that drivers can block the system from hibernating when they don't cooperate correctly.
I am absolutely sure during wakeup the driver needs to cooperate correctly. There are numerous cases that some device does no longer work correctly after wakeup. I doubt that ACPI alone can be blamed for all of the issues, even if I don't like the close source nature of ACPI.
Is there any open source approach to ACPI? Not that I'd expect to work better right away. But you know whom to blame. In the worst case yourself for not starting to fix it.
I think this is halfway accurate. Drivers are part of the problem and firmware is the other. Other folks in this thread have gone on to explain it better than I can, so I'll just point you to them.
That said, I think things like the new firmware update manager that connects device creators to the Linux ecosystem so they can provide smooth and regular updates to users are pivotal to solving these kinds of problems.
I've had less problems on PopOS due to this. Firmware updates have at times completely eradicated the more usual problems I experienced with Linux, which in an uneducated guess, probably boiled down to interoperability.
Drivers have to implement callbacks for suspend. A driver needs to make sure it saves all of its state before the suspend, and then it needs to make sure it restores all of its state after resume. S3 suspend often kills the state of every register that was previously written.
Usually, I've been running something that is either not very new, or else, is specifically branded as having linux support.
Meanwhile people do have serious issues with sleep even on Intel Macs running MacOS and Thinkpads running Windows. For whatever reason PC chip / hardware vendors just cannot get sleep to work properly. Apparently the problem is so low-level that even a company like Apple cannot paper over the problems without throwing out Intel entirely and using their own SoC in the new Macbooks.
The 2015's were incredibly solid machines, I've never heard of an issue like this happening. I still daily my 2015MBP and the thing is an absolute tank where everything just works.
I would literally bet money that your issue is hardware, not software.
Edit: I realize now that this comment could be referring to running Linux on a 2015 MBP, in which case I'm a moron and we can just disregard my comment.
I am obliged to conclude that it must be just an NVidia problem, because I always avoid those. (My laptops are built with an NVidia chip in them, but powered off. On-chip Intel graphics work very, very well lately.)
I have another laptop that takes about a minute to shut down, and it appears related to the wireless NIC. While it's an Intel-based card (Killer-rebranded... absolute garbage), I've had nothing but trouble with it. I plan on swapping it out one of these days.
Assuming you're not running a Mac (where the vendor controls the entire stack), you've got your OS vendor, your MB vendor, your every-single-external-device-vendor...
... and the interactions of all this hardware mediated through the OS, its drivers, and the reading comprehension and the development pressures of every single dev who's worked on any part of this stack.
There's an awful lot of room for ambiguities there. Protocol definition at this level is kind of a collaborative lurching towards consensus.
I wouldn't assume so. Is there a problem with the spec for using your turn signals while driving? And yet...
The fundamental challenge is complexity. Understanding how to build this stuff is a mix between figuring out which complexity to expose to “the masses” (masses here being other developers) and what else to hide in abstractions or better tooling.
I think the market would look very different if senior Linux kernel maintainers (including Torvalds) got together and said “this is the Linux power save API - implement it”. The challenge is that the same HW powers Windows (and used to power Macs and probably still does to at least some degree). No protocol worth a damn can handle that much variability. So then the question is can the firmware and driver code be given less to be responsible for rather than more and then let the kernel make all the decision making power. The problem with ACPI (at least as I understand it from reading about it superficially - I’ve never read the spec itself) is that decision making is extremely interdependent with the kernel ultimately not being fully in charge of decisions.
For example, a simple design for something like this is defining ACPI-lite that handles 80% of the hardware that ACPI currently supports but that drastically simplified the mental model and lets the kernel implement all the common logic with the driver and firmware not being responsible for anything more than translating kernel commands to the HW. Then you leave ACPI for the remaining 20% of HW that doesn’t fit in the bucket but you also make the warning verbose (you’re running legacy ACPI device X - this may degrade your battery power / prevent sleep wake from working effectively).
If they can also get Windows kernel engineers on board then you would have a compelling market forcing function on HW makers/driver writers to simplify their code.
If you want someone to do something, then you must make it realistic for them to do it, and you must make sure that they have some reason to bother.
When shopping for computer components, do people research whether that graphics card or USB hub behaves well in power saving modes? And if they wanted to, do they have easy access to that information? If not, then manufacturers will probably not prioritize it. They will prioritize whatever goes into the purchasing decision instead.
Though it is good in a way to know that there are specific things that could be improved on the technical side, because it means there's the possibility that things could be better.
Random thought: maybe some organization whose mission is energy conservation (government like Energy Star in the US or nonprofit) would be willing to fund the software revamp. Maybe in combination with people who pay data center electric bills.