On Thu, Jun 26, 2025 at 05:21:35PM -0500, Mario Limonciello wrote:

On 6/26/2025 2:40 PM, Dmitry Torokhov wrote:

quoted

On Thu, Jun 26, 2025 at 09:31:12PM +0200, Rafael J. Wysocki wrote:

quoted

On Thu, Jun 26, 2025 at 9:28 PM Dmitry Torokhov
[off-list ref] wrote:

quoted

On Thu, Jun 26, 2025 at 09:18:56PM +0200, Rafael J. Wysocki wrote:

quoted

On Thu, Jun 26, 2025 at 9:16 PM Hans de Goede [off-list ref] wrote:

quoted

Hi,

On 26-Jun-25 21:14, Dmitry Torokhov wrote:

quoted

On Thu, Jun 26, 2025 at 08:57:30PM +0200, Hans de Goede wrote:

quoted

Hi,

On 26-Jun-25 20:48, Dmitry Torokhov wrote:

quoted

On Thu, Jun 26, 2025 at 01:20:54PM -0500, Mario Limonciello wrote:

[...]

quoted

quoted

quoted

quoted

quoted

quoted

I want to note this driver works quite differently than how ACPI power
button does.

You can see in acpi_button_notify() that the "keypress" is only forwarded
when not suspended [1].  Otherwise it's just wakeup event (which is what my
patch was modeling).

https://github.com/torvalds/linux/blob/v6.16-rc3/drivers/acpi/button.c#L461
[1]

If you check acpi_button_resume() you will see that the events are sent
from there. Except that for some reason they chose to use KEY_WAKEUP and
not KEY_POWER, oh well. Unlike acpi button driver gpio_keys is used on
multiple other platforms.

Interesting, but the ACPI button code presumably only does this on resume
for a normal press while the system is awake it does use KEY_POWER, right ?

Yes. It is unclear to me why they chose to mangle the event on wakeup,
it does not seem to be captured in the email discussions or in the patch
description.

I assume they did this to avoid the immediate re-suspend on wakeup by
power-button issue. GNOME has a workaround for this, but I assume that
some userspace desktop environments are still going to have a problem
with this.

It was done for this reason IIRC, but it should have been documented
more thoroughly.

I assert that it should not have been done and instead dealt with in
userspace. There are numerous drivers in the kernel emitting
KEY_POWER. Let userspace decide how to handle this, what keys to ignore,
what keys to process and when.

Please see my last message in this thread (just sent) and see the
changelog of commit 16f70feaabe9 ("ACPI: button: trigger wakeup key
events").

This appears to be about cases when no event would be signaled to user
space at all (power button wakeup from ACPI S3).

Ahh, in S3 we do not know if we've been woken up with Sleep or Power
button, right? So we can not send the "right" event code and use
"neutral" KEY_WAKEUP for both. Is this right?

Thanks.

I did some more experiments with this affected system that started this
thread (which uses s2idle).

I only applied patch 3 in this series to help the debounce behavior and
figure out impacts from patch 4 with existing Linux userspace.

If suspended using systemd in GNOME (click the GUI button) on Ubuntu 24.04
the GNOME workaround mitigates this problem and no visible impact.

If I suspend by hand using the kernel interface and then press power button
to wake:

# echo mem | sudo tee /sys/power/state:

* When GNOME is running:
I get the shutdown popup and it eventually shuts down.

* When GNOME isn't running (just on a VT):
System shuts down.

For the latter you may want to raise an issue with systemd, and for the
former I guess it is being too clever and does not activate the
workaround if suspend was not initiated by it? I think Gnome is being
too careful.

Thanks.

-- 
Dmitry