Comment 60 for bug 271706

I think I can almost see their design rationale, especially if they wanted the controlling logic to be compatible with more than just their volume wheel- but deviations from any standard are almost always more headache than they're worth for developers, especially when documentation isn't available.

@jetdog:
My U305 has a compatible keyboard module, I can compile and test any kernels you provide.

Looking at various source versions of the old 'kbd' drivers, I'm of the opinion that it might be best to also hack a fix in input_evdev. It doesn't exactly address the source of the problem, but quirking the kernel for all of the keyboard configurations that suffer this issues will be a long and arduous process, especially considering all the testing and scrutiny a change has to be placed under before it can make it upstream.

Wouldn't it be better to, in addition to quirking the kernel, provide a hack in evdev with a single additional non-intensive call that would provide more immediate relief to the users? This is what was done in the 'kbd' drivers, though those used a different method of determining key events.