Message-ID: <1414680060.2406.51.camel@hadess.net>
Date:	Thu, 30 Oct 2014 15:41:00 +0100
From:	Bastien Nocera <hadess@...ess.net>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	John Stultz <john.stultz@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: A desktop environment[1] kernel wishlist

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists