Ben Hutchings <b...@decadent.org.uk> writes:
> I think a proper fix would be one of: > > a. If the Xen virtual keyboard driver is advertising capabilities it > doesn't have, stop it doing that. > b. Change the implementation of modalias attributes to allow longer > values. > > It's not clear to me whether the Xen driver is advertising correctly or > not. If it is, then the solution should be b, but that may be too > disruptive a change to the kernel. So a reasonable workaround might > be: > > c. Change the input subsystem to limit the length of the > capabilities part of the modalias. The problem with a) is that the Xen keyboard is not a physical keyboard and so it has no way of knowing what keys it actually has. It is a fake input device designed to pass through whatever input the Xen hypervisor sends down. As such, any key could come in. If it doesn't advertise that it has all of these keys, then they would not be accepted by libinput when the hypervisor sends them down. This seems to be the heart of the problem: libinput was designed assuming that all keyboards can and must report what keys are actually present, and then libinput tries to cram that information into the modalias rather than some other sysfs attribute as it should ( or not at all... I still don't see how this information is actually supposed to be useful to userspace ). As for b), the problem isn't with the modalias attribute itself, but when the kernel tries to copy it into the environment block for the udev callout. The environment block is only a single page, and so limited to 4 KB. And that's for everything else that goes into the environment, not just the modalias.
