I wanted to use a Logitech R400 that a friend loaned my in a presentation, but I wanted to tweak the mappings for the buttons a bit. My presentation is done using Reveal.js and uses both left/right and up/down. The R400 has four buttons but two of them are mapped to “go to black screen” and “slideshow mode” neither of which is useful to me. Here is how I fixed it in Fedora 20.
/etc/udev/hwdb.d
/etc/udev/hwdb.d/99-logitech-r400.hwdb
# The lower left button actually emits two
# different scancodes depending on the state of
# the "presentation".
# E.g. one code to start and one to stop.
keyboard:usb:v046DpC538
KEYBOARD_KEY_70029=up
KEYBOARD_KEY_7003E=up
KEYBOARD_KEY_70037=down
KEYBOARD_KEY_7004B=left
KEYBOARD_KEY_7004E=right
This maps the left and right buttons to left and right, the both states of the slideshow button to up, and the blank screen button to down. The 046D
is the Logitech vendor code and the C538
is the model number. Those magic numbers after “KEYBOARD_KEY” are the scancodes associated with the button. Supposedly showkey --scancodes
will display them but I couldn’t get that to work and ended up taking them from another blog post.
# udevadm hwdb --update && udevadm trigger
# xev | grep -A2 --line-buffered '^KeyRelease' | sed -n '/keycode /s/^.*keycode \([0-9]*\).* (.*, \(.*\)).*$/\1 \2/p'
/etc/udev/rules.d/99-logitech-r400.rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c538", IMPORT{builtin}="hwdb 'keyboard:usb:v046DpC538'", RUN{builtin}+="keyboard"
That will import our custom mapping when the USB receiver is plugged in.
Thanks to the following who helped me figure all this out:
I just went through a harrowing experience of attempting to install Fedora 14 on a Lenovo T520 Thinkpad with my good friend, abutcher. The issue presented itself first as X failing to start after the installer loaded. After switching into low graphics mode we were able to go through the installer successfully. But that did not solve our problems completely. After booting into the desktop we were unable to change the display resolution from 1280×1024 to the native 1600×900.
We started as most people would, Googling for numerous combinations of “fedora 14 thinkpad T520”, “sandybridge linux”, “sandybridge fedora”, etc. The results were surprising. Numerous sources report the T520 works with “no special setup needed.” This was not true for us. We Tried installing a newer Kernel from rawhide and the newer xorg-x11-drv-intel
driver (2.16). This did not fix the issue.
To compound our confusion, we noticed numerous posts referencing a BIOS option to disable the Nvidia 4200M (Optimus) card. Our system showed no signs of said card or any “internal”/”external” BIOS option.
Next we attempted installing Fedora 15. *ugh* GNOME 3 was not on our list of things to try today. But it was all we could think of.
This also did not work.
I started doing some heavy research. Somehow I ended up researching Kernel Mode Setting (KMS). The Debian Wiki was an especially useful resource for this.
Kernel Mode Setting (KMS) provides faster mode switching for X and console. It also provides native-resolution VTs on some laptops and netbooks which, prior to this, would use some standard mode, e.g. 800×600 on a 1024×600 panel.
This was relevant to my interests. “KMS provides native-resolution virtual terminals” you say? A quick trip to /boot/grub/grub.conf
showed that we were booting our kernel with the nomodeset option. We made a new boot entry (protip: never change your boot loader without leaving a known “working” entry) and omitted the nomodeset option. We also set the value of the default variable to our new entry, set timeout
to 10, and commented out the hiddenmenu
directive.
This almost worked. We removed the xorg config file (/etc/X11/xorg.conf
) and restarted the computer for good measure.
voila.
Our Lenovo Thinkpad T520 was booting X using the laptops native resolution.
Just to clarify:
xorg-x11-drv-nouveau
package/driver had nothing to do with this. That package provides an Nvidia driver (which did not affect us)kmod-nvidia
package/driver also has nothing to do with this