lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 5 Nov 2021 14:55:17 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Vinícius Reis <itsme.vreis@...il.com>
Cc:     Jiri Kosina <jikos@...nel.org>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>, angiolucci@...il.com
Subject: Re: [PATCH] HID: hid-asus.c: Maps key 0x35 (display off) to
 KEY_SCREENLOCK

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@...il.com> escreveu:
> >
> > Hi Vinícius,
> >
> > On Fri, Oct 8, 2021 at 3:24 PM Vinícius Angiolucci Reis
> > <itsme.vreis@...il.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