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.
Is systemd involved at all with these problems?
WONTFIX
Is even worse on Linux than it is on Windows.
No one has managed to make it work reliably on Windows either. I don't think I've ever encountered a laptop on which Suspend wasn't either a game of Russian Roulette, or a guaranteed way to require a restart.
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 half-assed reply from johnv-valve reminds me why I don't bother submitting issues for projects hosted on GitHub. I've seen that kind of useless reply, followed by an immediate closure of what's apparently a legitimate bug report, way too often within GitHub. While this can happen with other bug reporting systems, too, I think that there's something with the GitHub culture and mindset that really promotes such disrespectful handling of bugs. Maybe it's the total lack of accountability, coupled with the "social coding" concept. More traditional non-GitHub bug tracking systems were just about that: tracking bugs. But GitHub adds the "social" aspect to it, which ends up just being a way for the project leaders to go on power trips, which often involve treating mere users of the software like total shit.
But even disrespectful bug closures like that don't match up to the pathetic "code of conduct" controversy bullshit we saw recently. I've been involved with open source software development for a couple of decades. We didn't need bullshit "code of conducts" before this GitHub era, because our coding wasn't "social". We were writing open source software to solve real problems, or to make our lives easier. We weren't coding as a way to attract attention, or to see who had a bigger e-penis, or to treat others like shit just so we can feel like we have "power" over others. We just naturally treated one another with respect, so we didn't need some lengthy, goddamn list of rules governing each and every possible aspect of our social interactions! It's only now that the coding becomes secondary to the "social" that all this bullshit about "code of conducts" starts coming up, and it's really quite pathetic!
To play games dual boot to Windows. That's the solution even if Windows is used exclusively for this purpose. After that, no more time wasted trying to make this work and no more giving a crap about GPU drivers on Linux, etc.
Suspend is a key feature, and energy costs more than ever. It's not acceptable not to suspend. Many people won't shut down, and if they can't suspend, they'll just leave the system on and turn off the display.
I hope they're at least using the lowest power states when at idle, and with a governor more intelligent than ondemand.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Don't have either on my Windows 7 box, only 'Sleep' and 'Shut Down'.
Not really sure what either of those does.
Reddit is buying Slashdot
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.
...wake from suspend is a whole lot worse.
Tried getting my wireless logitech keyboard to wake up my ubuntu-installed intel NUC to wake from sleep, but I can't get it to work.
Logitech's Unifying receiver can wake from sleep on Windows out of the box, but ubuntu needs hacks and tweaks... of which I can't get to work.
Having to get out of the chair and lean over to hit the power button on the computer should not be a feature when there's a wireless keyboard on the couch.
READY.
PRINT ""+-0
but most Linux users are power users, and have Windows..so it doesn't really matter.
They can't properly interact with the underlying system. GNU/Linux is an ever evolving system which gets new features and improvements at all layers regularly. What is really going on is the companies producing these proprietary drivers can't keep up. Most of the problem goes away if you release the code and its properly integrated into the rest of the system. This is one of the many reasons I won't use hardware dependent on proprietary drivers/firmware/etc. Proper support demands the drivers source code be released.
Not sure why you'd need to save the state of RAM to RAM!! Perhaps thats a feature whose time NEEDS to end!
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
There can be several MB of data stored in the processor cache, as well as the contents of the processor registers. In addition you need to either preserve state for all the peripheral chips you're powering down or release reinitialize them on resume.
Think of how we use video devices. Not just in Linux, in pretty much all current systems. In the name of "efficiency" we memory-map them, and we let the user process directly mess around with the internals of a hardware device.
This is the way a set-top video game box works, not a secure and reliable operating system.
Until the video is firewalled off from the user the way other components of the operating system are, it's not going to be safe, secure, or reliable. Obviously we'll need new hardware designs to make this work fast enough.
Bruce Perens.
Then how does Android work so well?
Wireless controllers, keyboards and mice ?
I hate wireless stuff with a passion, but it seems to me that a system that suspends USB port power would not be able to power the machine back up
For those who think a simple suspend is easy, go read one of Matthew Garrett's old posts about the mess. Here's an example:
http://www.advogato.org/articl...
Apparently it's much nicer now.
Ask me about repetitive DNA
Most of the time problems with suspend/hibernation are related to drivers which aren't properly initializing after the memory is restored. the thing with hardware is that the state of the hardware has to be restored after suspend/hibernation to the point that the driver expects as the state. So if a driver isn't capable of restoring that state, it will likely cause some sort of trouble.
Never underestimate the relief of true separation of Religion and State.
I've been using Linux for over 10 years on various systems, I've never seen it successfully work. It's also pointless, Linux machines boot fast anyway.
Like much in the BIOS, it was "designed" to work with the windows system, not designed according to the spec.
The failures to work properly with suspend is not a problem with the software in Linux but the crap programming of the motherboard manufacturers.
Just like when MS and supporters claim that the problem with crashes in NT/XP/... were due to buggy hardware and the drivers written by the manufacturer and NOT due to the windows OS.
Same deal here.
Suspending on lid-closure is one of the first thing's I disable on a new system:
echo HandleLidSwitch=ignore >> /etc/systemd/logind.conf
systemctl restart systemd-logind # or reboot
Let's hope that this lack of support for suspend will not affect the SteamBoy portable steam handheld. From my experience with a PS Vita, suspend is absolutely essential for anybody playing games in public transports. When you only play a few minutes here and there between transfers, being able to suspend the game is absolutely essential.
Without suspend it's simply not playable because often you do not get the chance in a single play session to start the game and progress enough to even be worth it to start playing.
I've had hardware act screwy on Windows, too. Sometimes Windows will just refuse to sleep because a process prohibiting suspend did not exit like it should. Suspend works rather well on my present install of Ubuntu on my laptop, but I've had issues with it waking up.
Chewbacon
The Bible is like Wikipedia: written by a bunch of people and verifiable by questionable sources.
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.
Sounds like a job for SystemD to take over!
Steamboxes are now on sale. Breaking features is lawsuit time not time for wontfix
i'd like the auto-update-and-reboot be a bit smarter and signal apps that an update reboot is occurring and then the apps save their state
Windows applications do get a restart notification. Bug the publishers of the applications that you use to register for and act on this notification. On the other hand, Microsoft is hypocritical about this, including with Windows several applications that do not save their state.
In theory, Windows is already designed this way. Only a few services require a restart. It's just that PC operating systems in general have become so big, and people on the other side of the Internet have become so malicious, that at least one update per month affects a critical system service.
A lot of the issues I've had with suspend have been with the Nvidia/ATI proprietary video drivers, especially when switching video modes, and beyond that with USB peripherals
Suspending worked fine, when resuming I'd often have peripherals missings (often unplugging/replugging worked OK for keyboards, but not so much on a laptop) and plenty of weird stuff would occur with the video drivers.
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.
I thought Linux didn't have problems.
You bought a laptop designed specifically for Windows, with windows pre-installed on it, and you're complaining that it would be too much work to grind through the tedious process of building linux specifically for your hardware.
You'd have an only slightly less frustrating problem if you'd bought a laptop designed specifically for Linux and tried to put windows on it.
Laptops always have uniquely challenging hardware; if you want ease of software installation use a desktop PC with generic parts. If you want a laptop, buy one preconfigured with the OS you desire, and stop whining that it didn't come with a free pony.
Hey, you have the same bullshit criticism as last time, I have the same response, you presumably have the same lack of response. I'm going to be less polite here, because you're obviously trolling.
Linux does not need desktop marketshare, and having a closed driver model would be too great a price to pay. If that means trouble for Valve, too bad. However, the driver model actually has nothing to do with anything, and your predictions and your challenge are worthless. You do not have a clue what you are talking about. If the drivers are so terrible, how are there billions of Linux devices?
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
My close relatives don't have to worry about getting infected a couple times a year since I helped them move to Linux.