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.