lkml.org 
[lkml]   [2015]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: A desktop environment[1] kernel wishlist
    On 05/07/2015 11:03 PM, Rafael J. Wysocki wrote:
    > On Thursday, May 07, 2015 05:54:56 PM One Thousand Gnomes wrote:
    >> On Tue, 05 May 2015 14:31:26 +0200
    >>
    >>> For example, when you wake up from S3 on ACPI-based systems, the best you
    >>> can get is what devices have generated the wakeup events, but there's
    >>> no input available from that (like you won't know which key has been
    >>> pressed). You may not get that even. You may only know what GPEs have
    >>> caused the wakeup to happen and they may be shared.
    >>>
    >>> For PCI wakeup, the wakeup event may be out of band. You need to walk
    >>> the hierarchy and check the PME status bits to identify the wakeup device
    >>> and then you need to be careful enough not to reset it while putting into
    >>> D0 for the input data associated with the event to be available. I'm not
    >>> sure how many device/driver combinations this actually works for.
    >>>
    >>> For USB wakeup, you get the wakeup event from the controller which may be
    >>> a PCI device. Getting to the USB device itself from there requires some
    >>> work and even then the device may not "remember" what exactly happened.
    >>>
    >>> Further, if you wake up via the PC keyboard from suspend-to-idle, the
    >>> wakeup key code is not available, the only thing you know is that the
    >>> interrupts has occured (that may be changed, but it's how the current
    >>> code works).
    >>
    >> It's probably got to change, otherwise once machines get able to sleep
    >> between keypresses it's going to suck every time you pause and think for
    >> a minute then begin typing. Remember display being off for suspend is
    >> purely a limitation of most current display panels.
    >
    > Right.
    >
    > It is just one example, though.
    >
    > Take a PCI device in D3hot for another one. It may not even have a buffer
    > to store input data while in that state. The only thing it may be able to
    > do is to signal a PME from it.

    Yeah, I tried to make clear that I don't think that this is generally
    achievable. But in the ChromeOS hardware that I have here, the input
    event is there for userspace to read when it wakes up.

    But if there's traction for adding upstream a more generic mechanism
    that works in a broader range of machines, I'm all for it.

    Regards,

    Tomeu



    \
     
     \ /
      Last update: 2015-05-08 09:21    [W:2.480 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site