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 m
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?
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
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
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 keycod
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
