Hello, (Please see bugs.debian.org/736389 for the earlier report.) As mentioned in the report above logind (systemd version 204-6) does not receive the "sleep key" Fn+F4. However, this key does generate the correct keycode (checked with showkey on the console and Xev). The journal also records that logind is set up to watch for the key. The udev info also records that it has /dev/input/event[n] with tag "power-switch". The system (Acer Aspire One D250) is running Debian jessie (Linux 3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29) x86_64 GNU/Linux). It is a barebones system installed via debootstrap and only contains basic text-mode utilities along with systemd. I can debug further if given indications on how to do this. Before using systemd, I was using the acpid mechanism to trigger an event handler. So acpid *was* seeing the key. As indicated in the 30/01/2014 mailing by me, I do not know where to look between the kernel and systemd/logind to find out which process is preventing the key event being sent to logind. Any help will be appreciated. Regards, Kapil. --
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.