Re: [PATCH] HID: hid-asus.c: Maps key 0x35 (display off) to KEY_SCREENLOCK

[Vinícius Reis]

Em qui., 28 de out. de 2021 às 13:07, Dmitry Torokhov
<dmitry.torokhov@xxxxxxxxx> escreveu:
>
> Hi Vinícius,
>
> On Fri, Oct 8, 2021 at 3:24 PM Vinícius Angiolucci Reis
> <itsme.vreis@xxxxxxxxx> wrote:
> >
> > On Windows systems, ASUS laptops uses the "turn display off" key
> > (usually fn+f6) to turn both display and keyboard backlit off. On Linux
> > systems, this key has no effect at all since most desktop enviroments
> > don't deal with KEY_DISPLAY_OFF. By mapping it to KEY_SCREENLOCK
> > instead, would enable desktop environments to handle this key as a
> > screen lock intent from the user, out of the box.
>
> But is it the intent of the user? The fact that current desktop
> environments do not handle this key is not a reason to change kernel
> behavior.
>
> If screen lock is simply your preference then you can change the
> mapping via udev on your system without the need to patch the kernel.
>
> Thanks.
>
> --
> Dmitry

(Sorry, I'm sending this response again because it seems the first
attempt didn't make it to the mailing lists for some reason.)

Hi Dmitry,

I've picked up this particular key event because it would trigger a close
behavior to the one seen on Windows. It is far from being my preference,
which would be an exact mimic of the Windows behavior (and can be
achieved by xset dpms force on/off from user space).

The idea of this patch is to improve the user experience, by giving that key a
behavior as close as possible to what users might experience on Windows.
Because most Linux desktop environments also turn the display off after
locking the screen, this would be a good approximation to what happens on
Windows. I think it is more about giving (consistent) behavior to it
than changing it.

I agree it is possible to control that via udev or something else. But
most regular
users won't be able to do that, ending up with an unused key, though.
The hardcore user that would prefer a very different key behavior
could keep using
udev to do that.

So IMHO I think that setting this up on the kernel would be a good
approach in this case.

Thanks.

Vinícius