Re: [PATCH 3/6] tty/sysrq: Allow configurable SysRq key

[Andrzej Pietrasiewicz <andrzej.p@xxxxxxxxxxxxx>]

Hi Dmitry,

W dniu 11.05.2020 o 20:01, Dmitry Torokhov pisze:
> Hi Andrzej,
>
> On Mon, May 11, 2020 at 03:59:15PM +0200, Andrzej Pietrasiewicz wrote:
> > There are existing machines which don't have SysRq key, e.g. chromebooks.
> > This patch allows configuring which key acts as SysRq. The value is passed
> > with sysrq's module parameter.
> >
> > Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@xxxxxxxxxxxxx>
> > ---
> >   drivers/tty/sysrq.c | 14 +++++++++++---
> >   1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
> > index 93202fc24308..ebad9799fdc0 100644
> > --- a/drivers/tty/sysrq.c
> > +++ b/drivers/tty/sysrq.c
> > @@ -604,6 +604,7 @@ EXPORT_SYMBOL(handle_sysrq);
> >   
> >   #ifdef CONFIG_INPUT
> >   static int sysrq_reset_downtime_ms;
> > +static unsigned short sysrq_key = KEY_SYSRQ;
> >   
> >   /* Simple translation table for the SysRq keys */
> >   static const unsigned char sysrq_xlate[KEY_CNT] =
> > @@ -735,10 +736,10 @@ static void sysrq_reinject_alt_sysrq(struct work_struct *work)
> >   
> >   		/* Simulate press and release of Alt + SysRq */
> >   		input_inject_event(handle, EV_KEY, alt_code, 1);
> > -		input_inject_event(handle, EV_KEY, KEY_SYSRQ, 1);
> > +		input_inject_event(handle, EV_KEY, sysrq_key, 1);
> >   		input_inject_event(handle, EV_SYN, SYN_REPORT, 1);
> >   
> > -		input_inject_event(handle, EV_KEY, KEY_SYSRQ, 0);
> > +		input_inject_event(handle, EV_KEY, sysrq_key, 0);
> >   		input_inject_event(handle, EV_KEY, alt_code, 0);
> >   		input_inject_event(handle, EV_SYN, SYN_REPORT, 1);
>
> Unfortunately this means that if I connect my external keyboard to
> chromebook SysRq there will stop working, which is not great. If we want
> to support this we need to figure out how to make this handling
> per-device.

I see your point.

So what you envision is SysRq key being configured for each input device
separately. I can see these problems:

- How to attach such a configuration information to each specific
device instance? It is easy if done framework-wise, but gets messy
if done per-device. And we are talking per-device rather than per-driver.

- If a user has multiple USB keyboards connected (possibly through a cascade
of hubs), how would they know which key is valid for which keyboard?

Wouldn't it be better if such a piece of configuration were valid for the
whole system instead of per-device?

Andrzej