On Thu, Jun 26, 2025 at 12:53:02PM -0500, Mario Limonciello wrote:

On 6/26/25 12:44 PM, Dmitry Torokhov wrote:

quoted

Hi Mario,

On Thu, Jun 26, 2025 at 06:33:08AM -0500, Mario Limonciello wrote:

quoted

On 6/26/25 3:35 AM, Hans de Goede wrote:

quoted

Hi Mario,

On 25-Jun-25 23:58, Mario Limonciello wrote:

quoted

From: Mario Limonciello <mario.limonciello@amd.com>

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@kernel.org>
Fixes: 0f107573da417 ("Input: gpio_keys - handle the missing key press event in resume phase")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
   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);

There is already pm_stay_awake() above.

But that doesn't help with the fact that userspace gets KEY_POWER from this
and reacts to it.

quoted

quoted

quoted

quoted

   		}
   	}

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

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.

Nonetheless if this is dependent on an Android userspace problem could we
perhaps conditionalize it on CONFIG_ANDROID_BINDER_DEVICES?

No it is not only Android, other userspace may want to distinguish
between normal and "dark" resume based on keyboard or other user
activity.

Thanks.

In this specific case does the key passed up to satisfy this userspace
requirement and keep it awake need to specifically be a fabricated
KEY_POWER?

Or could we find a key that doesn't require some userspace to ignore
KEY_POWER?

Maybe something like KEY_RESERVED, KEY_FN, or KEY_POWER2?

The code makes no distinction between KEY_POWER and KEY_A or KEY_B, etc.
It simply passes event to userspace for processing.

You need to fix your userspace. Even with your tweak it is possible for
userspace to get a normal key event "too early" and turn off the screen
again, so you still need to handle this situation.

Thanks.

-- 
Dmitry