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

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Fri, Nov 05, 2021 at 12:16:45PM -0300, Vinícius Reis wrote:
> Em qui., 28 de out. de 2021 às 13:07, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> escreveu:
> >
> > Hi Vinícius,
> >
> > On Fri, Oct 8, 2021 at 3:24 PM Vinícius Angiolucci Reis
> > <itsme.vreis@gmail.com> 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.

I am sorry, I disagree. I understand that patching the kernel might be
easier than implementing new shortcut/behavior in various desktop
environments, but that does not make it the right approach.

Thanks.

-- 
Dmitry