All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Cc: "Maciej W. Rozycki" <macro@orcam.me.uk>,
	Pavel Machek <pavel@ucw.cz>,
	linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Jiri Slaby <jirislaby@kernel.org>,
	kernel@collabora.com
Subject: Re: [RFC] tty/sysrq: Add alternative SysRq key
Date: Fri, 5 Nov 2021 14:27:17 +0100	[thread overview]
Message-ID: <YYUxNaDG0DquQvke@kroah.com> (raw)
In-Reply-To: <b3a917ef-8a70-80b6-8c79-48ce4628b9e8@collabora.com>

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...

So no, as-is, this change is not acceptable at all, and I would be
amazed if anyone would ship such a thing.

thanks,

greg k-h

  reply	other threads:[~2021-11-05 13:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-03 15:54 [RFC] tty/sysrq: Add alternative SysRq key Andrzej Pietrasiewicz
2021-11-03 16:19 ` Randy Dunlap
2021-11-04  8:44   ` Andrzej Pietrasiewicz
2021-11-04  9:34   ` Andrzej Pietrasiewicz
2021-11-04  9:52     ` Greg Kroah-Hartman
2021-11-03 18:44 ` kernel test robot
2021-11-04 12:01 ` Pavel Machek
2021-11-04 12:21   ` Andrzej Pietrasiewicz
2021-11-04 13:07     ` Maciej W. Rozycki
2021-11-04 13:13       ` Maciej W. Rozycki
2021-11-04 14:17         ` Andrzej Pietrasiewicz
2021-11-05 13:01           ` Andrzej Pietrasiewicz
2021-11-05 13:27             ` Greg Kroah-Hartman [this message]
2021-11-05 14:06               ` Andrzej Pietrasiewicz
2021-11-15 14:48                 ` Andrzej Pietrasiewicz
2021-11-15 15:09                   ` Greg Kroah-Hartman

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=YYUxNaDG0DquQvke@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=andrzej.p@collabora.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jirislaby@kernel.org \
    --cc=kernel@collabora.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@orcam.me.uk \
    --cc=pavel@ucw.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.