Ps3 remote and battery drain

I am also trying to get this to work.
I recently jumped on the OSMC train and so far I’m very happy with it.
The only thing that I can’t figure out, is how to get the input.conf to be read by bluetoothd, thus I’m unable to use the keymap editor for configuration of keys.
I have the newer version of the Sony PS3 BD Remote (2nd gen it appears), but basically they’re almost the same.
Before, I was on Raspbian Wheezy, where I were able to apply the above mentioned bluez patch.
Sadly, I don’t know any programming at all, so I won’t be able to debug anything here.

Those are the bluetooth related errors from the journal:

connmand[340]: Method “ListAdapters” with signature “” on interface “org.bluez.Manager” doesn’t exist
bluetoothd[704]: Unable to get on D-Bus

I’m going to try and list every bit of information I can find regarding this matter:

First of all, the underlying problem seems to be that X11 doesn’t recognize keystrokes >255 as described here: 11227 – (x11-keycode-limit) Allow > 255 keycodes

Given that this bugs exist since 2007 it’s probably not going to get fixed - ever.

The possible workaround #1 is using a patched version of bluez that allows us to use /etc/bluetooth/input.conf to remap the keys on the remote. The translation of keypresses >255 seems to take place in the bluez-4.101_ps3remote.diff patch as mentioned in this article:

I don’t know if this patch can be applied to the current bluez version (5.23 I think?) and am not experienced enough in Linux stuff to try, fail and repair my mistake.

Another way to get around the X11 >255 bug is by building the xf86-input-evdev driver as described here:

I don’t know if any of these fixes can be integrated into OSMC, or patched manually as both procedures use outdated patches.

Basically what needs to be done, is to remap the keys >255 to keys <255. This seems to be more complicated than it sounds though, at least to my untrained ears.

BTW: What does this script do? osmc/ at master · osmc/osmc · GitHub
Could the remapping be implemented there?

This is the output of evtest:

