From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Phillip Susi <phill@thesusis.net>
Cc: xen-devel@lists.xenproject.org, linux-input@vger.kernel.org
Subject: Re: Xen Virtual Keyboard modalias breaking uevents
Date: Thu, 29 Apr 2021 15:29:15 -0700 [thread overview]
Message-ID: <YIszOwADJ8jdBov8@google.com> (raw)
In-Reply-To: <87fsz84zn1.fsf@vps.thesusis.net>
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
next prev parent reply other threads:[~2021-04-29 22:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-29 19:08 Xen Virtual Keyboard modalias breaking uevents Phillip Susi
2021-04-29 20:10 ` Phillip Susi
2021-04-29 22:29 ` Dmitry Torokhov [this message]
2021-04-30 0:11 ` Phillip Susi
2021-04-30 0:35 ` Dmitry Torokhov
2021-04-30 0:57 ` Phillip Susi
2021-04-30 13:16 ` Phillip Susi
2021-05-06 14:36 ` [PATCH] Xen Keyboard: don't advertise every key known to man Phillip Susi
2021-05-06 20:26 ` Dmitry Torokhov
2021-05-18 16:20 ` Phillip Susi
2021-05-18 17:13 ` Phillip Susi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YIszOwADJ8jdBov8@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=phill@thesusis.net \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).