Comment 67 for bug 271706

To all developper's attempting to fix this bug:

This problem exists in the __kernel__. Not in evdev. Not in X. Not in Gnome, KDE, or anywhere else.

Quirking the evdev driver does not fix this problem - and your evdev driver AND the kernel will probably be faced with increased CPU time as a result of key-event message passing. What happens is that once the kernel starts spamming the volume up/down key signals to the various kernel/X input handlers (i.e. anything that begins with xf86-input-____), X gets spammed with key events, causing the lockups you're describing.

The reason the kernel spams evdev is quite simple: We have logs earlier in this thread that indicate that the physical hardware implementing the PS/2 protocol on the keyboard do not create a release event for the volume buttons (this wheel produces "down" ticks, but __does_not_always__ produce "up" ticks).

Quirking evdev, as per the solution by ktemkin described in this thread, and on a repeatedly referenced ubuntuforums post, will __not__ stop this increased key-event message passing! It will only cause evdev to ignore the respective key signals from the kernel, but it is an extremely hackish-fix,and your kernel input handling will still be highly clogged! Also, the problem will reoccur if you (or ubuntu official) were ever to switch away from using xf86-input-evdev.

The problem starts WAY earlier than evdev. It (likely) exists in the input/drivers/atkbd.c kernel input driver. What this fix needs is a quirk for the key scancodes that are not producing "release" events, so that the linux kernel can give "keyup" events for evdev, any other xf86-input handlers, and the resulting userspace applications that use these input handlers. Then your volume wheel will work normally.

We need to get some kernel bugfixers in here! I would fix this myself, but real-life work is unfortunately taking the majority of my time.

I hope this will jumpstart a fix -- i know it's rough trying to find someone to get this stuff done!