linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mario Limonciello <superm1@kernel.org>
To: "Armin Wolf" <W_Armin@gmx.de>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Shyam Sundar S K" <Shyam-sundar.S-k@amd.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
	"open list:INPUT (KEYBOARD, MOUSE, JOYSTICK,
	TOUCHSCREEN)..." <linux-input@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:AMD PMF DRIVER" <platform-driver-x86@vger.kernel.org>,
	Mario Limonciello <mario.limonciello@amd.com>
Subject: Re: [PATCH 1/2] Input: Add a helper for reporting a screen lock key sequence
Date: Wed, 16 Apr 2025 15:43:26 -0500	[thread overview]
Message-ID: <cebf59f2-5d81-41f9-8c4f-d51fcb514f86@kernel.org> (raw)
In-Reply-To: <7bb43fb5-83dd-4531-b835-77a8e937f54b@gmx.de>

On 4/16/2025 3:39 PM, Armin Wolf wrote:
> Am 07.04.25 um 17:27 schrieb Mario Limonciello:
> 
>> From: Mario Limonciello <mario.limonciello@amd.com>
>>
>> In the PC industry KEY_SCREENLOCK isn't used as frequently as it used
>> to be. Modern versions of Windows [1], GNOME and KDE support "META" + "L"
>> to lock the screen. Modern hardware [2] also sends this sequence of
>> events for keys with a silkscreen for screen lock.
>>
>> Introduced a helper input_report_lock_sequence() for drivers to utilize
>> if they want to send this sequence.
>>
>> Link: https://support.microsoft.com/en-us/windows/keyboard-shortcuts- 
>> in-windows-dcc61a57-8ff0-cffe-9796-cb9706c75eec [1]
>> Link: https://www.logitech.com/en-us/shop/p/k860-split- 
>> ergonomic.920-009166 [2]
>> Suggested-by: Armin Wolf <W_Armin@gmx.de>
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>> ---
>>   drivers/input/input.c | 20 ++++++++++++++++++++
>>   include/linux/input.h |  2 ++
>>   2 files changed, 22 insertions(+)
>>
>> diff --git a/drivers/input/input.c b/drivers/input/input.c
>> index ec4346f20efdd..dfeace85c4710 100644
>> --- a/drivers/input/input.c
>> +++ b/drivers/input/input.c
>> @@ -508,6 +508,26 @@ void input_copy_abs(struct input_dev *dst, 
>> unsigned int dst_axis,
>>   }
>>   EXPORT_SYMBOL(input_copy_abs);
>> +/**
>> + * input_report_lock_sequence - Report key combination to lock the 
>> screen
>> + * @dev: input device
>> + *
>> + * Key combination used in the PC industry since Windows 7 for 
>> locking display
>> + * is META + L. This is also used in GNOME and KDE by default.
>> + * See https://support.microsoft.com/en-us/windows/keyboard- 
>> shortcuts-in-windows-dcc61a57-8ff0-cffe-9796-cb9706c75eec
>> + */
> 
> Hi,
> 
> maybe it would make more sense to have the input subsystem transparently 
> translate between KEY_SCREENLOCK and this
> special screen lock sequence. This way there would be no room for 
> regressions as people could enable/disable this
> behavior via Kconfig.

Wouldn't all drivers that emit KEY_SCREENLOCK still need to be modified 
to have support to emit KEY_LEFTMETA and KEY_L?

Wouldn't that mean conditional code in every single driver based on the 
Kconfig?

Is that worth it?

> 
> Thanks,
> Armin Wolf
> 
>> +void input_report_lock_sequence(struct input_dev *dev)
>> +{
>> +    input_report_key(dev, KEY_LEFTMETA, 1);
>> +    input_report_key(dev, KEY_L, 1);
>> +    input_sync(dev);
>> +    input_report_key(dev, KEY_L, 0);
>> +    input_sync(dev);
>> +    input_report_key(dev, KEY_LEFTMETA, 0);
>> +    input_sync(dev);
>> +}
>> +EXPORT_SYMBOL(input_report_lock_sequence);
>> +
>>   /**
>>    * input_grab_device - grabs device for exclusive use
>>    * @handle: input handle that wants to own the device
>> diff --git a/include/linux/input.h b/include/linux/input.h
>> index 7d7cb0593a63e..16f7bef12f1c1 100644
>> --- a/include/linux/input.h
>> +++ b/include/linux/input.h
>> @@ -492,6 +492,8 @@ void input_set_abs_params(struct input_dev *dev, 
>> unsigned int axis,
>>   void input_copy_abs(struct input_dev *dst, unsigned int dst_axis,
>>               const struct input_dev *src, unsigned int src_axis);
>> +void input_report_lock_sequence(struct input_dev *dev);
>> +
>>   #define INPUT_GENERATE_ABS_ACCESSORS(_suffix, _item)            \
>>   static inline int input_abs_get_##_suffix(struct input_dev *dev,    \
>>                         unsigned int axis)        \


  reply	other threads:[~2025-04-16 20:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-07 15:27 [PATCH 1/2] Input: Add a helper for reporting a screen lock key sequence Mario Limonciello
2025-04-07 15:27 ` [PATCH 2/2] platform/x86/amd: pmf: Use meta + L for screen lock command Mario Limonciello
2025-04-16 20:39 ` [PATCH 1/2] Input: Add a helper for reporting a screen lock key sequence Armin Wolf
2025-04-16 20:43   ` Mario Limonciello [this message]
2025-04-16 23:06     ` Armin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cebf59f2-5d81-41f9-8c4f-d51fcb514f86@kernel.org \
    --to=superm1@kernel.org \
    --cc=Shyam-sundar.S-k@amd.com \
    --cc=W_Armin@gmx.de \
    --cc=dmitry.torokhov@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).