USB headset Buttons

[Tompazi]

I have wireless USB headset with four buttons. Two for volume control (They work).
I'd like to use the other buttons too. One gives 'Alt-C' as input. The doesn't give visible any input. I tried to get the input with Wireshark but it could only capture 16 packages when plugging in the headset.
So my question is: How can I get the input for the second Button?
and how can I change the Input of the first button (Alt-C) to e.g. xf86audiomute?

Tompazi

[simon]

if the buttons register as x events you can change their keycodes via .Xmodmap. type xev to launch the x event monitor, put the cursor in the little square, and tap the headset buttons. if the one you want to change registers as an x event, you'll see a keycode displayed for that event.

let's say the keycode was 234: put a line like "keycode 234 = XF86AudioMute" in your .Xmodmap file. if your distro doesn't parse it automatically, stick "xmodmap ~/.Xmodmap" in a startup file (something like .bashrc). this should remap the button for you.

if that works, you can try getting the other button to register as an x event (if it already does, you're fine: just assign a key as above). press the key that's not generating an event and then do a dmesg | tail to get its hex code (let's call this $hex). then, find an unused keycode (we'll call this $key) and you can simply bind them together with:

setkeycodes $hex $key

assuming this works, you now have a keycode to assign via xmodmap. if you want this to happen all the time (the setkeycodes bit) i think you may need to do it fairly early on (e.g. in a system init script, like rc.local or whatever).

[Tompazi]

Thank you for your competent answer
Button 1: xev tells me that the keycode is 127. I created the .Xmodmap file in my home directory and wrote: 'keycode 127 = XF86AudioMute'. So far, so good. The button now mutes (and unmutes ) my sound, BUT it still gives an 'Alt-C' input. I checked the original xmodmap file (/usr/share/xmodmap/) and 127 was NOT defined. This very annoying as 'Alt-C' is the quit shortcut for many programs. Where can this still be defined and how can I change this?

Button 2: xev ignored this button completely, so I assumed that this button is not registered as a x event. dmesg told me:

 [  337.307331] input: Creative HS-1200 Headset Creative HS-1200 Headset as /devices/pci0000:00/0000:00:1d.0/usb5/5-1/5-1:1.3/input/input11

The only hex I found was 1d so I tried: setkeycodes 1d 120 this probalby wrong as the command failed. What have I done wrong?

Tompazi

[simon]

oh dear, and oh dear. i'll start with the second bit of bad news.

it doesn't look like the kernel is aware of that other button. dmesg ought to respond to it (with a message about an undefined or unknown code maybe, or something like that): what you've listed there just looks like the kernel acknowledging the headset as a whole. the way to check is to run dmesg *before* pressing the button, then press it a couple of times and run dmesg again. if there's no change (and xev doesn't respond either), it's probably invisible to the kernel so there's nothing you can do about it, unless someone has written an updated driver for that device.

the other bit of bad news is that i don't know how to fix the strange hard-wired alt-c thing. all i can suggest is going through your window manager's keyboard settings and making sure it's not defined in there somewhere (most window managers have a gui applet for customising the keyboard: xfce, which i use, has a "keyboard" setting for shortcuts to launch apps etc., and a "windows" setting with a tab for the keys you want to use to close windows, maximise them, and so on). if you can't fix it via xmodmap or a gui keyboard settings tool, maybe you can kludge a solution by customising the actual applications that close with alt-c, and making it so they only close with alt-f4 or ctrl-q or whatever?

[Tompazi]

D'oh,

dmesg -> button pressed -> dmesg --> Both dmesg outputs are the very same

now to the mysterious Alt-C button:
xev doesn't give give me the keycode 127 anymore, but now tells me that actually the Buttons 'Alt_L' and 'c' are being pressed...

KeyPress event, serial 47, synthetic NO, window 0x5200001,
    root 0x13c, subw 0x0, time 4003034, (176,-19), root:(459,351),
    state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 47, synthetic NO, window 0x5200001,
    root 0x13c, subw 0x0, time 4003042, (176,-19), root:(459,351),
    state 0x18, keycode 54 (keysym 0x63, c), same_screen YES,
    XLookupString gives 1 bytes: (63) "c"
    XmbLookupString gives 1 bytes: (63) "c"
    XFilterEvent returns: False

KeyRelease event, serial 47, synthetic NO, window 0x5200001,
    root 0x13c, subw 0x0, time 4003050, (176,-19), root:(459,351),
    state 0x18, keycode 54 (keysym 0x63, c), same_screen YES,
    XLookupString gives 1 bytes: (63) "c"
    XFilterEvent returns: False

KeyRelease event, serial 47, synthetic NO, window 0x5200001,
    root 0x13c, subw 0x0, time 4003058, (176,-19), root:(459,351),
    state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

FocusOut event, serial 47, synthetic NO, window 0x5200001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 47, synthetic NO, window 0x5200001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 47, synthetic NO, window 0x0,
    keys:  2   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

I swear this wasn't there the first time.
so is the hardware actually simulating these buttons? is there a way how to change that?

Of course I could change the shortcuts but it's not only the closing of progrms but many things and I don't want to send any other command when wanting to mute the sound.

Tompazi