Asure Wrote:I started out from your blog post (i'm dutch) before i came to the XBMC forums

Can you tell me your distro ? It's not mentioned in the posting.
Also, why use cakemote in the end of the blog post ?

The 'old bdremote' part is to run only bdremote with a paired remote, and lirc to connect to it. For me, paired or not, bdremote will never pick up the remote, and send nothing to lirc.. (ubuntu 9.04) so that's why it's important to know your distro

I used XBMC Live 9.04, so in fact Ubuntu 9.04. It has been a while ago since I wrote the blogpost. Maybe it's better to start all over again, using the latest bits and bytes and write a better howto.

Live 9.04.1 cd-rom did not work with the steps above.
I followed the howto below, to use the older bluetooth 3.x stuff from hardy:http://jackflapb.wordpress.com/2009/03/2...to-hardys/
Basically the steps are:
1. Remove all bluetooth stuff
2. Replace jaunty with hardy in your apt sources..
3. Install bluetooth and libbluetooth-dev from hardy.
4. Re-compile bdremoted using libbluetooth-dev from hardy.
5. Start bluetooth and stop it, run bdremoted as before, notice it detects keypresses

Installing bluetooth from Hardy will break lots of stuff it seems.. so be carefull

I'm looking into going back to Jaunty apt sources and fix the breakage somehow.

Having been trying lot of variants on my ubuntu jaunty.
Neither of them satisfied me.
The problems:
Lirc works fine until you turned off the remote. Then, bluetoothd is not removing old device record, and new registration confuses Lirc - it just using correct event descriptor.
This is half of the story. I've written simple script which monitors number of PS3 records in bus/input/devices, and if more then 1 - restarts bluetoothd.
However, this produces a new HAL event, and XBMC captures new keyboard device (ps3 remote) directly from HAL, ignoring Lirc.
Then tried lot of custom scripts, written own python script to handle events, tried to bypass this with Lirc as event client - no go, still, XBMC doesn't care about any input device as soon as it sees new keyboard.
However, this new keyboard (ps3remote) is capable of sending cursor movement keys, play/stop, escape and numbers. Not a big list of options to choose.
As such, I've modified bluez's ps3remote driver to:
1) Correctly detect remote turning off and clean up device handler
2) Correctly handle holding of PS button, to allow remote to be turned off without generating ps button event.
3) remap keys on remote to send normal keyboard keys, which are predefined in system/Keymaps.xml
Here is the patch:

Thus, you don't need Lirc for this, remote is seen as simple keyboard and is sending generic keyboard's scancodes, which could be easily customized in Keymaps.xml
Ability to turn off the remote controller (holding PS button for 7 secs) allows to save batteries.

Running a minimal Hardy Ubuntu installation on an ION machine with BDRemoted.

You need to update to the latest nvidia driver but that will conflict with an exsisting nvidia driver that arrives with ubuntu. You can blacklist the driver or remove the restricted package in order to load the latest nvidia driver. Then you need to compile xbmc from svn to get vdpau working. IIRC Hardy builds don't have vdpau enabled.

I've given up. I went to back to the drawing board, minimal hardy, removed the nvidia stuff, dropped in glx-190 and compiled from svn after manually adding vpdau devel stuff. That worked great, with vdpau working. Except, bluetooth fails to work for me for some reason i don't understand. No errors in any logs. Tried 3 dongles, all blink, rebooted several times etc..

It still works fine with ps3_remote.py.. which i don't get..

I guess i'm off to the store on monday for a MCE reciever or something. The BD remote would be used for my ps3 for now

There is a way out though. If someone good at python would use the 'stopablethread' stuff inside ps3d.py to create a version of ps3_remote.py that can time-out, i would be sorted. I'm no good at python though (Otherwise i do that myself.)

Using the latest BlueZ 4.47 we can use the remote as a standard keyboard thanks to fakehid. This works almost out of the box, except for the keys that have a keycode above 255 since X can't handle those. Take a look at the post above by Ruff, for the fakehid patch. A different approach is to use evrouter to map the keys. I'm also looking into Gizmod but both seem to struggle with XBMC running as a standalone X session.

It triggers after a few presses of the PS button and generates an exception
Then ps3_remote.py drops back to the terminal.. to keep it going i made a 'remote.sh' and dropped a call to it into rc.local :

When ps3_remote.py drops back to bash after pressing PS button, it will disconnect first, then get restarted.

Sidenote: I fixed up the notifications since eventserver is somewhat broken, and it now only sends a notification on connect and exit. (otherwise it beeps all the time on each eventserver-notification message)

Still, a version that times out would be cleaner.. need to brush up my python-skillz..

Asure Wrote:Sidenote: I fixed up the notifications since eventserver is somewhat broken, and it now only sends a notification on connect and exit. (otherwise it beeps all the time on each eventserver-notification message)

Still, a version that times out would be cleaner.. need to brush up my python-skillz..

I also noticed that it is somewhat broken, that's why I became determined to hack bluez. That is - when xbmc sees new input device - all events sent by eventclient are ignored by event server. It only detects Hello/bye packets, and all key events are lost in vain (timed out).
Bluez, on the other hand, is lowlevel, it correctly handles pairing, it sends all necessary hal/dbus notifications... just incorrectly handles unpairing and sends keyevents, xbmc is not aware of %) Also this stickiness of xbmc to new input device allows to forget about all other devices. Even if you plugged usb keyboard to htpc for some reason, just hold ps to unpair and hit it once again to pair - and voilà
Of course, I'd rather prefer ps3bd to be detected as remote controller to use more explicit mappings of <remote> sections in Keymaps.xml. On the other hand, this keyboard driver allows me to launch xbmc from desktop using gnome's keybindings, as I'm turning off xbmc while going to work, to make cpu idle and save the power %)

Asure Wrote:I've given up. I went to back to the drawing board, minimal hardy, removed the nvidia stuff, dropped in glx-190 and compiled from svn after manually adding vpdau devel stuff. That worked great, with vdpau working. Except, bluetooth fails to work for me for some reason i don't understand. No errors in any logs. Tried 3 dongles, all blink, rebooted several times etc..

What exactly is the advantage of using XBMC's EventClient support? As far as I know it sends events to XBMC and show notifications on screen when something happens to the input device?

As far as I know i'm not using EventClient (does XBMC load it under the hood?). The remote is working fine as a keyboard, using Bluez and uinput. I don't get any notifications in XBMC about the remote, but do I need any?. It is connected at boot and works for as long as the machine is running so there's nothing to notify me about.

I've hooked up a multimeter to the remote to check power usage. Compared to the PS3, it does use more power overall. I guess the wireless connection with a PS3 is more finetuned than the connection with a generic USB bluetooth dongle. After about 30 mins the remote seems to enter a low-power state all by itself.

The only minor issue I'm having is with the keys on the remote with keycodes >255. The fakehid driver is the culprit here, as Ruff pointed out. In my opinion all problematic keys should be mapped to some normal keyboard letter instead of being ignored. That way anyone who isn't satisfied with the mapping can use gizmod, evrouter, keymap.xml etc. to change it to their liking, without having to recompile fakehid.c.