Message-ID: <cbf3ab37-21d9-467c-8181-b5a08e28c364@collabora.com>
Date: Tue, 25 Nov 2025 21:05:11 +0500
From: Muhammad Usama Anjum <usama.anjum@...labora.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: usama.anjum@...labora.com, Len Brown <lenb@...nel.org>,
 Pavel Machek <pavel@...nel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Danilo Krummrich <dakr@...nel.org>,
 Dmitry Torokhov <dmitry.torokhov@...il.com>,
 Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <peterz@...radead.org>,
 linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-pm@...r.kernel.org, linux-input@...r.kernel.org, kernel@...labora.com,
 superm1@...nel.org
Subject: Re: [PATCH 3/4] Input: Ignore the KEY_POWER events if hibernation is
 in progress

On 11/25/25 5:25 PM, Rafael J. Wysocki wrote:
> On Tue, Nov 25, 2025 at 11:23 AM Muhammad Usama Anjum
> <usama.anjum@...labora.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@...labora.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.
I see. I'll add a suspended flag just like the acpi button and use it here.
Thank you so much for explaining.

-- 
---
Thanks,
Usama

Powered by blists - more mailing lists