Re: A desktop environment[1] kernel wishlist

[One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>]

> > You'd have to solve it in the firmware.
> 
> Not if the kernel can tell us that the event occurred and when.

Which it can only do if the firmware told the kernel meaningfully !

> 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?

You ask for suspend and we put all the devices into lowest power state if
they are not already there then sit on our backsides issuing mwaits
asking for C7 state on BYT (C10 I think on HSW).

If you box is ever passive enough you can even randomly enter this state
in the idle loop. You generally won't do this on current devices because
you won't have suitable panels and most desktop OS's are far too noisy on
wakeups. There's nothing preventing you having half your processors in
deep idle.

That's where it is all heading though. Suspend will eventually go away.

> [1]: Reason for wake-up for each wake-up-able device, along with a
> timestamp.

We may not know and the answer in many cases will be extremely device
specific. It's a reasonable ask but answers even if available are likely
to be things like "because GPE36" and GPE36 will just be some connection
to something that could be anything from a lid switch to a light sensor
or even a smart wifi chip deciding it wants the CPU to help out because
you are out of range of the base station. We may not even know what it
relates to.

A non suspend system will exit deep idle type status because they got
an IRQ or perhaps some DMA needed the cache coherency. That doesn't mean
they've got the foggiest which IRQ kicked them out if idle, just that hey
I'm awake and there are four pending interrupts. That of course is
assuming it even noticed it entered a deep idle state - you don't want to
wake an idle CPU to tell it that its more idle than it was before.

Alan