xen kbdfront registers itself as being able to deliver *any* key since
it doesn't know what keys the backend may produce.
Unfortunately, the generated modalias gets too large and uevent creation
fails with -ENOMEM.
This can lead to gdm not using the keyboard since there is no seat
associated [1] and the debian installer crashing [2].
Trim the ranges of key capabilities by removing some BTN_* ranges.
While doing this, some neighboring undefined ranges are removed to trim
it further.
An upper limit of KEY_KBD_LCD_MENU5 is still too large. Use an upper
limit of KEY_BRIGHTNESS_MENU.
This removes:
BTN_DPAD_UP(0x220)..BTN_DPAD_RIGHT(0x223)
Empty space 0x224..0x229
Empty space 0x28a..0x28f
KEY_MACRO1(0x290)..KEY_MACRO30(0x2ad)
KEY_MACRO_RECORD_START 0x2b0
KEY_MACRO_RECORD_STOP 0x2b1
KEY_MACRO_PRESET_CYCLE 0x2b2
KEY_MACRO_PRESET1(0x2b3)..KEY_MACRO_PRESET3(0xb5)
Empty space 0x2b6..0x2b7
KEY_KBD_LCD_MENU1(0x2b8)..KEY_KBD_LCD_MENU5(0x2bc)
Empty space 0x2bd..0x2bf
BTN_TRIGGER_HAPPY(0x2c0)..BTN_TRIGGER_HAPPY40(0x2e7)
Empty space 0x2e8..0x2ff
The modalias shrinks from 2082 to 1550 bytes.
A chunk of keys need to be removed to allow the keyboard to be used.
This may break some functionality, but the hope is these macro keys are
uncommon and don't affect any users.
[1] https://github.com/systemd/systemd/issues/22944
[2] https://lore.kernel.org/xen-devel/[email protected]/T/
Cc: Phillip Susi <[email protected]>
Cc: [email protected]
Signed-off-by: Jason Andryuk <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
---
v3:
Add Mattijs R-b
Put /* and */ on separate lines
---
drivers/input/misc/xen-kbdfront.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index 67f1c7364c95..d59ba8f9852e 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -256,7 +256,16 @@ static int xenkbd_probe(struct xenbus_device *dev,
__set_bit(EV_KEY, kbd->evbit);
for (i = KEY_ESC; i < KEY_UNKNOWN; i++)
__set_bit(i, kbd->keybit);
- for (i = KEY_OK; i < KEY_MAX; i++)
+ /*
+ * In theory we want to go KEY_OK..KEY_MAX, but that grows the
+ * modalias line too long. There is a gap of buttons from
+ * BTN_DPAD_UP..BTN_DPAD_RIGHT and KEY_ALS_TOGGLE is the next
+ * defined. Then continue up to KEY_BRIGHTNESS_MENU as an upper
+ * limit.
+ */
+ for (i = KEY_OK; i < BTN_DPAD_UP; i++)
+ __set_bit(i, kbd->keybit);
+ for (i = KEY_ALS_TOGGLE; i <= KEY_BRIGHTNESS_MENU; i++)
__set_bit(i, kbd->keybit);
ret = input_register_device(kbd);
--
2.41.0
Hi Dmitry,
Do you have any feedback or can you pick this up?
Thanks,
Jason
On Wed, Oct 11, 2023 at 3:34 PM Jason Andryuk <[email protected]> wrote:
>
> xen kbdfront registers itself as being able to deliver *any* key since
> it doesn't know what keys the backend may produce.
>
> Unfortunately, the generated modalias gets too large and uevent creation
> fails with -ENOMEM.
>
> This can lead to gdm not using the keyboard since there is no seat
> associated [1] and the debian installer crashing [2].
>
> Trim the ranges of key capabilities by removing some BTN_* ranges.
> While doing this, some neighboring undefined ranges are removed to trim
> it further.
>
> An upper limit of KEY_KBD_LCD_MENU5 is still too large. Use an upper
> limit of KEY_BRIGHTNESS_MENU.
>
> This removes:
> BTN_DPAD_UP(0x220)..BTN_DPAD_RIGHT(0x223)
> Empty space 0x224..0x229
>
> Empty space 0x28a..0x28f
> KEY_MACRO1(0x290)..KEY_MACRO30(0x2ad)
> KEY_MACRO_RECORD_START 0x2b0
> KEY_MACRO_RECORD_STOP 0x2b1
> KEY_MACRO_PRESET_CYCLE 0x2b2
> KEY_MACRO_PRESET1(0x2b3)..KEY_MACRO_PRESET3(0xb5)
> Empty space 0x2b6..0x2b7
> KEY_KBD_LCD_MENU1(0x2b8)..KEY_KBD_LCD_MENU5(0x2bc)
> Empty space 0x2bd..0x2bf
> BTN_TRIGGER_HAPPY(0x2c0)..BTN_TRIGGER_HAPPY40(0x2e7)
> Empty space 0x2e8..0x2ff
>
> The modalias shrinks from 2082 to 1550 bytes.
>
> A chunk of keys need to be removed to allow the keyboard to be used.
> This may break some functionality, but the hope is these macro keys are
> uncommon and don't affect any users.
>
> [1] https://github.com/systemd/systemd/issues/22944
> [2] https://lore.kernel.org/xen-devel/[email protected]/T/
>
> Cc: Phillip Susi <[email protected]>
> Cc: [email protected]
> Signed-off-by: Jason Andryuk <[email protected]>
> Reviewed-by: Mattijs Korpershoek <[email protected]>
> ---
> v3:
> Add Mattijs R-b
> Put /* and */ on separate lines
> ---
> drivers/input/misc/xen-kbdfront.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> index 67f1c7364c95..d59ba8f9852e 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -256,7 +256,16 @@ static int xenkbd_probe(struct xenbus_device *dev,
> __set_bit(EV_KEY, kbd->evbit);
> for (i = KEY_ESC; i < KEY_UNKNOWN; i++)
> __set_bit(i, kbd->keybit);
> - for (i = KEY_OK; i < KEY_MAX; i++)
> + /*
> + * In theory we want to go KEY_OK..KEY_MAX, but that grows the
> + * modalias line too long. There is a gap of buttons from
> + * BTN_DPAD_UP..BTN_DPAD_RIGHT and KEY_ALS_TOGGLE is the next
> + * defined. Then continue up to KEY_BRIGHTNESS_MENU as an upper
> + * limit.
> + */
> + for (i = KEY_OK; i < BTN_DPAD_UP; i++)
> + __set_bit(i, kbd->keybit);
> + for (i = KEY_ALS_TOGGLE; i <= KEY_BRIGHTNESS_MENU; i++)
> __set_bit(i, kbd->keybit);
>
> ret = input_register_device(kbd);
> --
> 2.41.0
>
Hi Dmitry,
Do you have any feedback, or can you pick up this patch? It solves a
real issue affecting udev, which crashes the Debian installer and
breaks the mouse for Gnome.
Or would you be okay if this patch went in via the Xen tree?
Thanks,
Jason
On Wed, Nov 1, 2023 at 10:11 AM Jason Andryuk <[email protected]> wrote:
>
> Hi Dmitry,
>
> Do you have any feedback or can you pick this up?
>
> Thanks,
> Jason
>
> On Wed, Oct 11, 2023 at 3:34 PM Jason Andryuk <[email protected]> wrote:
> >
> > xen kbdfront registers itself as being able to deliver *any* key since
> > it doesn't know what keys the backend may produce.
> >
> > Unfortunately, the generated modalias gets too large and uevent creation
> > fails with -ENOMEM.
> >
> > This can lead to gdm not using the keyboard since there is no seat
> > associated [1] and the debian installer crashing [2].
> >
> > Trim the ranges of key capabilities by removing some BTN_* ranges.
> > While doing this, some neighboring undefined ranges are removed to trim
> > it further.
> >
> > An upper limit of KEY_KBD_LCD_MENU5 is still too large. Use an upper
> > limit of KEY_BRIGHTNESS_MENU.
> >
> > This removes:
> > BTN_DPAD_UP(0x220)..BTN_DPAD_RIGHT(0x223)
> > Empty space 0x224..0x229
> >
> > Empty space 0x28a..0x28f
> > KEY_MACRO1(0x290)..KEY_MACRO30(0x2ad)
> > KEY_MACRO_RECORD_START 0x2b0
> > KEY_MACRO_RECORD_STOP 0x2b1
> > KEY_MACRO_PRESET_CYCLE 0x2b2
> > KEY_MACRO_PRESET1(0x2b3)..KEY_MACRO_PRESET3(0xb5)
> > Empty space 0x2b6..0x2b7
> > KEY_KBD_LCD_MENU1(0x2b8)..KEY_KBD_LCD_MENU5(0x2bc)
> > Empty space 0x2bd..0x2bf
> > BTN_TRIGGER_HAPPY(0x2c0)..BTN_TRIGGER_HAPPY40(0x2e7)
> > Empty space 0x2e8..0x2ff
> >
> > The modalias shrinks from 2082 to 1550 bytes.
> >
> > A chunk of keys need to be removed to allow the keyboard to be used.
> > This may break some functionality, but the hope is these macro keys are
> > uncommon and don't affect any users.
> >
> > [1] https://github.com/systemd/systemd/issues/22944
> > [2] https://lore.kernel.org/xen-devel/[email protected]/T/
> >
> > Cc: Phillip Susi <[email protected]>
> > Cc: [email protected]
> > Signed-off-by: Jason Andryuk <[email protected]>
> > Reviewed-by: Mattijs Korpershoek <[email protected]>
> > ---
> > v3:
> > Add Mattijs R-b
> > Put /* and */ on separate lines
> > ---
> > drivers/input/misc/xen-kbdfront.c | 11 ++++++++++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> > index 67f1c7364c95..d59ba8f9852e 100644
> > --- a/drivers/input/misc/xen-kbdfront.c
> > +++ b/drivers/input/misc/xen-kbdfront.c
> > @@ -256,7 +256,16 @@ static int xenkbd_probe(struct xenbus_device *dev,
> > __set_bit(EV_KEY, kbd->evbit);
> > for (i = KEY_ESC; i < KEY_UNKNOWN; i++)
> > __set_bit(i, kbd->keybit);
> > - for (i = KEY_OK; i < KEY_MAX; i++)
> > + /*
> > + * In theory we want to go KEY_OK..KEY_MAX, but that grows the
> > + * modalias line too long. There is a gap of buttons from
> > + * BTN_DPAD_UP..BTN_DPAD_RIGHT and KEY_ALS_TOGGLE is the next
> > + * defined. Then continue up to KEY_BRIGHTNESS_MENU as an upper
> > + * limit.
> > + */
> > + for (i = KEY_OK; i < BTN_DPAD_UP; i++)
> > + __set_bit(i, kbd->keybit);
> > + for (i = KEY_ALS_TOGGLE; i <= KEY_BRIGHTNESS_MENU; i++)
> > __set_bit(i, kbd->keybit);
> >
> > ret = input_register_device(kbd);
> > --
> > 2.41.0
> >
Hi Jason,
On Wed, Mar 20, 2024 at 01:42:27PM -0400, Jason Andryuk wrote:
> Hi Dmitry,
>
> Do you have any feedback, or can you pick up this patch? It solves a
> real issue affecting udev, which crashes the Debian installer and
> breaks the mouse for Gnome.
>
> Or would you be okay if this patch went in via the Xen tree?
I'd rather not. Could you please ping me in 2 weeks on this. I promise
we find a solution before the next release.
Thanks.
--
Dmitry
Hi Dmitry,
On Thu, Mar 28, 2024 at 2:05 PM Dmitry Torokhov
<[email protected]> wrote:
>
> Hi Jason,
>
> On Wed, Mar 20, 2024 at 01:42:27PM -0400, Jason Andryuk wrote:
> > Hi Dmitry,
> >
> > Do you have any feedback, or can you pick up this patch? It solves a
> > real issue affecting udev, which crashes the Debian installer and
> > breaks the mouse for Gnome.
> >
> > Or would you be okay if this patch went in via the Xen tree?
>
> I'd rather not. Could you please ping me in 2 weeks on this. I promise
> we find a solution before the next release.
It's been ~3 weeks. Any ideas?
If you think this patch should be pursued in this form, I'd like to
post a v4 that adds BTN_DPAD_{UP,DOWN,LEFT,RIGHT} on the off chance
someone wants to use a controller. I dropped them initially since
they are not keyboard keys, but button presses are delivered through
the keyboard. Hence, they should be included.
Thanks,
Jason
Hi Jason,
On Sun, Apr 21, 2024 at 07:57:24PM -0400, Jason Andryuk wrote:
> Hi Dmitry,
>
> On Thu, Mar 28, 2024 at 2:05 PM Dmitry Torokhov
> <[email protected]> wrote:
> >
> > Hi Jason,
> >
> > On Wed, Mar 20, 2024 at 01:42:27PM -0400, Jason Andryuk wrote:
> > > Hi Dmitry,
> > >
> > > Do you have any feedback, or can you pick up this patch? It solves a
> > > real issue affecting udev, which crashes the Debian installer and
> > > breaks the mouse for Gnome.
> > >
> > > Or would you be okay if this patch went in via the Xen tree?
> >
> > I'd rather not. Could you please ping me in 2 weeks on this. I promise
> > we find a solution before the next release.
>
> It's been ~3 weeks. Any ideas?
>
> If you think this patch should be pursued in this form, I'd like to
> post a v4 that adds BTN_DPAD_{UP,DOWN,LEFT,RIGHT} on the off chance
> someone wants to use a controller. I dropped them initially since
> they are not keyboard keys, but button presses are delivered through
> the keyboard. Hence, they should be included.
I do not think suppressing random keys in the driver is a good idea,
because we may fill up what you currently consider as gaps, and
people will be confused why certain events are not being delivered.
I just posted a patch (you are CCed) that attempts to trim too long
modalias strings, please take a look and see if that solves your issue.
Thanks.
--
Dmitry