Distribution: Fedora Core release 2 FINAL Hardware Environment: Dell Inspiron 8200, 512 MB, NVIDIA 64 MB 440 Go Software Environment: ? Problem Description: The Dell Inspiron 8200 has four extra buttons plus a volume up and down button. In the old 2.4 kernel these buttons could be easily bounded to different things (they had keycodes 129 to 132). On the new 2.6 kernel xev doesn't show any keycodes at all. They have raw codes, e_001 to e_004 I think it was. I tried to give them keycodes but when I did they where shifted by two. That mean if I give e_001 129, xev shows it has 131 for some reason. I seems like this has been a problem since the release of the versions of the 2.6.0 kernel. Would be nice if this would get fixed finally. Steps to reproduce: Start xev on a Dell Inspiron 8200 and try out the four extra buttons (play/pause, stop, reverse, forward) on FC 2.
Created attachment 3935 [details] atkdb.c patch for getting the 4 extra buttons working on a Dell Inspiron 8200 Patch for the atkbd.c in order to get the 4 extra buttons working in a DELL Inspiron 8200. They haven't worked on any 2.6 kernel. See http://linux.siprell.com/ for more information and http://linux.siprell.com/k26.htm#keyboardpatch plus http://linux.siprell.com/hardware.htm#keyboard. PS. I didn't create this patch the guy who made this webpage made it. I'm submitting this patch since it seems like he never did! Kind Regards Andr
Pavlik, can you comment on this patch?
Adding the following to init scripts and using 'Option "XkbModel" "inspiron"' works just fine for me (Inspiron 8100) without any patching... setkeycodes e001 171 setkeycodes e002 172 setkeycodes e003 187 setkeycodes e004 189 I guess we could patch since positions are free anyway, but it looks like keycodes are a bit different... How should userspace be setup with the patch in question? *reading page* Ahh, those apper to be non-standard keycodes, not very good.
I will not accept this patch (or any similar patch) to extend the atkbd.c mapping table - only standard scancodes are allowed there. The table is easily modified from userspace, and that is the way to go. In the past I tried to fill the table with all the entries, but found out that there are two or three keyboards competing for every position in the scancode table, with a different keycode.
The table is easily modified from userspace, and that is the way to go. How do I modify it from userspace? Kind Regards Andr
Why this patch be accepted into the kernel, the people at Fedora have put into their. The problem is that even if you set setkeycodes e001 171 setkeycodes e002 172 setkeycodes e003 187 setkeycodes e004 189 for example. Xev will spit out other keycodes those you actually binded. Kind Regards Andr
Yes, xev will report different codes because there is another translation table than mangles the codes. However why does this matter? The symbols assigned to these codes is what matters and if you load Inspiron keymap into X the symbols are the correct ones.
Why would xev report different keycodes? If I set setkeycodes e001 176 and then run xev and then press that I would expect the xev gives back keycode 176. On the Inspiron 8200 with 2.6 kernel you xev would give keycode 182 if you would bind setkeycodes e001 176 Kind Regards Andr
The kernl's input system allows you to have keycodes with values greater than 256, while X only understands PS/2 protocol (codes up to 242 I believe, because the rest are protocol control/command codes). So there is a translation table that does this and the rules are pretty complex. Look into drivers/char/keyboard.c::x86_keycodes tables and emulate_raw(). Hope this helps.
I am rejecting this bug since keycode table fine-tuning should be done from userspace.
I don't get this obviously. Redhat accepted this patch into their version of the kernel and it works fine. If it can be set from user space, that's fine too but how does one do that. if set the keycode setkeycodes e001 171 why does xev spit out something different than 171?
Because there are 2 levels of translation in kernel, one from scancode to keycode and the second from keycode into PS/2 emulated code for consumption by X. Don't the keys work for you if you set up keycodes as I outlines above and change XkbModel to "inspiron"?