Ps3 remote and battery drain

Help and Support Raspberry Pi
1

Hi.

Until now I’ve used the old raspberry pi model with rasbmc and a ps3 remote (1st gen) successfully.
Although the bluetooth setup was quite difficult (applying patches to bluez, compiling manually, setup key mappings etc.), it worked in the end. Basically I used this guide to setup everything:

http://kodi.wiki/view/HOW-TO:Set_up_PS3_BD_Remote

Without the patches, bluez never took the remote to standby and after 2-3 weeks, batteries were empty.
With the patches, batteries last for at least 6 months - if not even longer.

Now I got the pi 2 from a friend and tried to go to osmc directly. After updating it to the latest version, pairing with the remote worked and was usable. Good job! Keymappings are still missing, but I did that with the Keymap Editor addon in the past.

What worries me is, that the remote doesn’t go to standby as with rasbmc. With rasbmc one could recognize the sleep mode when pressing a button. First press woke up the remote, the 2nd went through. So one had to press buttons 2 times until the remote woke up.

I could configure the idleTimeout and the keymappings within the /etc/bluetooth/input.conf file. This seems to exist in osmc as well, but setting idleTimeout to 1 (minute, I guess, with the patches it was in seconds), the remote doesn’t seem to go to sleep. Also mappings don’t seem to be read properly.

So I’m not sure, whether the bluez package of osmc already contains the mentioned patches concerning the standby fixes.

Does anybody got the ps3 remote standby working with osmc?

Without a fix for this, I have to stay at rasbmc I guess :(…

2

Hi

I had a PS3 remote some years ago and had serious battery drain issues with the device.

Can you share your changes so we can get it in to OSMC for other users?

To get a better understanding of the problem you are experiencing we need more information from you. Please see How to submit a useful support request - General - OSMC for advice on how to help us.

3

Getting the ps3 remote working with OSMC is straight forward implemented within OSMC so we don’t need to take a deeper look at this.

Where we need to improve is on the standby thing. Per default, the remote doesn’t seem to get into standby under OSMC so the batteries are drained very quickly. Under raspbmc I had to patch the bluez packages to get it working correctly. Orignally the patches came from a user named kitlaan. Replacing the originally raspbmc bluez packages with the patched ones did the trick for me. Back then, that was the version 4.99. OSMC comes with 5.12 or something. So I wonder, whether the patches have made their way into the official bluez distribution. I think we should check this first. On first sight I would say no - because idleTimeout isn’t respected and the documentation states its value is in minutes rather then seconds (as with the patches). So I think we should get in contact with the bluez maintainer to check this.

Meanwhile I upgraded my raspbmc installation from the first pi model to the latest version 2 model. There it happened, that the remote went to standby, but didn’t woke up anymore. A little debugging showed, that the bluetoothd from the bluez package didn’t recognized the re-connect anymore - I don’t know why. Maybe of the changed kernel. So I just returned to the patches and realized, that there is a new version available (4.101). I patched the bluez package of the raspbmc again - now with the new version - and standby works again.

So I think to get standby working under OSMC, this is the working solution for it:

https://www.mythtv.org/wiki/Sony_PS3_BD_Remote

Question is now, is the OSMC Team willing to use a patched bluez package to get it working? If yes, applying the patches like described above should do the trick. I think pairing with ps3_pair.py isn’t that important - that could be done with the standard bluez commands - I guess. If patching is not an option, we have to get the bluez maintainer onboard - as I mentioned earlier.

Keyboard mappings are just a side topic and can be simply addressed with the keymap editor kodi addon. So we can get into that later I think. This is finetuning :).

So I try to get in contact with the bluez maintainer and report back. Maybe you also have a direct connection to the maintainers?

4

Hello,

OSMC ships BlueZ 5.2.3-2.

Perhaps – but I think it would be beneficial to users if you shared the keymap or even submitted the revised keymap as a PR so we can get that included in the next update.

You can check the packages from the Debian repository.

I’m not keen on this – I’d like to stay with upstream. I’m curious as to why this has not been submitted upstream if it does indeed fix an issue. Perhaps this introduces regressions or was not the right way to get things done. I would first verify whether or not the patch is in BlueZ upstream, and if so, whether it’s in Debian BlueZ. There are effectively ‘two’ maintainers for BlueZ in Debian: the upstream and the Debian maintainers themselves. I have spoken to the BT maintainer for Debian, as we would also like to backport AVRCP. At best, we get it in ‘jessie-backports’ which still isn’t ideal.

For now, I’d recommend you do what you did in Raspbmc (compile it downstream and use a local version). If you have luck with this on 5.2.3 I can take a look at packaging this for OSMC.

Cheers

Sam

5

The original keymap is shown in the mythtv link above (look at the end), and is put in input.conf.
I use this as-is. But I think that these mappings are only used with the patched bluez.

The other mappings via keymap editor addon are just some according to my personal taste. I think this should be up to the user to decide and configure. The remote is ok with the default mappings already. It’s more about getting the standby fixed.

Checking the whole source tree of bluez and comparing it to the patches will require some work. Although I’m a developer as well (Java), these C/C++ sources aren’t real fun to read :). I posted to the bluez mailing list and see if something comes back there.

Depending on the answer I will have to check the patches/sources by myself, I guess :(.
We’ll see if the 4.101 patches are still working with 5.2 - I doubt it.

6

Hi,
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

7

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:
https://www.mythtv.org/wiki/Sony_PS3_BD_Remote#Linux_installation_process

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:
https://www.mythtv.org/wiki/Remapping_remote_control_key_codes_greater_than_255

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/ps3_remote.py 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)
Properties:
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

8

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

9

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

10

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:

https://github.com/osmc/osmc/blob/master/package/lirc-osmc/patches/all-000-fix-uinput-restriction.patch

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

11

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?

12

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.

13

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.

14

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.

15

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.

16

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.

17

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.

18

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.

19

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: https://github.com/osmc/osmc/blob/master/package/eventlircd-osmc/files/etc/eventlircd.d/ps3remote.evmap 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.

20

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.