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.
This is a great example of how not to close a bug report.
Merely stating that the feature "is no longer supported" and closing the bug report without giving any further explanation is the wrong way of handling the situation.
If a user went to the trouble of submitting the ticket, then somebody associated with the project should at least put forth the small amount of effort it takes to explain why the bug is being closed without being properly resolved.
Providing some concrete information is just the sensible, courteous thing to do.
Uselessly vague "$FEATURE is no longer supported"-type replies do no good.
Giving a proper explanation for why a bug is being closed is not "handholding".
It's professionalism, plain and simple.
Being a programmer doesn't mean that one's incapable of providing a technical justification for closing a bug ticket.
It doesn't even matter if the person who logged the bug is a customer or not.
If the bug ticket is closed, then a complete, technical explanation of why is the minimum that should be expected.
The person who opened the ticket, and anyone else reading it, regardless of whether they are or aren't affiliated with the project in question, should be provided with a full explanation as to why the bug was closed.
This will typically be well over one sentence in length.
So if someone is closing a bug ticket and their justification is only one or two sentences long, then they should realize right away that what they're providing is completely insufficient.
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
For all the nitpickers, what he said is true. Suspend saves the system state in RAM, which means NOT in CPU registers, GPU registers, nor a myriad other hardware controller registers on devices and hubs all over the system bus. The RAM is left in a low-power, self-refresh mode. Resuming from suspend means powering up all those devices, reinitializing their control registers, and getting everything back in sync with the state that the OS *thought* it was in according to the state stored in RAM.
This process involves coordinated effort of many different layers of hardware drivers to reinitialize each part and restore it to a working state. Some annoying hardware also lacks a simple "load state from bit sequence" function, and instead needs its own convoluted state-machine to be run through multiple steps in the right order to reestablish the state it had before suspending. This is where things usually go comically wrong.
Hibernate suffers all of this plus a bit more. It also has to reinitialize the disk controllers, read the saved system state from disk into RAM, and then perform all this same state-recovery that resume-from-suspend does.
So I guess I should make a comment about how superior Windows is because this is an article about Linux OS issues. Then I can be like all the Linux fan boys who just have to comment in Windows articles on how they never have such such issues because they are running a Linux based OS.
I've never have suspend or hibernation issues while running Windows based OS. In fact, it's crazy how fast resume works on my Lenovo Z50-75 running Windows 10. I don't even worry about privacy issues because I turned that stuff off. It's was easy to get the help I needed right from Windows forums on the correct settings.
Instead of all the thousand different yet same Distros. How about all the Linux geeks get together, focus on a handful of Distros and prove to us why it's superior to Windows? Because issues like suspend and the various graphic driver bugs will continue to keep it from wide spread usage. Like it or not, Linux based Distros make up 1.6% of the desktop OS and it's because of problems not because it's better. Microsoft has continued to up their game on the desktop and Linux Distros will have to match them if they every want a chance at taking over.
All that effort is better-spent making the OS start up and shut down quickly
No, it really isn't...
People who just want their computers to work also want their stuff to stay where it was when they closed their laptop. I know I do. I often have 5 to 10 programs open, sometimes 5 to 10 tabs open in a web browser.
When I turn off my notebook and turn it on a few hours later, I expect it all to be sitting there as I left it.
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.