Re: [RFC] tty/sysrq: Add alternative SysRq key

[Greg Kroah-Hartman]

On Mon, Nov 15, 2021 at 03:48:59PM +0100, Andrzej Pietrasiewicz wrote:
> Jiri, Greg,
> 
> 
> W dniu 05.11.2021 o 15:06, Andrzej Pietrasiewicz pisze:
> > Hi Greg,
> > 
> > W dniu 05.11.2021 o 14:27, Greg Kroah-Hartman pisze:
> > > On Fri, Nov 05, 2021 at 02:01:23PM +0100, Andrzej Pietrasiewicz wrote:
> > > > Hi,
> > > > 
> > > > W dniu 04.11.2021 o 15:17, Andrzej Pietrasiewicz pisze:
> > > > > Hi Maciej,
> > > > > 
> > > > > W dniu 04.11.2021 o 14:13, Maciej W. Rozycki pisze:
> > > > > > On Thu, 4 Nov 2021, Maciej W. Rozycki wrote:
> > > > > > 
> > > > > > >    The reason for this is with their more recent laptops Lenovo in their
> > > > > > > infinite wisdom have placed the <PrintScreen> key (which in a traditional
> > > > > > > PS/2-keyboard manner produces <SysRq> when combined with <Alt>) in their
> > > > > > > keyboards between the right <Alt> and <Ctrl> keys.  With thumbs not being
> > > > > > > as accurate as other fingers (and the overall misdesign of the keyboard
> > > > > > > and touchpad interface) you can imagine how often I have inadvertently hit
> > > > > > > <SysRq> combined with a letter key, wreaking havoc to my system (and of
> > > > > > > course I want to keep the key enabled for times when I do need it).
> > > > > > 
> > > > > >    On second thoughts this can be disabled with `setkeycodes 54 0' once we
> > > > > > do have an alternative combination available.
> > > > > > 
> > > > > 
> > > > > Doesn't `setkeycodes` affect only one keyboard? What if there are more
> > > > > keyboards connected to a machine?
> > > > > 
> > > > >   From drivers/tty/vt/keyboard.c:
> > > > > 
> > > > > /*
> > > > >    * Translation of scancodes to keycodes. We set them on only the first
> > > > >    * keyboard in the list that accepts the scancode and keycode.
> > > > >    * Explanation for not choosing the first attached keyboard anymore:
> > > > >    *  USB keyboards for example have two event devices: one for all "normal"
> > > > >    *  keys and one for extra function keys (like "volume up", "make coffee",
> > > > >    *  etc.). So this means that scancodes for the extra function keys won't
> > > > >    *  be valid for the first event device, but will be for the second.
> > > > >    */
> > > > > 
> > > > 
> > > > My second thoughts: if we run `setkeycodes` to map, say, F10 as SysRq,
> > > > don't we lose F10?
> > > 
> > > The fact that this patch adds a "new" sysrq key no matter what is a
> > > non-starter, please think through the consequences of such a change...
> > > 
> > 
> > I wouldn't say this RFC adds a "new" sysrq no matter what. It does so only
> > when the input device (keyboard) does _not_ have SysRq key at all. So I would
> > say that this patch adds a replacement SysRq key if the SysRq key proper is
> > _physically_ absent. Which seems not such a bad thing to me. The problem I'm
> > trying to solve is exactly this: what to use as SysRq if there's no SysRq?
> > 
> 
> What approach is acceptable then? Any criteria other than "go guess"?
> Is "connect an external keyboard" the _only_ choice Linux wants to offer
> to its users in case of devices such as e.g. Chromebooks?

I don't see how this patch only kicks in if a keyboard does not have a
sysrq key present given that you are allowing a different key to be used
as it also.

Anyway, it's an RFC, which can't be applied to the tree so I'll wait to
review it "for real" when you feel comfortable enough to submit it for
inclusion.

thanks,

greg k-h