| Summary: | logind (version 204-6) fails to catch suspend key (Acer Aspire One D250) | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Kapil Hari Paranjape <kapil> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED FIXED | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | kapil |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Kapil Hari Paranjape
2014-01-31 10:13:55 UTC
Hmm, can you strace logind while pressing the key, to see whether logind gets it at all? Do logind's logs show that it picked up the input device the fn key is on? An strace output while pressing the key is attached to the Debian bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=30;filename=logind_strace.txt;att=1;bug=736389 The logs do show that it is handling the "Sleep Key". https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;filename=logind_journal.txt;att=2;bug=736389 The key also shows up with "showkey" on the Linux console. Maybe something is inhibiting it? What does systemd-inhibit --list show? The response from systemd-inhibit --list is "0 inhibitors listed." Is it possible for the keyboard to somehow skip/avoid indicating an event on /dev/input/event* and yet generate the correct keycode? I somehow get the feeling that the event is not being received by logind. Well, logind actually logs "Power Key pressed" in your first starce output, so it did get the evtn. If you do this, and type "systemctl list-jobs" on the shell shortly after, do you see anything queued? Do you see any output generated from PID 1? The Debian package "triggerhappy" was installed. It has a daemon called "thd" which allows one to monitor which events are being received. It turns out the Sleep Key generates a KEY_SLEEP event on /dev/input/event0 (which is the Keyboard device). On the other hand logind seems to be monitoring /dev/input/event3 for the Sleep Key. (Perhaps it picks this device /dev/input/event3 up from the kernel.) Perhaps this is the source of the problem. The so-called sleep key is not generating an event on /dev/input/event3 and is merely generating a keyboard event. Kapil. -- Which input devices logind is listening on is controlled with the "power-switch" udev tag which we currently only set for acpi and thinkpad_acpi input devices... We probably should set this for normal atkbds too, but this would mean logind would be woken up for all random keys users press, and that's ugly... We started discussions now with some input guys whether we might be able to get a "wakeup mask" or so that we can set on input devices from logind and which would make sure we only get certain keypresses, not all... In the maintime i should be sufficient to set the "power-switch" tag on your kbd device, locally, until we find a good solution upstream. This is how the rule looks like for the acpi keys: SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="acpi", TAG+="power-switch" It shouldn#t be too hard to come up with a rule that works for you lpatop... This should be fixed since a while, see github PR #6210. Closing. |
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.