[SOLVED] Remapping Razer Naga (and Naga Epic) Buttons

Question

Original Thread Title: Can I remap keys on a single device?
Okay, so I have a Razer Naga Epic here, obviously unsupported by the manufacturer. However, evdev sees the device as two seperate event drivers:
in /dev/input/by-id/:
usb-Razer_Razer_Naga_Epic-event-kbd
usb-Razer_Razer_Naga_Epic-event-mouse
The default mapping of the mouse is set to have the side numbers (1-12) set to 1-0 and then - and = (first row of a standard keyboard, not the numpad equivalent presses)
This becomes problematic when attempting to map the keys to functions in games or different actions in the DE, or any other application.
I'm relatively inexperienced when it comes to remapping keys in X11 or any key remapping in Linux, so its a relatively noob question:
How would I go about remapping the usb-Razer_Razer_Naga_epic-event-kbd keys from the number 0-9 and - and = to nonstandard keys (Fn+0-9, FN+-,= for example, since my system has no Fn key, this would simulate presses normally impossible for me to hit on my keyboard, effectively making this buttons seperate)
I understand that with xmodmap I can change the keys globally (so the keys on my keyboard and mouse would both get changed) but what if I just want to remap the mouse's keys to different buttons?
xinput --list outputs the following:
xinput --list
â¡ Virtual core pointer id=2 [master pointer (3)]
â â³ Virtual core XTEST pointer id=4 [slave pointer (2)]
â â³ Razer Razer Naga Epic id=8 [slave pointer (2)]
⣠Virtual core keyboard id=3 [master keyboard (2)]
â³ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
â³ Power Button id=6 [slave keyboard (3)]
â³ Power Button id=7 [slave keyboard (3)]
â³ Razer Razer Naga Epic id=9 [slave keyboard (3)]
â³ Topre Corporation Realforce 87 id=10 [slave keyboard (3)]
X clearly detects the pointer and button portions of the mouse as two seperate devices. Unfortunately xkeycap (a frontend for xmodmap) confirms my fear that the two devices are handled as one (the virtual core keyboard) as far as X is concerned... I'll have to dig around some more and see if I can figure out how to use the other x keyboard config utils.
I think I may have figured out a relatively simple way, avoiding using xkbcomp and setxkbmap, which are cumbersome. Remembering back to the days when laptop keyboards and such weren't handled as well by evdev, and we had to do funny things with xorg conf files to load special keymaps, I realized that I could make a section for the Naga, and make my own key map file (These files are stored in /usr/share/X11/symbols, in my case I use the us symbols group.)
So my idea is to create a new "naga" symbols group, by editing a copy of the "us" symbols group, which should effectively give me a new keymap for JUST my naga by setting it in xorg.conf to use the naga group. I'll report back whether this works, and mark the thread solved accordingly.
This will not work because of the way evdev assigns itself to devices. I need to make an xkb layout that modifies other layouts, and have it apply itself to the Naga device, I will work on this more later.
Edited: Changed the title to be something more relevant to this particular discussion. Hopefully this will help with people looking for the solution to the same problem!
Last edited by Xaero252 (2012-10-25 23:28:14)

Answer 1

I have been wrestling with this post for quite some time and thought I would post my findings as well.
Let me start off by saying I think you should go with the above posts first because I have just been fumbling around trying to get this to work and it does. However, I have no experience with this and I do not know if this is the best way to go about the remapping (IE it may be considered pretty ugly).
For some reason, the above method did not seem to work all that well for me. What seemed to be happening was that some (but not all) of my keyboard keys would become unresponsive after applying the fix above. EG the 3, 4, 6 & 9 would not register anything after applying the script(s) above. This seemed to correspond to any of the keys (F15, F16, etc.) that were that were assigned a shortcut in KDE->System Settings->Shortcuts and Gestures. I ran xev and took a look at the output to check things out. When pressing those keys, it seemed like both keys (the keyboard 3 and the naga 3 (remapped to F15)) still had the same scancode but a different mappings and xev appeared to be confused in some way. Anyway, the end result was that the keyboard would not register a 3 when pressed.
So to fix it I went down a level in the remapping process. I created a udev rule, a corresponding keymap, and a ~/.Xmodmap and the problem seems to be solved.
For the TL;DR people with a razer naga first generation you can just place these files in the following direcotries, unplug and reconnect your mouse, issue `xmodmap ~/.Xmodmap`  and things may work:
/etc/udev/rules.d/85-razer-naga.rules
/usr/lib/udev/keymaps/razer-naga
~/.Xmodmap
CAUTION: Before you replace the .Xmodmap file, I suggest that you run `xmodmap -pke`. The output is your current key mapping. The ~/.Xmodmap file that I have provided replaces keycodes 191 through 202. Some of those keys maybe be (at least they were for me) special keys that you do not want to replace (IE toggling a touchpad on/off). If you don't have any problem losing anything there (I don't even have those keys) go ahead and replace all the files above and issue `xmodmap ~/.Xmodmap`.
My fix is based on this blog post:
http://stew.vireo.org/blog/posts/Udev_a … keyboards/
I followed that post preciesly only I replaced f13-f24 for all the key codes corresponding to the 1-12 buttons on the naga. Created the rule file and unplugged and replugged my mouse. At that point things did not work. So I re-ran xev to find that the remapping was working but the key codes the naga was spitting out were not the key codes that I was expecting. The scan codes were correct (191-202) but the mapped keycodes were some special keys as stated above (why?, I do not know). So the next step was to force a remapping of the scancode to keycode relationship.
I did this by issuing `xmodmap -pke > ~/.Xmodmap` and generally following the this Archwiki guide.
In the end, I finally got this mouse to work as expected.
Hope this helps.
Have a great day.
-Rick
Last edited by rick1908 (2013-04-04 10:30:30)