rich text

could you guys talk to those other guys and then

Here, have some more volume control hate, this time from Dell.

I have a Dell Latitude D600. It has three “multimedia keys” for volume down, up, and mute. It came with a Dell multimedia USB keyboard, with eight multimedia keys: volume down, up, and mute, plus five more for browser control, I guess — back, forward, stop, reload, home. The browser ones aren’t important right now though.

So GNOME lets me choose which keys change volume, and I set them up without the USB keyboard attached. Then I plugged the keyboard in, hoping for the best, and got EVIL. Here’s the keycodes for those keys:

  Laptop key USB keyboard key
Volume up 0xB0 0xB0
Volume down 0xAE 0x9D
Mute 0xA0 0xAE

You’ll notice that they got one set right: volume-up is consistent everywhere. But you’ll also notice that they got another set as completely FUBAR as possible: two keys that do different things have the same keycodes, on two keyboards from the same company. (The other five multimedia keys on the USB keyboard all have unique keycodes.)

What the hell? Is this just fundamental brokenness that wouldn’t even work in Windows, or is there some magic I can do to get those keys to not conflict with each other, or better yet, to send the same keycode for the same key?

Rich

,

3 responses to “could you guys talk to those other guys and then”

  1. Hahahah.

    Does the kernel events layer also include the sysfs deviceid that originated the event? I wonder if you could map the tuple (USB device id, keyboard key) to a function, instead of just the keyboard key.

    Ugggly.

  2. I don’t think so — all that gets exposed to the X server are keycodes. I think I’ll disassemble the keyboard and switch around the keycaps before I’d start messing with the kernel HID stuff.

  3. You could mess with the USB hot-plug stuff. Detect when the keyboard is plugged in and change the key mapping.

    Look in /etc/hotplug/usb.agent for details. You’ll probably need to create a /etc/hotplug/usb/hib script that checks $PRODUCT, remaps the keyboard if it matches your keyboard (lsusb to find the ID) and creates a script in $REMOVER that switches the map back.

    Or you could swap keycaps :-)

    And yes, this is annoying. Dell probably has a small driver in the pre-installed Windows that does the same thing. I suspect that Dell made neither the keyboard, nor the laptop, so they don’t have as much control over the keycodes as one would think.