Controlling apps via Bluetooth Devices

[Juanito]

I've being trying to make things work so that, for example, if you press "track skip" on a bluetooth device, a music player app on tc will skip to the next music track.

I believe the communication chain is (for example):

AVRCP signal -> bluetoothd -> uinput -> X -> gnome-settings-daemon -> rhythmbox

I can follow the signal as far as /dev/input/event*, but then get stuck on getting the track skip command into X - note that the signal takes the form of a pseudo keyboard input.

I've compiled gnome-settings-daemon (which depends on libxklavier in the repo), but it refuses to parse the pseudo key presses:

Code: [Select]

DEBUG: Unable to parse: 'XF86AudioNext'
Does anyone know of a utility other than gnome-settings-daemon that can capture key presses like this?

[Arslan S.]

this i believe is related to xmodmap not gnome-settings-daemon

Code: [Select]

xmodmap -pkethis code shows which key codes mapped to which symbols as you see there is no XF86AudioNext

Code: [Select]

xevpress keys
some keys are not captured for example when i press brightness up button (fn+light up) of my laptop

i am also trying to solve this issue because none of the shortcut keys are working in gnome desktop

Edit: some keys are workig some not

[curaga]

See http://en.gentoo-wiki.com/wiki/Multimedia_Keys

In short, some players can handle the multimedia keys themselves, others have remote use switches like --skip that can be bound via any key grabber (actkbd, xbindkeys, one of the wm's doing this, etc).

[Juanito]

some keys are not captured for example when i press brightness up button (fn+light up) of my laptop

The keys recognised seem to be governed by /usr/local/include/X11/XF86keysym.h from Xorg-7.4-dev.

Looking at the latest version of XF86keysym.h from xproto-7.0.16.tar.bz2, there seems to to be a lot more data than the one in Xorg-7.4-dev, including:

Code: [Select]

/* Backlight controls. */
#define XF86XK_MonBrightnessUp   0x1008FF02  /* Monitor/panel brightness */
#define XF86XK_MonBrightnessDown 0x1008FF03  /* Monitor/panel brightness */
..but:

Code: [Select]

#define XF86XK_AudioNext 0x1008FF17   /* Next track                 */..is in both versions

From my testing, I can see that the pseudo key presses are being received:

Code: [Select]

$ sudo evtest /dev/input/event11
Input driver version is 1.0.0
Input device ID: bus 0x5 vendor 0x0 product 0x0 version 0x0
Input device name: "00:1B:66:00:31:88"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 163 (NextSong)
    Event code 165 (PreviousSong)
    Event code 166 (StopCD)
    Event code 168 (Rewind)
    Event code 200 (PlayCD)
    Event code 201 (PauseCD)
    Event code 208 (Fast Forward)
  Event type 2 (Relative)
  Event type 20 (Repeat)
Testing ... (interrupt to exit)
Event: time 1274200254.037702, type 1 (Key), code 163 (NextSong), value 1
Event: time 1274200254.037709, -------------- Report Sync ------------
Event: time 1274200254.092604, type 1 (Key), code 163 (NextSong), value 0
Event: time 1274200254.092608, -------------- Report Sync
...

Perhaps my problem is that "NextSong" is not equal to "Next Track"

[Juanito]

I played around with this as per some of the suggestions in Curaga's link.

After setting up ~/.Xmodmap to match the capabilities of the remote device as per "evtest", things seemed OK:

Code: [Select]

$ xmodmap -pke
...
keycode 163 = XF86AudioNext
keycode 164 =
keycode 165 = XF86AudioPrev
keycode 166 = XF86AudioStop
...
keycode 200 = XF86AudioPlay
keycode 201 = XF86AudioPause
..nothing much happened when I pressed the buttons on the remote device:

Code: [Select]

$ sudo evtest /dev/input/event11
...
Event: time 1274287841.778370, type 1 (Key), code 163 (NextSong), value 1
Event: time 1274287841.778375, -------------- Report Sync ------------
Event: time 1274287841.833310, type 1 (Key), code 163 (NextSong), value 0
Event: time 1274287841.833314, -------------- Report Sync ------------
..but:

Code: [Select]

$ xev | sed -n 's/^.*keycode *\([0-9]\+\).*$/keycode \1 = /p' | uniq
...
keycode 144 =
.i.e. as per event11, keycode 163 is pressed, but xev sees keycode 144 as being pressed??

After modifying ~/.Xmodmap to suit, I get:

Code: [Select]

$ xev
...
KeyPress event, serial 27, synthetic NO, window 0x1600001,
    root 0xac, subw 0x0, time 3401979, (-8,96), root:(1090,99),
    state 0x0, keycode 144 (keysym 0x1008ff17, XF86AudioNext), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False
..and things happen in rhythmbox - even if they're not what would be expected.

Very odd that xev sees something different to what is input  

[Juanito]

Leaving aside the question of why X sees a different keypress from that reported by /dev/input, this makes things work:

Code: [Select]

$ cat ~/.Xmodmap
keycode 144 = XF86AudioPrev
!keycode 152 = XF86XK_AudioRewind [commented out as not supported by Xorg-7.4]
keycode 153 = XF86AudioNext
keycode 164 = XF86AudioStop
keycode 168 = XF86AudioPlay
!keycode 180 = XF86XK_AudioForward [commented out as not supported by Xorg-7.4]


Code: [Select]

$ cat ~/.X.d/Xmodmap
/usr/local/bin/xmodmap /home/tc/.Xmodmap &

To stop the pseudo keypress repeating at warp speed:

Code: [Select]

$ cat ~/.X.d/xset   
xset -r 144 -r 153 -r 164 -r 168
..and now the remote controls on bluetooth headphones will control rhythmbox - at  least in terms of "play", "stop", "next track" and "previous track".

Note the bluetooth controls will also control rhythmbox when it's playing through the laptops speakers since the software doesn't differentiate where the input comes from.