All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.