On 6/26/2025 1:45 PM, Hans de Goede wrote:
Hi,
On 26-Jun-25 20:42, Mario Limonciello wrote:
On 6/26/2025 1:37 PM, Hans de Goede wrote:
Hi Mario,
On Thu, Jun 26, 2025 at 06:33:08AM -0500, Mario Limonciello wrote:
On 6/26/25 3:35 AM, Hans de Goede wrote:
Hi Mario,
On 25-Jun-25 23:58, Mario Limonciello wrote:
From: Mario Limonciello <mario.limonciello@xxxxxxx>
Sending an input event to wake a system does wake it, but userspace picks
up the keypress and processes it. This isn't the intended behavior as it
causes a suspended system to wake up and then potentially turn off if
userspace is configured to turn off on power button presses.
Instead send a PM wakeup event for the PM core to handle waking the system.
Cc: Hans de Goede <hansg@xxxxxxxxxx>
Fixes: 0f107573da417 ("Input: gpio_keys - handle the missing key press event in resume phase")
Signed-off-by: Mario Limonciello <mario.limonciello@xxxxxxx>
---
drivers/input/keyboard/gpio_keys.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 773aa5294d269..4c6876b099c43 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -420,12 +420,7 @@ static irqreturn_t gpio_keys_gpio_isr(int irq, void *dev_id)
pm_stay_awake(bdata->input->dev.parent);
if (bdata->suspended &&
(button->type == 0 || button->type == EV_KEY)) {
- /*
- * Simulate wakeup key press in case the key has
- * already released by the time we got interrupt
- * handler to run.
- */
- input_report_key(bdata->input, button->code, 1);
+ pm_wakeup_event(bdata->input->dev.parent, 0);
}
}
Hmm, we have the same problem on many Bay Trail / Cherry Trail
windows 8 / win10 tablets, so this has been discussed before and e.g.
Android userspace actually needs the button-press (evdev) event to not
immediately go back to sleep, so a similar patch has been nacked in
the past.
At least for GNOME this has been fixed in userspace by ignoring
power-button events the first few seconds after a resume from suspend.
The default behavior for logind is:
HandlePowerKey=poweroff
Right note poweroff not suspend, GNOME inhibits logind's power-button
handling and substitutes its own handling which is done by gsd-media-keys.
Can you share more about what version of GNOME has a workaround?
This was actually GNOME (on Ubuntu 24.04) that I found this issue.
See:
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/main/plugins/media-keys/gsd-media-keys-manager.c?ref_type=heads#L94
and the code in that file using that define.
Regards,
Hans
This is pretty ancient, it's part of GNOME 40 and later. Ubuntu 24.04 is GNOME 46.
Right, this power-button evdev key event on resume causing an immediate
suspend again is a pretty old problem. When I said "discussed before"
I meant discussed quite a while ago :)
Regards,
Hans
:)
I'm quite used to most platforms using ACPI power button which doesn't
send a key press event during the resume sequence, so this is the first
exposure for me to it.
