You are not logged in.
In Power Manager there is a setting section Buttons. I'd like to set the action to perform when the power button is pressed.
kamil$inxi -S
System:
Host: debian Kernel: 6.12.27-amd64 arch: x86_64 bits: 64
Desktop: Xfce v: 4.20.1 Distro: Debian GNU/Linux 13 (trixie)
kamil$inxi
CPU: dual core Intel Core i5-2520M (-MT MCP-) speed/min/max: 3200/800/3200 MHz
Kernel: 6.12.27-amd64 x86_64 Up: 5m Mem: 1.72/7.71 GiB (22.3%)
Storage: 476.94 GiB (6.0% used) Procs: 220 Shell: Zsh inxi: 3.3.38
kamil$tldr inxi
I'm on X220 ThinkPad. Is this a bug or can I set what the 'Power button' – or 'Sleep button' is?
Offline
Current;y with "Ask" you should get the logout dialog. Is this not what's happening?
I AM CANADIAN!
Siduction
Debian Sid
Xfce 4.20 with Wayland/Labwc
Offline
To run a custom command when the power button is pressed,
you need to intercept the ACPI event and handle it yourself,
bypassing the default XFCE Power Manager behavior.
You'd set the button to Do Nothing and handle the event with acpid.
https://wiki.archlinux.org/title/Acpid
Do you want to exit the Circus?
https://www.youtube.com/watch?v=ZJwQicZHp_c
Offline
Current;y with "Ask" you should get the logout dialog. Is this not what's happening?
Yes, with that and any other option nothing happens. The power button works perfectly fine and it's the original keyboard in good condition.
Offline
eriefisher wrote:Current;y with "Ask" you should get the logout dialog. Is this not what's happening?
Yes, with that and any other option nothing happens. The power button works perfectly fine and it's the original keyboard in good condition.
Is it a laptop or a desktop?
Is the power button on a computer case or on a usb keyboard?
Like some multimedia or laptop-style USB keyboards with a dedicated power key?
The button may or may not send the standard ACPI power event that the system expects.
Many power buttons built into laptop cases or directly connected to the motherboard send special ACPI events,
which the OS and desktop environment detect and handle (like XFCE Power Manager).
But a USB keyboard’s power button is often just a regular key sending a keycode
not necessarily triggering an ACPI power event.
Run
xev
in a terminal:
Press the power button on the USB keyboard.
See if any key event appears.
Do you want to exit the Circus?
https://www.youtube.com/watch?v=ZJwQicZHp_c
Offline
Fragrant1470 wrote:eriefisher wrote:Current;y with "Ask" you should get the logout dialog. Is this not what's happening?
Yes, with that and any other option nothing happens. The power button works perfectly fine and it's the original keyboard in good condition.
Is it a laptop or a desktop?
Is the power button on a computer case or on a usb keyboard?
Like some multimedia or laptop-style USB keyboards with a dedicated power key?The button may or may not send the standard ACPI power event that the system expects.
Many power buttons built into laptop cases or directly connected to the motherboard send special ACPI events,
which the OS and desktop environment detect and handle (like XFCE Power Manager).
But a USB keyboard’s power button is often just a regular key sending a keycode
not necessarily triggering an ACPI power event.Run
xev
in a terminal:
Press the power button on the USB keyboard.
See if any key event appears.
This is a X220 ThinkPad laptop . It is not an USB keyboard, not a desktop. I ran the command, and at least to me it appears that no event was registered when pressing the power button, and I did that a couple of times in a couple of tries, but here's the output for your interpretation: https://pastebin.com/idAG0s3L
Offline
Yes xev will not detect power button.
Install acpid
sudo apt install acpid
and run in terminal
acpi_listen
Then press the power button.
If you get something like
button/power PBTN 00000080 00000000
This would confirm that the ACPI subsystem is active and that the power button generates events,
which can be intercepted or overridden.
In that case a simple script would do
#!/bin/bash
acpi_listen | while read -r event; do
if [[ "$event" == *"button/power"* ]]; then
echo "Power button pressed at $(date)"
xfce4-session-logout
fi
done
But if there is no output from acpi_listen then something else is an issue.
Last edited by Misko_2083 (2025-06-10 18:00:10)
Do you want to exit the Circus?
https://www.youtube.com/watch?v=ZJwQicZHp_c
Offline
Yes xev will not detect power button.
But if there is no output from acpi_listen then something else is an issue.
Unfortunately, something else is an issue. It correctly listened to other keys, but did not output anything for the power button.
kamil$acpi_listen
3button/micmute MICMUTE 00000080 00000000 K
button/mute MUTE 00000080 00000000 K
button/mute MUTE 00000080 00000000 K
button/volumeup VOLUP 00000080 00000000 K
button/prog1 PROG1 00000080 00000000 K
button/prog1 PROG1 00000080 00000000 K
button/prog1 PROG1 00000080 00000000 K
button/prog1 PROG1 00000080 00000000 K
button/up UP 00000080 00000000 K
Offline
Check if ACPI button driver is loaded
Run:
lsmod | grep button
You should see something like:
button 16384 0
If not, try:
sudo modprobe button
Since acpi_listen does react to other buttons (volume, mute, mic, etc.) but not the power button,
it is likely that the power button event is already claimed and consumed by systemd (or possibly the BIOS/firmware directly),
and ACPI no longer forwards it to userland when systemd-logind is in control.
Check if the power button is caught by systemd-logind in the logs after pressing the button:
journalctl -f
If you see entries like:
systemd-logind[PID]: Power key pressed.
Then systemd-logind is handling the power button directly, bypassing acpid.
If so, look in /etc/systemd/logind.conf
This file controls how systemd handles power events. If the [HandlePowerKey] is not set to ignore,
then systemd takes over and suppresses ACPI delivery to acpid.
You can override it:
# /etc/systemd/logind.conf
HandlePowerKey=ignore
Then reload systemd:
sudo systemctl restart systemd-logind
Now try acpi_listen again.
Do you want to exit the Circus?
https://www.youtube.com/watch?v=ZJwQicZHp_c
Offline
Check if ACPI button driver is loaded
Run:lsmod | grep button
You should see something like:
button 16384 0
If not, try:
sudo modprobe button
Since acpi_listen does react to other buttons (volume, mute, mic, etc.) but not the power button,
it is likely that the power button event is already claimed and consumed by systemd (or possibly the BIOS/firmware directly),
and ACPI no longer forwards it to userland when systemd-logind is in control.Check if the power button is caught by systemd-logind in the logs after pressing the button:
journalctl -f
If you see entries like:
systemd-logind[PID]: Power key pressed.
Then systemd-logind is handling the power button directly, bypassing acpid.
If so, look in /etc/systemd/logind.conf
This file controls how systemd handles power events. If the [HandlePowerKey] is not set to ignore,
then systemd takes over and suppresses ACPI delivery to acpid.You can override it:
# /etc/systemd/logind.conf HandlePowerKey=ignore
Then reload systemd:
sudo systemctl restart systemd-logind
Now try acpi_listen again.
So this is what it looks like. TLDR: journalctl also does not register the power button. Maybe something broke because this laptop had ME cleaner ran and coreboot flashed wiping the stock BIOS.
IMO if there are not obvious next ideas, this is it and I'll live. It was fun because I learned a few things, but not having the power button handled by the system properly does not end the world for me (:
kamil$lsmod | grep button
button 24576 0
kamil$sudo journalctl -f
Jun 11 18:21:02 debian rtkit-daemon[951]: Supervising 4 threads of 2 processes of 1 users.
Jun 11 18:21:02 debian rtkit-daemon[951]: Supervising 4 threads of 2 processes of 1 users.
Jun 11 18:21:02 debian rtkit-daemon[951]: Successfully made thread 2578 of process 2449 owned by '1000' RT at priority 10.
Jun 11 18:21:02 debian rtkit-daemon[951]: Supervising 5 threads of 3 processes of 1 users.
Jun 11 18:21:14 debian rtkit-daemon[951]: Supervising 5 threads of 3 processes of 1 users.
Jun 11 18:21:14 debian rtkit-daemon[951]: Supervising 5 threads of 3 processes of 1 users.
Jun 11 18:21:29 debian systemd[1]: systemd-timedated.service: Deactivated successfully.
Jun 11 18:21:59 debian espanso[1729]: get_active_window reported an error
Jun 11 18:23:02 debian sudo[2843]: kamil : TTY=pts/0 ; PWD=/home/kamil ; USER=root ; COMMAND=/usr/bin/journalctl -f
Jun 11 18:23:02 debian sudo[2843]: pam_unix(sudo:session): session opened for user root(uid=0) by kamil(uid=1000)
Jun 11 18:23:45 debian espanso[1729]: get_active_window reported an error
Offline
One last try.
Try Listening to /dev/input Events
Your power button may be routed via an input event device instead of ACPI.
Install a utility to monitor input device events.
sudo apt install evtest
Then run:
sudo evtest
Look for a device like /dev/input/event3: Power Button
Select that device and press the power button and you should see output like:
Event: time ..., type 1 (EV_KEY), code 116 (KEY_POWER), value 1
Event: time ..., type 1 (EV_KEY), code 116 (KEY_POWER), value 0
If yes, that means the power button is working but bypasses ACPI, going through Linux’s input subsystem instead.
Do you want to exit the Circus?
https://www.youtube.com/watch?v=ZJwQicZHp_c
Offline
One last try.
Try Listening to /dev/input Events
Your power button may be routed via an input event device instead of ACPI.
Install a utility to monitor input device events.sudo apt install evtest
Then run:
sudo evtest
Look for a device like /dev/input/event3: Power Button
Select that device and press the power button and you should see output like:Event: time ..., type 1 (EV_KEY), code 116 (KEY_POWER), value 1 Event: time ..., type 1 (EV_KEY), code 116 (KEY_POWER), value 0
If yes, that means the power button is working but bypasses ACPI, going through Linux’s input subsystem instead.
That didn't do it either. Thanks for the deep dive into the problem, I really appreciate it and I hope this thread helps someone out in the future. If given all that you can say this might be a bug suitable for a report on an appropriate tracker, I'll submit it.
Offline
[ Generated in 0.015 seconds, 7 queries executed - Memory usage: 631.09 KiB (Peak: 664.37 KiB) ]