Xen Keyboard: don't advertise every key known to man

For reasons I still don't understand, the input subsystem allows
input devices to advertise what keys they have, and adds this
information to the modalias for the device.  The Xen Virtual
Keyboard was advertising every known key, which resulted in a
modalias string over 2 KiB in length, which caused uevents to
fail with -ENOMEM ( when trying to add the modalias to the env ).
Remove this advertisement.
---
 drivers/input/misc/xen-kbdfront.c | 5 -----
 1 file changed, 5 deletions(-)

On Thu, May 06, 2021 at 02:36:54PM +0000, Phillip Susi wrote:
> For reasons I still don't understand, the input subsystem allows
> input devices to advertise what keys they have, and adds this
> information to the modalias for the device.  The Xen Virtual
> Keyboard was advertising every known key, which resulted in a
> modalias string over 2 KiB in length, which caused uevents to
> fail with -ENOMEM ( when trying to add the modalias to the env ).
> Remove this advertisement.
> ---
>  drivers/input/misc/xen-kbdfront.c | 5 -----
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> index 4ff5cd2a6d8d..d4bd558afda9 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -254,11 +254,6 @@ static int xenkbd_probe(struct xenbus_device *dev,
>  		kbd->id.product = 0xffff;
>  
>  		__set_bit(EV_KEY, kbd->evbit);
> -		for (i = KEY_ESC; i < KEY_UNKNOWN; i++)
> -			__set_bit(i, kbd->keybit);
> -		for (i = KEY_OK; i < KEY_MAX; i++)
> -			__set_bit(i, kbd->keybit);
> -

By doing this you are stopping delivery of all key events from this
device.

Thanks.

Dmitry Torokhov writes:

> By doing this you are stopping delivery of all key events from this

> device.


It does?  How does the PS/2 keyboard driver work then?  It has no way of
knowning what keys the keyboard has other than waiting to see what scan
codes are emitted.

If the keys must be advertised in order to emit them at runtime, then I
see no other possible fix than to remove the codes from the modalias
string in the input subsystem.  Or maybe allow certain drivers that
don't know to set some sort of flag that allows them to emit all codes
at runtime, but NOT advertise them so you end up with a mile long
modalias.

Phillip Susi writes:

> Dmitry Torokhov writes:

>

>> By doing this you are stopping delivery of all key events from this

>> device.


Hrm... I don't have very many "interesting" keys to test, but when I hit
the menu key, I see KEY_COMPOSE, which is > KEY_MIN_INTERESTING.  When I
press the button to have my vnc client send a windows key, I see
KEY_LEFTCTRL+KEY_ESC.  I also see KEY_PAUSE when I hit that key and it
is also "interesting".  I get the same thing with or without this patch,
so it does not appear to be breaking delivery of the keys that are no
longer being advertised.

Oddly though, libinput list-devices does not even show the Xen Virtual
Keyboard.  It's sysfs path is /sys/class/input/input1, but it also does
not have a device node in /dev/input so I can't even ask libinput to
only monitor that device.

Ok... this is really odd.. it does show the device without this patch,
and not with it.  The input events I was seeing were coming through the
"AT Translated Set 2 keyboard" and no events come though the Xen Virtual
Keyboard ( even without this patch ).  This makes me wonder why we have
this device at all?