2011-02-16, 01:23
Alright! That is what I have been doing. Simply rebooting and starting from a fresh boot to try and pin down timings and configurations of the remote.
poofyhairguy Wrote:My interkey delay is 150.
SaM Wrote:Concerning the double key press :
- using “echo none +lirc > /sys/class/rc/rc0/protocols” didn’t work
- using the lirc_mceusb module by blacklisting mceusb removed the double key press problem but I had the inverse problem, where I had to press multiple time a button for it to work and it was generally slow to respond
- I finally made it work with the mceusb module (from the kernel) by using the method demod posted in the first comments. And the remote is much more responsive than ever before. I just had to tweak a little by writing a udev rule to create a “permanent” device i could use with lirc, as it wasn’t always the same /dev/input/eventX after a reboot, I also had to use my own Lircmap.xml and remote.xml for xbmc (I use a logitech harmony one + mce compatible IR605A/Q dongle recognised as “Formosa21 eHome Infrared Transceiver”
In this case the remote and the IR receiver are not at fault, it’s the system, because the double key press is due to the fact that two modules are loaded for the same device, one included in the kernel since 2.6.36 (mceusb) and one from lirc (lirc_mceusb). We can see the problem easily with irw, for some key press on the remote two events are detected (we can logically assume one from each module, also see the end of the post), hence the double key press effect in xbmc.
So, to eliminate the double key press, you must configure the system to load and use only one module which is done by blacklisting one and configuring the other properly.
First, I tried the “echo none +lirc > /sys/class/rc/rc0/protocols” tip given somewhere in the comments, but it didn’t work for me, I still had exactly the same problem.
Then I tried to blacklist mceusb and use lirc_mceusb, it removed the double key press problem but introduced another one (almost the opposite problem) : I had to press a button multiple times for one press to be detected, and it felt kinda slow to respond.
Then I tried the last solution, blacklisting lirc_mceusb and using mceusb. But from what I could read on the net, it seems that instead of simply being recognized as a remote it emulates a keyboard and it isn’t very easy to configure with xbmc because how can you know to which key from a keyboard corresponds each button from the remote (key press as a keyboard did not generate events in irw). That’s why all the subsequent configuration was necessary to be able to use the mceusb module and have a behavior consistent with a remote which can be used properly with lirc. It supressed the double key press for me and I have no more problems, it’s very responsive and every key press is properly detected only once in irw and by xbmc.
For the resume from sleep I read a lot about this problem also but since I don’t use sleep I can’t help on this point.
From what I can guess from your symptoms :
- lirc_mceusb is loaded and functioning properly, each key press generates an event
- mceusb is also loaded and functioning as an emulated keyboard, the direction button from the remote are apparently and logically mapped as direction buttons from a keyboard so when you press this buttons you have an event from lirc_mceusb recognized by xbmc as well as a key press on a keyboard. But since the other buttons from the remote are probably mapped to others buttons of a keyboard not corresponding to the keymaps used by xbmc they don’t create this double key press effect in xbmc, only the lirc_mceusb key press being recognized.
When I tested my solution, before reconfiguring lirc, the only buttons from my remote that could do something in xbmc were the direction buttons, which seems to confirm this intuition that others buttons are not mapped to keyboard buttons recognized by xbmc in its default configuration.
So in your case I think you definitely must try one of the solutions to stop the system from using both modules.
I hope i’ve been clear enough (sorry for any error, I’m not a native eglish speaker)
xbmc@XBMCLive:~$ irw
000000037ff07be1 00 Up mceusb
000000037ff07bde 00 Right mceusb
000000037ff07bdf 00 Left mceusb
000000037ff07bde 00 Right mceusb
000000037ff07bdf 00 Left mceusb
000000037ff07bdf 01 Left mceusb
000000037ff07bdf 00 Left mceusb
000000037ff07bde 00 Right mceusb
000000037ff07bdf 00 Left mceusb
000000037ff07bdf 00 Left mceusb
000000037ff07bdf 00 Left mceusb
000000037ff07bdf 00 Left mceusb
000000037ff07bdf 00 Left mceusb
000000037ff07bdf 00 Left mceusb
000000037ff07bdf 01 Left mceusb
000000037ff07bdf 00 Left mceusb
000000037ff07be1 00 Up mceusb
000000037ff07be0 00 Down mceusb
000000037ff07bde 00 Right mceusb
000000037ff07bde 01 Right mceusb
000000037ff07bdf 00 Left mceusb
000000037ff07bf4 00 Enter mceusb
000000037ff07bdf 00 Left mceusb
000000037ff07bde 00 Right mceusb
000000037ff07be1 00 Up mceusb
000000037ff07be0 00 Down mceusb
000000037ff07bde 00 Right mceusb
000000037ff07bdf 00 Left mceusb
000000037ff07bdf 01 Left mceusb
000000037ff07be0 00 Down mceusb
000000037ff07be1 00 Up mceusb