Messages in this thread |  | | Subject | Re: A desktop environment[1] kernel wishlist | From | Bastien Nocera <> | Date | Thu, 30 Oct 2014 15:41:00 +0100 |
| |
On Tue, 2014-10-28 at 22:57 +0000, One Thousand Gnomes wrote: > > If the firmware eats that button (which I hope it wouldn't, but I > > probably should know better then to expect sane behavior), how does > > the kernel know anything more? > > The firmware is generally going to do whatever it believes is "correct", > which may nor may not be determined by what the hardware itself does > (if wakeup is a GPIO off the controller then it'll be determined by the > widget the other end what is eaten) > > > button). If those button presses don't reliably get communicated, I > > think that's a better problem to solve in the kernel. > > You'd have to solve it in the firmware.
Not if the kernel can tell us that the event occurred and when.
> > But the other part of why I'm pushing back is that on future hardware, > > we may not have a "suspend" mode, and systems may just be in a deep > > idle, with selected interrupts disabled > > Nothing future about this. Some ARM devices have had that kind of mindset > for a long time, some x86 platforms can run that way but don't currently > do so under Linux (eg Baytrail/T). On those x86 platforms 'suspend' and > 'resume' are in fact entirely Linux constructs to fake legacy behaviour > on top of an ultra low power idle. > > If you are planning for the future then I wouldn't be too hooked on ideas > like "suspend", "lid switches" or assumptions that a "closed" device > should be kept suspended. It's a broken model. It's bad enough that > systemd tries to do magic hackery to fake this up and gets it wrong in > some case (despite making a very good effort) without propogating the mess > further. > > - S3 has already gone away on some Intel SoC devices
And I think I have one of those devices, an Intel Baytrail tablet.
> - Suspend/Resume on such machines are a Linux fake to keep legacy code > happy
Do you have a link to how this is implemented currently?
> - In such an environment your "wakeup" model changes entirely because you > drop into deep idle whever there isn't stuff annoying the CPU > regularly. With the right kinds of video and audio that could even mean > doing it between keypresses (feature parity approaching 1980s 8bit > laptops ;-) ) > > Instead think long term that > > - There may be no such thing as suspend or resume, just make your code > very well behaved on wakeup events, and closing unneeded > devices/resources whenever it can. > - On/off is an extreme action rarely taken (feature parity with 1970s > VAXen ;-) ) > - The "blob with a lid" model of construction is no longer useful. Even a > keyboarded device is quite likely have a removable keyboard.
Except that what I requested (at least the amended version[1]) would also work with devices that don't have suspend. And would also work on the millions of other devices that do have a suspend state, and exist in the wild.
[1]: Reason for wake-up for each wake-up-able device, along with a timestamp.
|  |