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. -- Toshiba Satellite U300 volume wheel sticking https://bugs.launchpad.net/bugs/271706 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
