Mailing List Archive

Xen Virtual Keyboard modalias breaking uevents
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.
Re: Xen Virtual Keyboard modalias breaking uevents [ In reply to ]
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, and the Xen Virtual
Keyboard supports a lot of keycodes. Why does it do this?

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.
Re: Xen Virtual Keyboard modalias breaking uevents [ In reply to ]
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
Re: Xen Virtual Keyboard modalias breaking uevents [ In reply to ]
Dmitry Torokhov writes:

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

/Shouldn't/ they be reading sysfs attributes to find that information
out though? Isn't modalias there to help modprobe find the right module
that wants to bind to this device, which doesn't happen for input
devices? If user space is looking at this information then isn't it
getting it by reading from sysfs anyway?

What in user space looks at input devices other than X and Wayland? And
those aren't looking for particular "interesting" keys are they?

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

Xen guys: any input as to why it supports so many "interesting" keys?
Re: Xen Virtual Keyboard modalias breaking uevents [ In reply to ]
On Thu, Apr 29, 2021 at 08:11:03PM -0400, Phillip Susi wrote:
>
> Dmitry Torokhov writes:
>
> > 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.
>
> /Shouldn't/ they be reading sysfs attributes to find that information
> out though? Isn't modalias there to help modprobe find the right module
> that wants to bind to this device, which doesn't happen for input
> devices? If user space is looking at this information then isn't it
> getting it by reading from sysfs anyway?

Userspace may or may not have access to sysfs (it does not have to be
mounted) and one can have modules (input handlers) that want to bind to
a specific device (see joydev, mousedev as examples, although they are
not looking for specific keys).

>
> What in user space looks at input devices other than X and Wayland? And
> those aren't looking for particular "interesting" keys are they?
>
> > 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.
>
> Xen guys: any input as to why it supports so many "interesting" keys?
>

Thanks.

--
Dmitry
Re: Xen Virtual Keyboard modalias breaking uevents [ In reply to ]
Dmitry Torokhov writes:

> Userspace may or may not have access to sysfs (it does not have to be
> mounted)

How would userspace even enumerate the input devices and read their
modalias without sysfs?
Re: Xen Virtual Keyboard modalias breaking uevents [ In reply to ]
Dmitry Torokhov writes:

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

I'm still trying to wrap my head around why keys are even declared in
the first place. PS/2 ports have no idea what keys are on the keyboard
plugged into them, so I guess they don't declare any? And that doesn't
stop them from emitting any of the scan codes, so what is the use in
declaring them in the first place?

A lot of "interesting" buttons don't seem very interesting to me, such
as left and right parenthesis. Is a user space mail program really
going to bypass X11/wayland and open input devices directly to look for
someone to press the "send mail" key? Even if it did, why would it only
want to open a keyboard that advertises that it has such a key instead
of listening to all keyboards? Even if all USB keyboards report all of
their special keys, the fact that you could still have a PS/2 keyboard
that has a "send mail" key on it means that the reporting function can
not be relied on and so you just have to listen on all keyboards anyhow.

I guess as long as not reporting keys doesn't stop you from using them,
then the Xen Virtual Keyboard driver should just report none, like the
PS/2 keyboard driver.