On Tue, 2021-08-24 at 15:19 -0400, Chuck Zmudzinski wrote: > On 8/24/2021 1:12 PM, Ben Hutchings wrote: [...] > > 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. > > > > > > Ben. > > > > So workaround c would not involve disruptions to the kernel or > systemd? Workaround c seems too disruptive for stable to me, > but maybe could go into unstable and eventually into testing. I don't think it would be very disruptive. It might require a kernel ABI bump, but we do those regularly during a stable release. And this bug is severe enough that I think a fix would be suitable for Debian stable. > A problem with the approach of fixing this bug in the Xen > keyboard driver is that the fix must be implemented in the underlying > Dom0 system, which could be almost anything - another Linux distro > or Debian stable or oldstable. Any fix upstream would probably get into > a bullseye Dom0, but not oldstable Dom0, but perhaps it could be > provided as a backport for anyone who is still on oldstable for their > Xen Dom0. [...] I agree that we need to fix this for domU independently of any protocol change to allow discovery of which keys the underlying input device has. So we can't solve this with approach a. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it.
Attachment:
signature.asc
Description: This is a digitally signed message part