Slashdot Mirror
SteamOS Has Dropped Support For Suspend
jones_supa writes: As pointed out by a Redditor, it seems that suspending the machine is not officially supported by SteamOS anymore. A SteamOS user opened a bug report due to his controllers being unresponsive after a suspend cycle. To this, a Valve engineer bluntly reported that "suspend is no longer supported". He further explained the issue by saying that given the state of hardware and software support throughout the graphics stack on Linux, the team didn't think that they could make the feature work reliably.
Suspend is such a complicated feature that touches every part of the stack. I've found it works about 50/50. Every now and then I try it and it works for a while until a kernel update breaks it, eventually I try again in a few months and it's working again. I wouldn't support it if I wanted to remain sane.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
Considering the push for the "Year of the Linux Desktop" it's strange Ubuntu does not support hibernate and hasn't for years now. Hibernate is important, because unlike suspend it does not require power.
It's annoying to have the computer shutdown when it runs out of power instead of simply hibernating.
Funny you mentioned systemd, as hibernate on pre-systemd setup didn't work for me reliably on two Linux machines I use. Now I use it routinely without any problem.
Technically, suspend is not the problem. The problem is resume. It doesn't probe and reattach the controllers to the same point in the device tree that they were in when the system was suspended. Since those are the device nodes that SteamOS has open at the time of the suspend, and they route to The Noplace(tm), the controllers become unresponsive.
This is a general problem in the Linux device model, and you can see problem in the device model poke their heads up in various places.
For example, if you plug in two USB keyboards, what you are going to see when you hit the caps lock key on one of them is that the caps get locked for both of them, but the LED indicating that the caps lock is on is only lit on the original keyboard. This is great fun, when you see the LED state on both keyboards relative to the caps lock state, when you bounce the caps lock key on the second keyboard.
Presumably, this was implemented this way in order to allow multihead operation, with the keyboards separately (and explicitly -- which they are not by default -- to separately running console instances. But it's indicative of deeper problems in the model.
The reattach operation should (in theory) be handled by the udev mechanism, which I'm told is subsumed in systemd; however, they've faithfully reproduced the problems in the original implementation in the replacement as well (so it actually doesn't matter which one SteamOS is using, so please don't argue about that crap).
There are two implementations that do work; however, they in fact work differently.
The first implementation is in Windows; it works by directly assigning the device descriptor based on the USB vendor and device ID. What this effectively means is that when you resume, everything gets the same descriptor (or a replacement) that it had going own. The keyboard "problem" is handled in Windows by making them "the same device" -- in other words, you caps lock on one keyboard, it does it on both, and you undo it, and it does it on both.
The second implementation is Mac OS X; it's handled by explicit enumeration order of USB bus devices, and the using the USB vendor and device ID *and* the enumeration position ("bus ID) to uniquely identify the device.
You'll also notice, if you look, that Linux has problems with keyboard internationalization and locale. This is most easily seen by using a locale specific keyboard, and having it not be recognized. Further, you'll notice that the character set differences are handled by tables in X and Weyland, and these are not the same as the console tables (i.e. the USB ID of the keys is not propagated through the full input stack, and there's a difference in operation between sending the events up through the console, vs. sending events up through the X Server). To fix this would require moving the HID key value translations into the kernel keyboard driver, rather than having it (mostly) in user space in all three instances (X, Weyland, console).
Finally, Apple is one of the few vendors that actually correctly fills out the USB device serial number field correctly, so it's hard to use that as a unique identifier (specifically, it makes it really hard to mask program all your controller chips, without adding a "burn the fusable links" step).
Further, they are also one of the few vendors that sets the locale field in their USB devices (most laptop vendors will get this right during manufacturing, by placing the value into the BIOS, since the laptop keyboard is actually matrix decoded by the EC via a grid hooked up to GPIO pins, and then the EC pretends it's an 8051 with a PS/2 interface for the keyboard to mux a PS/2 trackpad -- e.g. like a Synaptics -- to look like a standard PS/2 keyboard and mouse).
Apple handles for unrecognized keyboards by having you press "the key right of the left shift key" and "the key to the left of the right shift key", and then uses the key IDs. Not ure if they have a patent on it, but it's a lot more clever than what Linux or the BSDs do to
Am I the only one who hasn't had a suspend problem in years on any platform? The last time I can recall having suspend not work reliably was on a late '90s Pentium 2 running Windows 98.
I used to get high on life, but I developed a tolerance. Now I need something stronger.
You got it half right, the problem on Linux is drivers or more precisely a driver stack that hasn't evolved since the days of Win9x. You can sit down and with basic math show that "let the devs handle it" just doesn't scale, even if you had ten times the amount of driver devs than Linux actually has they still wouldn't have enough hours in the day to fix all that gets pissed on when Torvalds and friends change a pointer.
I have taken XP drivers and ran them in Windows 7, taken XP X64 drivers and run them in 8.1 64bit, and until Linus fixes his mess of a driver stack so an OEM won't have to remake every driver when a new kernel comes out? Things are never gonna get any better which is why despite Windows 10 being nothing but spyware pretending to be an OS Linux will not gain even a single percentage point, not one.
The really sad part IMHO? I gave you a perfect test to rub in the dev's noses like rubbing a doggy nose in its poo, they say their driver model works? Show them the results of the Hairyfeet challenge and call 'em out on their bullshit. Instead I get called dirty names for actually expecting an OS to be able to update itself without destroying itself (gasp! shock!) and have FOSSies rush to defend them with classic memes like "its free you can't complain" or the ever hilarious "you should fix it" which is like saying you have a new car that can take on the new Mustang and when somebody asks to see it you hand 'em a pile of raw ore and say "here ya go, make it for me" LOL.
So take the challenge yourself, pick any of those "consumer friendly" distros and knock yourself out, then you will see why Linux doesn't gain any share and why I predict Valve will abandon SteamOS within 5 years, its because you can't build a strong house on a rotten foundation and the Linux driver model is rotten to the core.
ACs don't waste your time replying, your posts are never seen by me.
Hibernation never works for me and I am unwilling to debug it. Suspend works like a champ, though.
"So long and thanks for all the fish."
In Linux, suspend to disk really does write the contents of RAM to the swap partition.
From here:
Suspend part
~~~~~~~~~~~~
running system, user asks for suspend-to-disk
user processes are stopped
suspend(PMSG_FREEZE): devices are frozen so that they don't interfere
with state snapshot
state snapshot: copy of whole used memory is taken with interrupts disabled
resume(): devices are woken up so that we can write image to swap
write image to swap
suspend(PMSG_SUSPEND): suspend devices so that we can power off
turn the power off
Funny that yours has just worked. I guess you were one of the lucky ones. I've used some Linux off and on, mostly off these days. A couple of years ago I had an Ubuntu over the network upgrade (can't remember exactly which one), and after the install finished there was no network card anymore. The flipping OS upgraded OVER THE NETWORK and then didn't have a network when it was done. That's the way Linux works sometimes. You go to a second machine and search on it and find that they randomly don't have support for the specific card anymore. Outstanding! Then don't upgrade machines that have that card.
This is one of the big reasons I switched to Mac a long time ago (Pre Windows 7). I got utterly fed up with Windows being unable to handle suspend/resume. I tried to go to Linux, but the amount of fiddling and script editing I needed to do to make it was was just absurd, and still wasn't guaranteed to work.
I am able to close the lid on my Macbook Pro to suspend, open it to resume, multiple times a day for weeks at a time without ever having to shut down or reboot. (Ocassionally it would die, at which point I would be livid because it would be so unexpected). Whether this is still true or not, I'm not sure, as I haven't needed to do this for a couple years now, but it was true for 10.5, 10.6 and 10.7.
It's depressing that that it sounds like things haven't improved at all on the Linux side... I don't want to go to back to Windows, especially considering all the privacy nightmares I've been reading lately about Windows 10, but I'm equally unhappy with the appliance-ification of computers that Apple is doing... I swear it seems like we're going full circle to go back to the 1980s.
One would have thought that by going the Apple route and focusing on a specific and limited set of hardware, Valve would be able to focus on making sure that that hardware works flawlessly. I believe there are several Linux-certified laptops that are supposed to have done this (I can't remember who at this point... Dell maybe?), but I have no experience with them so I can't say how successful they were.
But rambling aside... Being able to suspend and/or hibernate should be considered a standard feature in almost everything at this point, so a device that can't handle it just seems... sub-par, and makes you wonder what else they've screwed up, or if they're even competent enough to put out a decent product in the first place.