Re: [PATCH 3/4] Input: Ignore the KEY_POWER events if hibernation is in progress

["Rafael J. Wysocki" <rafael@kernel.org>]

On Tue, Nov 25, 2025 at 11:23 AM Muhammad Usama Anjum
<usama.anjum@collabora.com> wrote:
>
> On 11/24/25 11:50 PM, Rafael J. Wysocki wrote:
> > On Fri, Nov 7, 2025 at 7:45 PM Muhammad Usama Anjum
> > <usama.anjum@collabora.com> wrote:
> >>
> >> Input (Serio) drivers call input_handle_event(). Although the serio
> >> drivers have duplicate events, they have separate code path and call
> >> input_handle_event(). Ignore the KEY_POWER such that this event isn't
> >> sent to the userspace if hibernation is in progress.
> >
> > Your change affects suspend too.
> >
> > Also, what's the goal you want to achieve?
> Two goals:
> * Don't send event to userspace
> * Set pm_wakeup for hibernation cancellation for non-acpi devices (This api
>   call should be tested on non-acpi devices such as arm board to see if it
>   helps. I don't have an arm board in hand)
>
> >
> >> Abort the hibernation by calling pm_wakeup_dev_event(). In case of serio,
> >> doesn't have wakeup source registered, this call doesn't do anything.
> >> But there may be other input drivers which will require this.
> >>
> >> Without this, the event is sent to the userspace and it suspends the
> >> device after hibernation cancellation.
> >
> > I think that's because user space handles it this way, isn't it?
>
> Yes, it depends on how userspace handles such events. There are different settings
> configured for systemd-logind when power event is received. The purpose is to consume
> this event to cancel the hibernation without letting userspace know about it.
>
> Thinking more about it, I wasn't sure if all of such events are compulsory to be
> delivered to userspace. But then I found an example: In acpi_button_notify(), all
> such events are not sent to userspace if button is suspended. So it seems okay to
> not send this as well and just consume in the kernel.

You want the given key (and it doesn't matter whether or not this is
KEY_POWER or something else) to play two roles.  One of them is to
send a specific key code to user space and let it handle the keypress
as it wants.  This is how it works most of the time.  The second one
is to wake up the system from sleep (and I'm not sure why you want to
limit this to hibernation) in which case the key code will not be sent
to user space.

For this to work, you need to switch between the two modes quite
precisely and checking things like pm_sleep_transition_in_progress()
(which is only used for debug and its raciness is not relevant there)
is not sufficient for this purpose.  That's what the "suspended" flag
in the ACPI button driver is for.