On Wed, Jun 12, 2024 at 8:17 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, May 27, 2024 at 03:55:57PM -0400, Jason Andryuk wrote: > > From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> > > > > commit 0774d19038c496f0c3602fb505c43e1b2d8eed85 upstream. > > > > If an input device declares too many capability bits then modalias > > string for such device may become too long and not fit into uevent > > buffer, resulting in failure of sending said uevent. This, in turn, > > may prevent userspace from recognizing existence of such devices. > > > > This is typically not a concern for real hardware devices as they have > > limited number of keys, but happen with synthetic devices such as > > ones created by xen-kbdfront driver, which creates devices as being > > capable of delivering all possible keys, since it doesn't know what > > keys the backend may produce. > > > > To deal with such devices input core will attempt to trim key data, > > in the hope that the rest of modalias string will fit in the given > > buffer. When trimming key data it will indicate that it is not > > complete by placing "+," sign, resulting in conversions like this: > > > > old: k71,72,73,74,78,7A,7B,7C,7D,8E,9E,A4,AD,E0,E1,E4,F8,174, > > new: k71,72,73,74,78,7A,7B,7C,+, > > > > This should allow existing udev rules continue to work with existing > > devices, and will also allow writing more complex rules that would > > recognize trimmed modalias and check input device characteristics by > > other means (for example by parsing KEY= data in uevent or parsing > > input device sysfs attributes). > > > > Note that the driver core may try adding more uevent environment > > variables once input core is done adding its own, so when forming > > modalias we can not use the entire available buffer, so we reduce > > it by somewhat an arbitrary amount (96 bytes). > > > > Reported-by: Jason Andryuk <jandryuk@xxxxxxxxx> > > Reviewed-by: Peter Hutterer <peter.hutterer@xxxxxxxxx> > > Tested-by: Jason Andryuk <jandryuk@xxxxxxxxx> > > Link: https://lore.kernel.org/r/ZjAWMQCJdrxZkvkB@xxxxxxxxxx > > Cc: stable@xxxxxxxxxxxxxxx > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> > > [ Apply to linux-6.1.y ] > > Signed-off-by: Jason Andryuk <jason.andryuk@xxxxxxx> > > --- > > Patch did not automatically apply to 6.1.y because > > input_print_modalias_parts() does not have const on *id. > > > > Tested on 6.1. Seems to also apply and build on 5.4 and 4.19. > > How was this tested? I built a kernel for 6.1.92 + this patch and booted a VM with it. Inside, I used udevadm and looked at the sysfs entries for xen-kbdfront.ko. For 5.4 and 4.19, I just built the module with `make drivers/input/misc/xen-kbdfront.ko`. I see now that misses building the actual change. Sorry about that. > It blows up the build on all branches, 6.1 and older kernels with a ton > of errors like: > drivers/input/input.c: In function ‘input_print_modalias_parts’: > drivers/input/input.c:1397:40: error: passing argument 4 of ‘input_print_modalias_bits’ discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers] > 1397 | 'e', id->evbit, 0, EV_MAX); > | ~~^~~~~~~ Re-building, I see these as warnings. I don't have -Werror, so they were non-fatal, and I missed when in the scroll of the full kernel build. Sorry about this. I'm preparing new patches. Regards, Jason
