Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Bug Graphics Games Linux

SteamOS Has Dropped Support For Suspend 378

Posted by samzenpus from the keep-playing dept.
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.
This discussion has been archived. No new comments can be posted.

SteamOS Has Dropped Support For Suspend More

SteamOS Has Dropped Support For Suspend

Comments Filter:

  • As a Linux supporter, I agree (Score:5, Interesting)

    by Gazzonyx ( 982402 ) <scott.lovenberg@gm a i l.com> on Sunday August 16, 2015 @11:21PM (#50329023)
    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.

    • Re: (Score:2)

      by LesFerg ( 452838 )

      I have used suspend for at least 6 months on my debian box. Its on a KVM switch so I switch to it and wake it up and its going in no time at all, then I leave it to drift off in its own time. My TV can also wake it up for media files. Haven't had any problems yet.

    • Re: (Score:2)

      by Trogre ( 513942 )

      Okay, but it works reliably on my Fedora desktop and has for the past three years. My Mint desktop has been reliably suspending for the past year.

      • Currently I've got a dual boot Fedora/Linux Mint. Fedora 20 suspend currently works with my RAID setup, 19 didn't, haven't tried 21 yet. Currently, Linux Mint 17 suspends, but doesn't resume and trying to boot the Fedora install after suspending the Mint install causes a reboot when Fedora starts the first time (it clears the suspend signature I assume because the second boot succeeds). I think it doesn't understand my bootloader chaining (Mint has GRUB-1, Fedora has Grub-2, the GRUB-2 chain loads the GR

    • 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

    • I've never bothered with suspend for a few reasons:
      1) It requires a swap disk/space - I don't have one on any of my personal machines
      2) SSDs make boot up fast from a clean slate every time
      3) I hear it can be iffy, and can be tough to make work anyway

      I just leave my desktop running all the time, and turn my laptop off if I know I'm not going to need it. If for whatever reason I am going back and forth to my laptop with reasonably short intervals between use (1-2 hours), I just close the lid and plug it in.

      To

    • Comment removed based on user account deletion

    • 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.

      Suspend? No, suspend is easy. Hibernate is complicated, but I have never had issues with suspend. It is so simple, just freeze the machine in its current state and then resume later without changing any state. The only applications that gets surprised by suspend and ones that rely on real clock and get surprised by large time differences.

  • Unacceptable (Score:4, Insightful)

    by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Sunday August 16, 2015 @11:26PM (#50329043) Homepage Journal

    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.

    • Re: (Score:2)

      by Khyber ( 864651 )

      " It's not acceptable not to suspend"

      Every time I do suspend this GTX 260 Core 216 horks itself on resume and fucks everything up.

      Sleep/Suspend/Hibernate. It dies.

      So the system stays on.

      • I have to suspend my Windows 7 system twice before it will suspend. This is a regressive bug introduced in the last couple of weeks. Thanks, Microsoft!

        Windows is shit at this even designing the tools to shit on Linux.

        It's still not acceptable to give up on suspend. Give users the option to try.

        • 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.

      • I had a 7600GT work flawlessly, but resuming from suspend means the fan is stuck at 100% speed.
        I even had some chat with driver devs, who couldn't believe the card had fan control without PWM (fan has two wires). Closed nvidia driver isn't that much better as it does not offer fan control either, leaving it all to the graphics card's BIOS. But under Windows you CAN control the fan speed :).

        • Re: (Score:2)

          by gl4ss ( 559668 )

          pwm doesn't need more than two wires.

          you only need the third wire if you want to know how fast the fan is turning, which is not necessary for pwm control.

          • Re: (Score:2)

            by cdrudge ( 68377 )

            pwm doesn't need more than two wires.

            Unless you're trying to control a 12V fan with logic level PWM signal.
            Or you want more that just a half-assed attempt at being able to accurately control the fan across all usages and speeds.

            I'm guessing the engineers at Intel would have loved to hear your insight before they came up a spec [formfactors.org] for 4-wire fans.

  • Ubuntu does not support hibernate (Score:3, Interesting)

    by kervin ( 64171 ) on Sunday August 16, 2015 @11:33PM (#50329063)

    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.

    • Re: (Score:2)

      by Artemis3 ( 85734 )

      You should check this: http://ubuntuhandbook.org/inde... [ubuntuhandbook.org]
      (Do note these instructions are a bit different for Xubuntu, your flavor may need specific treatment).

      In short run sudo pm-hibernate in a console and see if you can go back to your desktop when turning it back on, if so enable it following instructions.

      It is disabled by default due to many chipsets acting erratically so its unsupported as well, unless your's has the ubuntu hardware certificate.

      The same can be done with pm-suspend. It works with some ha

    • Works perfectly on windows on my machine for over a decade.
      I reboot like once a month on my laptop.
      Rule 1 when I'm building a UI is don't lose their shit.
      Rule 2 is no one cares about your fucking excuses.

      I have a unique technique.

  • Comment removed based on user account deletion

  • Technically, suspend is not the problem. (Score:5, Interesting)

    by tlambert ( 566799 ) on Monday August 17, 2015 @12:15AM (#50329207)

    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

    • 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).

      Or just remove in-kernel VT consoles completely, and replace them with a user-space implementation [phoronix.com].

    • When we are looking at USB devices is it possible this could be handled later in the boot process by having all devices re-polled and connected as new devices? So on resume previously connected devices are simply treated as new devices. It would add a delay to the resume process and I'm guessing there may be device confusion if you have 2 controllers attached, ie player 1s controller becomes players 2s after a suspend resume. But would this not be a simple, but manky, solution to the problem?

      • Re:Technically, suspend is not the problem. (Score:4, Interesting)

        by tlambert ( 566799 ) on Monday August 17, 2015 @03:20AM (#50329735)

        When we are looking at USB devices is it possible this could be handled later in the boot process by having all devices re-polled and connected as new devices? So on resume previously connected devices are simply treated as new devices. It would add a delay to the resume process and I'm guessing there may be device confusion if you have 2 controllers attached, ie player 1s controller becomes players 2s after a suspend resume. But would this not be a simple, but manky, solution to the problem?

        If you are talking about the application programs closing and reopening the devices, then yes, the controllers could be handled that way. You would have to do it in every single application, however, for every single device which was capable of moving around that way, so it would include audio devices, cameras, game controllers, and so on.

        Further, you'd have to have a mechanism for notification of the applications that they need to close and reopen (and reinitialize) their devices.

        This really can't be done at a system level, because on resume the devices look like arriving new devices, and the nodes are in use by existing opens. So it is, for example, easy to "lose" a built-in camera or keyboard or audio device, because those end points are in use, and the "new" device gets assigned a new end point.

        One of the things I fixed in the Chrome OS testing environment was that the cameras got "lost" during factory testing on a number of devices where they were interfaces via USB (but were built into the clam shell). This meant that the test harness, which set up devices up front, would lose the devices because there were "there and open" in the Python code, but "not used yet before the suspend/resume cycle".

        The fix was to move the camera open/close code, ant to modify the code to search for specific attributes which meant "camera attached to this node", rather than "node for a camera".

        • Thanks Tlambert,

          I hadn't realised the applications would be speaking to the USB devices directly but that seems obvious now in hindsight. From your description it seems like an almost impossible problem to solve without having all hardware comply with a standard, which it is obviously not doing. It is that or have some extremely complex interface layer between the application and the devices which would have huge issues of its own.

    • Re: (Score:2)

      by AmiMoJo ( 196126 )

      Thanks, insightful comment. I'd like to add little more about how Windows handles USB devices though, as it is somewhat relevant here.

      Windows uses the vendor and product IDs and one other bit of information to uniquely identify a device. The other bit of information is the USB serial number, if it is available. If the serial number isn't provided then it uses the ID of the USB port that the device is connected to.

      This has some interesting effects. Devices with serial numbers work as you would expect. Driver

  • 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... [advogato.org]

    Apparently it's much nicer now.

  • Not just on Linux (Score:3)

    by Chewbacon ( 797801 ) on Monday August 17, 2015 @06:49AM (#50330359)

    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.

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close