Hello, My HP Chromebook 14 (Falco) sometime go to sleep without any reason. I'm on Fedora 26. I ran F23, F24, F25 without any problem in the past. The problem occur with both John Lewis and MattDevo firmware. Seem to happen less with JL firmware (only once that week). It seem that there is fake "Lid closed" event... > sept. 12 19:59:30 hp systemd-logind[759]: Lid opened. > sept. 12 19:59:30 hp systemd-logind[759]: Suspending... > sept. 12 19:59:30 hp systemd-logind[759]: Lid closed. Of course my lid can be "broken" and send fake event but as I said it never happened before I installed Fedora 26 and I tried to move the lid in all possible way and I never managed to trigger a "fake" event. Anyway these almost instant conflicting event should cancel them out. I mean libinput (systemd ?) should wait a little bit (1s ?) before putting the pc into suspend and this for 2 reasons. The first one to avoid unwanted behaviour like this one. The second to prevent the pc to suspend itself if you change your mind (eg. you close the lid to suspend it but reopen it almost instantaneously to continue using it). So there is a possible bug in libinput (or systemd or elsewhere but where ?) that trigger these event without any reason and there is a possible improvement to make to handle suspend event. I also opened a bug report against systemd https://github.com/systemd/systemd/issues/6900 Thanks !
libinput doesn't do anything with suspend, the only thing it does is that it disables the touchpad when a lid switch event is received. see http://who-t.blogspot.com/2017/02/libinput-and-lid-switch-events.html for an explanation. If you hardware is broken, you can set LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open in the hwdb (have a look at 90-libinput-model-quirks.hwdb, there are entries for this already). If that is set, libinput will send a lid open event as soon as you start typing. That at least papers over the firmware bug you're seeing. What does evemu-record on the device show in this case? Does it show an open + close event?
(In reply to Peter Hutterer from comment #1) > libinput doesn't do anything with suspend, the only thing it does is that it > disables the touchpad when a lid switch event is received. see > http://who-t.blogspot.com/2017/02/libinput-and-lid-switch-events.html for an > explanation. Suspend is triggered (by systemd it seem) because libinput detect a lid event in the first place, right ? > If you hardware is broken, you can set > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open > in the hwdb (have a look at 90-libinput-model-quirks.hwdb, there are entries > for this already). If that is set, libinput will send a lid open event as > soon as you start typing. That at least papers over the firmware bug you're > seeing. The thing is I strongly doubt that my lid is broken. It's just a possibility. Since it never happen before I installed Fedora 26, and it happen with 2 different firmware, I'm more inclined to think it's a software problem. > What does evemu-record on the device show in this case? Does it show an open > + close event? It will be hard to know since it only happened once in 10 days since I test the John Lewis firmware.
(In reply to Paviluf from comment #2) > (In reply to Peter Hutterer from comment #1) > > libinput doesn't do anything with suspend, the only thing it does is that it > > disables the touchpad when a lid switch event is received. see > > http://who-t.blogspot.com/2017/02/libinput-and-lid-switch-events.html for an > > explanation. > > Suspend is triggered (by systemd it seem) because libinput detect a lid > event in the first place, right ? no. systemd and libinput simply listen to the same kernel device. The switch event is delivered to both, each handle it in their own way. Whether libinput (or anything else) is around doesn't matter for this particular bug. even with WRITE_OPEN libinput *never* writes a lid close event, those always come from the hardware. > > What does evemu-record on the device show in this case? Does it show an open > > + close event? > > It will be hard to know since it only happened once in 10 days since I test > the John Lewis firmware. right. In that case I'll close this bug here because the best we could do (if the firmware is indeed confirmed to be broken) is the WRITE_OPEN approach outlined above. If the lid state doesn't match the hardware state that is either a kernel or ACPI bug. If the lid state matches but the suspend/resume behaviour does not match, then that's a systemd bug.
Ok, thank you Peter.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.