Re: Xen Virtual Keyboard modalias breaking uevents

[Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>]

On Thu, Apr 29, 2021 at 04:10:09PM -0400, Phillip Susi wrote:
> 
> It appears that input/input.c is responsible for the insane modalias
> length.  If I am reading input_print_modalias() correctly, it appends a
> "k" plus every key code that the keyboard supports,

Not every keyboard, but all keycodes above KEY_MIN_INTERESTING which is
KEY_MUTE, so that interested handlers could match on devices they are
interested in without first opening them or poking through sysfs.

> and the Xen Virtual
> Keyboard supports a lot of keycodes.  Why does it do this?

I don't know why Xen keyboard exports that many keycodes ;) In general,
my recommendation is to mirror the physical device when possible, and
instantiate several devices so there is 1:1 relationship between virtual
and physical devices.

In cases where it is not feasible, we need to be more careful about
declaring capabilities. For xen-kbdfront I do not think the keyboard
portion should be declaring keys from the various BTN_* ranges.


>  
> Phillip Susi writes:
> 
> > So I have finally drilled down to the modalias for the Xen Virtual
> > Keyboard driver being so long ( over 2KB ) that it causes an -ENOMEM
> > when trying to add it to the environment for uevents.  This causes
> > coldplug to fail, which causes the script doing coldplug as part of the
> > debian-installer init to fail, which causes a kernel panic when init
> > exits, which then for reasons I have yet to understand, causes the Xen
> > domU to reboot.
> >
> > Why is this modalias so huge?  Can we pare it down, or or is there
> > another solution to get uevents working on this device again?  Maybe the
> > environment block size needs to be increased?  I don't know.
> 

Thanks.

-- 
Dmitry