GNOME Bugzilla – Bug 128483
Thinkpad Keys Patch
Last modified: 2007-08-31 22:20:45 UTC
Hi, I sent this patch to the acme maintainer a few months ago and haven't heard anything new.... This patch adds support for the IBM Thinkpad Keys: volume, mute, LCD dimmer, LCD/VGA mode, "thinklight", home, search, mail keys.
Created attachment 22080 [details] [review] The patch
Btw this patch has no external dependencies.
Dude, I *did* send an answer ;) A couple of comments: - I would rather not have much code that was thinkpad specific in themain acme.c file - Why isn't thinkpad_key_listener merged with do_action ()? That would allow removing stuff like the THINKPAD_MUTE handling, THINKPAD_BRIGHTNESS and THINKPAD_VOLUME (and the other duplicate ones at the top) - testing for /dev/nvram isn't enough, you also need to restrict it to x86 machines, PPCs, Sparcs (and probably others) have nvram pointing to their firmware. Could end up being quite nasty.
Adding the PATCH keyword.
Removing the patch keyword, as it's wrong.
It's still a patch, nonetheless. . .
alexander: patches not accepted by the maintainer are not patches, basically.
Reassigning to the control-center.
(Anyone know if the new "needs-work" flag should be added to this patch?)
yeah- If the maintainer has already given a clear opinion on the patch, there can be no harm IMHO in setting the flags. At some point the bugsquad is likely to do a mass flag-setting session to try to help this process get along.
Richard, could you run us down the current status of all those keys?
Yes, sure. ThinkPad keys are tricky to deal with, as similar models can have different scancodes, and even worse the same scancodes are used for different keys on different models. The current plan is to patch the thinkpad_acpi driver to emit KEY_UNKNOWN with the scancode in the key event, something like input_event(inputdev, EV_MSC, MSC_SCAN, scancode); which will let us apply a keymap in userspace to map the keys to the correct keycodes. This can be done automatically using HAL, and we will automate this. Doing this approach means we do not have to do custom userspace bodges, and we can use the standard INPUT mechanism to deliver multimedia keypresses. Does that answer your question? The maintainer has applied my patches to an upstream branch, so it's likely this code will go to linus when the merge window re-opens. This bug can probably be closed now, as userspace polling in g-c-c is certainly not what we want.
(In reply to comment #12) > Doing this approach means we do not have to do custom userspace bodges, and we > can use the standard INPUT mechanism to deliver multimedia keypresses. Should we special case the mixer used for the volume keys so that we can see the changes with a popup (as g-p-m does for brightness-in-hardware keys)?
This is completely obsoleted by Richard's work on the ibm_acpi driver, and the keycode binding work in HAL.