lkml.org 
[lkml]   [2014]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: A desktop environment[1] kernel wishlist
    From
    On Mon, Oct 27, 2014 at 7:19 AM, Bastien Nocera <hadess@hadess.net> wrote:
    > I also cannot know, from user-space, whether Wake-On-LAN,
    > Wake-On-Wireless-LAN, or the Wi-Fi card's "network proximity" triggered
    > coming out of suspend for example.
    >
    > I can certainly check for the status of the lid, but I wouldn't know
    > whether a button was pressed to turn the machine back on, as the
    > firmware would eat that.

    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?

    > To make it short, I don't have a way to know, from user-space, whether
    > the event that took it out of suspend was programmatic, or user action.
    > I would add that, even if we said that races can occur, I have no easy
    > way to know, from user-space, whether the last thing that occurred was
    > the Wi-Fi card waking the machine up or the power button being pressed.


    Again, I think you just want to know if the power button (or lid
    trigger) was pressed. Not if it was the cause for resume (since a
    wake-on-lan or alarm could fire right as the user presses the power
    button). If those button presses don't reliably get communicated, I
    think that's a better problem to solve in the kernel.

    Again, part of the reason I'm pushing back here, is that there may be
    a lot of things going on on a system, and systems may suspend and
    resume quite often while being in use, so applications really should
    handle events consistently weather the system was suspended or not
    (another lesson from android: suspend blocking is a more flexible
    approach then having applications initiate suspend, since you avoid
    all the races of multiple applications trying to manage initiating
    suspend state).

    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 (event filtering, in other
    words). So I think its better if you design around events (button
    presses, lid triggers, mouse movements, timers firing), rather then
    specific system suspend state.


    >> Sure. But its not reliably suspending I'm worried about, its
    >> accidentally resuming in an environment the hardware wasn't designed
    >> for. Its really more of a hardware design issue. I'm not suggesting
    >> you don't do it, but I just suspect you'll need to be careful about
    >> automatically enabling this on older hardware.
    >
    > It could be opt-in if that's actually a problem.

    Yea. And again,I don't mean to throw water on the idea, I just wanted
    to make sure considerations were being made. Its good folks are
    working to keep function/feature parity with other modern desktop
    OSes, but quite often those OSes aren't expected to run on the same
    variety of hardware. So finding a way to detect safe hardware-designs
    would be useful for your effort.

    thanks
    -john


    \
     
     \ /
      Last update: 2014-10-27 18:21    [W:5.765 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site