`Available devices:
/dev/input/event0: Logitech K400
/dev/input/event1: lircd
/dev/input/event2: BD Remote Control
Select the device event number [0-2]: 2
Input driver version is 1.0.1
Input device ID: bus 0x5 vendor 0x54c product 0x306 version 0x110
Input device name: “BD Remote Control”
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 1 (KEY_ESC)
Event code 2 (KEY_1)
Event code 3 (KEY_2)
Event code 4 (KEY_3)
Event code 5 (KEY_4)
Event code 6 (KEY_5)
Event code 7 (KEY_6)
Event code 8 (KEY_7)
Event code 9 (KEY_8)
Event code 10 (KEY_9)
Event code 11 (KEY_0)
Event code 28 (KEY_ENTER)
Event code 103 (KEY_UP)
Event code 105 (KEY_LEFT)
Event code 106 (KEY_RIGHT)
Event code 108 (KEY_DOWN)
Event code 119 (KEY_PAUSE)
Event code 128 (KEY_STOP)
Event code 139 (KEY_MENU)
Event code 158 (KEY_BACK)
Event code 159 (KEY_FORWARD)
Event code 161 (KEY_EJECTCD)
Event code 168 (KEY_REWIND)
Event code 172 (KEY_HOMEPAGE)
Event code 207 (KEY_PLAY)
Event code 256 (BTN_0)
Event code 310 (BTN_TL)
Event code 311 (BTN_TR)
Event code 312 (BTN_TL2)
Event code 313 (BTN_TR2)
Event code 315 (BTN_START)
Event code 317 (BTN_THUMBL)
Event code 318 (BTN_THUMBR)
Event code 353 (KEY_SELECT)
Event code 355 (KEY_CLEAR)
Event code 357 (KEY_OPTION)
Event code 358 (KEY_INFO)
Event code 359 (KEY_TIME)
Event code 370 (KEY_SUBTITLE)
Event code 371 (KEY_ANGLE)
Event code 375 (KEY_SCREEN)
Event code 392 (KEY_AUDIO)
Event code 398 (KEY_RED)
Event code 399 (KEY_GREEN)
Event code 400 (KEY_YELLOW)
Event code 401 (KEY_BLUE)
Event code 407 (KEY_NEXT)
Event code 412 (KEY_PREVIOUS)
Event code 436 (KEY_FRAMEBACK)
Event code 437 (KEY_FRAMEFORWARD)
Event code 438 (KEY_CONTEXT_MENU)
Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN)
Testing … (interrupt to exit)

This device is grabbed by another process.
No events are available to evtest while the
other grab is active.
In most cases, this is caused by an X driver,
try VT-switching and re-run evtest again.
Run the following command to see processes with
an open fd on this device
“fuser -v /dev/input/event2”


In terminal every single keystroke is detected correctly. So the problem definitely must be, that X11 doesn’t recognize keystrokes >255

Are you using OSMC on a ATV1? If not than that is definetly not your problem as the Raspberry is not using X11.

Oh, okay, I supposed it did. I’m using OSMC on a RPi2. So should OSMC be able to use keystrokes >255? Maybe there’s an easier fix then? Keymap Editor doesn’t recognize the keys as is.
Where can I find the file with the keymapping for the PS3 BD Remote? Strangely enough, the coloured buttons work, even though their event code is >255

You can use event codes greater than 255 on OSMC.

At least two of the buttons on the white OSMC remote use event codes >255 (Context and Info I think) and we had to patch lircd to be able to handle this:

Remotes that don’t use lircd can also use event codes >255.

Thanks for the answer.
Then I guess I’ll just have to find a way to map those keys by editing some .Conf files
Could someone tell me where to find them? Does this work the same way as with IR remotes?

You know how this works with CEC?

I got a button digital/analog on my remote that I see pressed in the Kodi debug log, but with Keymap editor it is not possible to use it.
If I know which code it is, I can manually edit it in the xml.

Sorry, CEC is a special case. I meant all other types of remote’s other than CEC. CEC is handled directly by Kodi and does not go through the standard Linux input subsystems.

OE supports the ps3 bd remote, and will sleep the remote when the screensaver kicks in. I don’t actually know how they do it, but a search on github should reveal it.

ps. Bluez 5 has been rewritten so the old patch won’t work. The file that the old patch patches doesn’t even exist anymore.

ps2. if you add the deviceid of the harmony ps3 adapter, you can use an old harmony to control kodi (as an ps3). Once you go universal remote, you nver go back.

ps3. newer Harmony remotes can support bluetooth directly, either in dedicated mode or keyboard emulation. Including the harmony ps3 adapter, you then have 3 ways to control Kodi with a Harmony.

I can’t afford to buy a newer Harmony remote.
The reason why I don’t want to give up, is that I know there must be a way to make the PS3 BD Remote work in OSMC. It’s even in the code of OSMC already. For some reason it doesn’t translate or only partially translates to the Kodi GUI.

Sure, just build bluez 4.101 from source with the patch applied, and do apt-mark hold bluez. Or figure out how OE does it. I think they’re using lirc.

That’s what needed to be done for Kodi on Raspbian. But OSMC does already recognize the remote. It just doesn’t seem to forward that information to Kodi. A more experienced user than me would probably be able to solve the problem in seconds. :wink:
I’m just going to keep googling until I’m smarter.

Wake up.

Bluez has recognized the PS3 BD remote since 2008, why does it matter? The idle timeout code, the code that let you remap the keys with a simple input.conf, and the code to remap keycodes to =<255 (although not strictly needed under rpi). All these are specific code for the PS3 BD remote.

This functionality isn’t going to magically appear unless it’s actually patched into bluez…

Neither googling until you get smarter, or waiting for Santa to come fix it in “seconds” is going to accomplish anything.

Either you try building bluez 4.101 with the patch, rebase the patch to Bluez 5.x, or take a look at how OE does it.

Yeah, I get your point
I’m not waiting for Santa to be fixing the problem for me, though. I was trying to say, that someone smarter than me wouldn’t need to post here if he had my problem, because he would be able to fix it in seconds (with the remote in his hands).
Whereas I don’t know where to look for the right files and/or lines.
All I know is that the remote code is definitely integrated into the system, as it gets detected perfectly without any patch in Terminal and there are files referring to it, e.g. This one: Which wasn’t the case in Raspbian. If that doesn’t mean anything, so be it.

I appreciate your input, if that wasn’t clear.
Maybe I will do as you suggest, but even that will involve tons of googling for me. My Linux skills are pretty much copy/paste.

Look, there are a lot of people using the remote with Openelec. There are some differences regarding the evmap file, compared to OSMC, and it would have taken you 30seconds to google it yourself. I already told you twice to look at OE, but you didn’t, so what else can we do? I’m not saying this file will solve it (in any case there’s also the issue of being able to sleep the remote), but if you make an effort and report back, then everyone will benefit.

Thanks for pointing out the differences in the ps3remote.evmap file. I didn’t notice them.
My remote seems to sleep out of the box. At least it behaves the same way as under Raspbian where I patched bluez. I don’t mind having to change the batteries once a month, if necessary.

Yes, it took me 30 seconds to find that link, among hundreds of other links which I all read from top to bottom.
If you think, I’m just waiting here for kind replies, then you’re wrong. I’ve spent at least 20 solid hours trying to solve this.
In fact, I’ve spent the last 2 hours looking at every single search result of “openelec ps3 remote” which ultimately led me to this project: Sony PS3 Remote / Code / [r47] /bluez/patches
They do seem to have patched versions of bluez 5. Tomorrow I will try and see what I can achieve.
If I solve it, of course I will present the solution here. Also, I’m obviously going to give the openelec version of ps3remote.evmap a try. Though it appears that kodi ignores that file as is.

Thanks again for your help, I really don’t get the rudeness though.

Please don’t take offense. I find it the easiest to just be direct. It seems you did the homework regarding what causes mainline bluez to not function correctly with the ps3 remote. So like I said, there’s 3 ways you slash this. Use the old bluez, rebase the patch to a newer version of bluez, or just let (event)lirc handle this as OE seems to do. (I think they have added some code to be able to autosleep bluetooth devices when the screensaver kicks in)

As I have used the old patch with 100% success, I would try the new patch on Bluez 5.x. I like to have my timeout set to 60seconds, instead of relying on the screensaver kicking in. This way the batteries will easily last 1,5 years or so.

Also the (patched) bluez way of doing this seems to wake up the remote (or the subsequent repairing) much faster than eventlirc (as done in OE). Therefore there’s no need to have the remote active throughout a whole movie.

@DBMandrake don’t you have a PS3 remote?

No. I have never owned a PS3.

My mistake