From: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Pavel Machek <pavel@ucw.cz>,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.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: Thu, 4 Nov 2021 15:17:22 +0100 [thread overview]
Message-ID: <9fbe062a-2992-0361-e72a-f2b1523143dd@collabora.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2111041311260.57165@angie.orcam.me.uk>
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.
*/
Regards,
Andrzej
next prev parent reply other threads:[~2021-11-04 14:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-03 15:54 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-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 [this message]
2021-11-05 13:01 ` Andrzej Pietrasiewicz
2021-11-05 13:27 ` Greg Kroah-Hartman
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=9fbe062a-2992-0361-e72a-f2b1523143dd@collabora.com \
--to=andrzej.p@collabora.com \
--cc=dmitry.torokhov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®