Hi,
I have an issue with XBian with my GPIO IR receiver.
To make sure this is reproduceable I have started from scratch with the newest XBian 1.0 Beta 2.
The issue is that after enabling GPIO IR by adding lirc_rpi to /etc/modules and creating a lircd.conf file and a Lircmap.xml file, the GPIO receiver works with my remote, but strangely the arrow keys (i.e. KEY_UP, KEY_DOWN, KEY_LEFT and KEY_RIGHT) register twice. I press the key on the remote once and the function executes two times.
For testing I have then deleted my Lircmap.xml file in /home/xbian/.xbmc/userdata/ AND the original Lircmap.xml in /usr/local/share/xbmc/system, therefore no key mapping should exist, but after a reboot the arrow keys (and ONLY the arrow keys) still work...
btw. "irw" outputs the keys correctly (only once), so lircd.conf must be ok and it looks like a XBMC configuration issue.
It seems that somewhere the arrow keys are mapped outside of Lircmap.xml and if I map them in Lircmap.xml then they are executed twice.
Where are these keys mapped outside Lircmap.xml and how can I switch that off ?
Can you try:
and see what the output is per key press.
You may need to stop lirc if you get an error about device /dev/lirc is busy
Also can you try adding
Code:
<advancedsettings>
<remotedelay>10</remotedelay>
</advancedsettings>
to /home/xbian/.xbmc/userdata/advancedsettings.xml
and restart xbmc.
Terminal
sudo stop xbmc
sudo start xbmc
(16th Dec, 2013 03:52 AM)IriDium Wrote: [ -> ]Can you try:
and see what the output is per key press.
You may need to stop lirc if you get an error about device /dev/lirc is busy
Also can you try adding
Code:
<advancedsettings>
<remotedelay>10</remotedelay>
</advancedsettings>
to /home/xbian/.xbmc/userdata/advancedsettings.xml
and restart xbmc.
Terminal
sudo stop xbmc
sudo start xbmc
Hi Iridium,
thanks for your reply...
I have added the remotedelay in the advancedsettings.xml, after that the remote does not work at all, I took this out again.
mode2 is fine and the next step running irw is working fine as well, all keys show correctly and only once in the ssh session :
00000000000efba4 00 KEY_RIGHT test
00000000000efba7 00 KEY_UP test
00000000000efba6 00 KEY_DOWN test
00000000000efba5 00 KEY_LEFT test
00000000000efba3 00 KEY_OK test
00000000000efbfe 00 KEY_NUMERIC_1 test
00000000000efbfd 00 KEY_NUMERIC_2 test
00000000000efbfc 00 KEY_NUMERIC_3 test
Then again, the issue is that if I now put KEY_UP, KEY_DOWN, KEY_LEFT, KEY_RIGHT in Lircmap.xml like this
<left>KEY_LEFT</left>
<right>KEY_RIGHT</right>
<up>KEY_UP</up>
<down>KEY_DOWN</down>
<select>KEY_OK</select>
<start>KEY_HOME</start>
<back>KEY_EXIT</back>
...
and then use the remote the 4 keys above register TWICE
all other keys (KEY_OK, KEY_HOME,... ) register only once as it should be.
This is probably an issue with XBian, I have tried OpenElec and Raspbmc with the same lircd.conf and Lircmap.xml and there it works correctly. I would like to get this to work in XBian though.
if you remove "-u" from /etc/lirc/hardware/lirc_rpi.conf
?
@
MattS8
Why you still trying to put arrow (and Ok/Back) keys in the Lircmap.xml when they works wothout it?
This happens because keus with name KEY_UP/KEY_DOWN etc. exist in another config file, like Keymap.xml.
(16th Dec, 2013 04:53 AM)MattS8 Wrote: [ -> ]This is probably an issue with XBian, I have tried OpenElec and Raspbmc with the same lircd.conf and Lircmap.xml and there it works correctly. I would like to get this to work in XBian though.
Can you make a comparison between default Lircmap.xml and Keymap.xml from these OS?
(16th Dec, 2013 10:43 PM)kraleksandr Wrote: [ -> ]@MattS8
Why you still trying to put arrow (and Ok/Back) keys in the Lircmap.xml when they works wothout it?
Because it works in the menu navigation, but not in the screens where you need to put in numbers or text, like the network config (ip address entry) or the WiFi password entry... Sorry forgot to mention that earlier.
Anyway, removing "-u" from /etc/lirc/hardware/lirc_rpi.conf as posted by mk01 solves the issue, thanks !
Now my question is
1) could this be made the default (i.e. removing the "-u" argument) for new XBian installations so that XBian users with a GPIO IR reveiver do not get this problem ? Or what are the implications of making this the default ?
2) in the meantime, as /etc/lirc/hardware/lirc_rpi.conf is a system file I assume that the file will be replaced again with the next update. Is there any way to configure this to avoid having to remove the "-u" again after new updates ?
1) I believe GPIO receivers are becoming more common - previously they were all USB, so I would guess it would be set as the norm - I can't see any reason why not.
2) Have you tried putting the .conf file in your userdata folder and see if it picked up there? If that works, then any upgrade will not affect it.
If you feel the problem is solved - can you update the header to say so. Tnx.
(17th Dec, 2013 03:51 AM)IriDium Wrote: [ -> ]1) I believe GPIO receivers are becoming more common - previously they were all USB, so I would guess it would be set as the norm - I can't see any reason why not.
2) Have you tried putting the .conf file in your userdata folder and see if it picked up there? If that works, then any upgrade will not affect it.
If you feel the problem is solved - can you update the header to say so. Tnx.
Hi IriDium,
1) that would be really great, do you want me to file this request somewhere ?
2) no, putting the fixed lirc_rpi.conf file in /home/xbian/.xbmc/userdata does not work, it is not picked up. As long as this is not yet made the default, would there be any other way to avoid re-applying the -u fix after an upgrade ?
Thanks...
(18th Dec, 2013 01:02 AM)MattS8 Wrote: [ -> ]1) that would be really great, do you want me to file this request somewhere ?
2) no, putting the fixed lirc_rpi.conf file in /home/xbian/.xbmc/userdata does not work, it is not picked up. As long as this is not yet made the default, would there be any other way to avoid re-applying the -u fix after an upgrade ?
1) Hopefully it will be picked up by our main developer and if it doesn't affect anything, then it will be set as default.
2) Don't upgrade
I'm not too sure how to avoid it but I can't see many upgrades needing to overwrite this file - unless it is the one above. I guess if you made a symbolic link to your home directory for the conf file it might confuse the upgrade but it might also make it fail.
Personally, I'd just write a small script that checks the file and run it after any upgrades. I don't know how you upgrade - via XBMC, xbian-config or manually but you should see beforehand any upgrade that contains lirc.
(18th Dec, 2013 04:06 AM)IriDium Wrote: [ -> ] (18th Dec, 2013 01:02 AM)MattS8 Wrote: [ -> ]1) that would be really great, do you want me to file this request somewhere ?
2) no, putting the fixed lirc_rpi.conf file in /home/xbian/.xbmc/userdata does not work, it is not picked up. As long as this is not yet made the default, would there be any other way to avoid re-applying the -u fix after an upgrade ?
1) Hopefully it will be picked up by our main developer and if it doesn't affect anything, then it will be set as default.
2) Don't upgrade I'm not too sure how to avoid it but I can't see many upgrades needing to overwrite this file - unless it is the one above. I guess if you made a symbolic link to your home directory for the conf file it might confuse the upgrade but it might also make it fail.
Personally, I'd just write a small script that checks the file and run it after any upgrades. I don't know how you upgrade - via XBMC, xbian-config or manually but you should see beforehand any upgrade that contains lirc.
Hi IriDium,
Looking forward to this being changed as default in the next version. I have set the subject of the first post to "Solved" as we have a workaround in the meantime.
Thanks to all for your help !
(18th Dec, 2013 04:06 AM)IriDium Wrote: [ -> ] (18th Dec, 2013 01:02 AM)MattS8 Wrote: [ -> ]1) that would be really great, do you want me to file this request somewhere ?
2) no, putting the fixed lirc_rpi.conf file in /home/xbian/.xbmc/userdata does not work, it is not picked up. As long as this is not yet made the default, would there be any other way to avoid re-applying the -u fix after an upgrade ?
1) Hopefully it will be picked up by our main developer and if it doesn't affect anything, then it will be set as default.
2) Don't upgrade I'm not too sure how to avoid it but I can't see many upgrades needing to overwrite this file - unless it is the one above. I guess if you made a symbolic link to your home directory for the conf file it might confuse the upgrade but it might also make it fail.
Personally, I'd just write a small script that checks the file and run it after any upgrades. I don't know how you upgrade - via XBMC, xbian-config or manually but you should see beforehand any upgrade that contains lirc.
@
mk01 has known about this for about two months, it's why he knew the fix... there must be an implication because I asked him to remove it a month or two ago
(19th Dec, 2013 05:14 AM)f1vefour Wrote: [ -> ]@mk01 has known about this for about two months, it's why he knew the fix... there must be an implication because I asked him to remove it a month or two ago
If there is an issue, maybe a change can be made so that the .conf is picked up first in the user directory and if not found, then default to the standard location.
(17th Dec, 2013 12:16 AM)MattS8 Wrote: [ -> ]2) in the meantime, as /etc/lirc/hardware/lirc_rpi.conf is a system file I assume that the file will be replaced again with the next update. Is there any way to configure this to avoid having to remove the "-u" again after new updates ?
all those listed files are considered as user configuration files and are not overwritten on reinstall in case they are changed.
etc/default/iguanaIR
etc/lirc/lircd.conf
etc/lirc/lircmd.conf
etc/lirc/remotes/devinput.conf
etc/lirc/remotes/mceusb.conf
etc/lirc/remotes/smt1000t.conf
etc/lirc/remotes/speedlink.xml
etc/lirc/remotes/srm7500.conf
etc/lirc/remotes/tigerfly.xml
etc/lirc/remotes/x10-or32e.conf
etc/lirc/remotes/xbox.conf
etc/lirc/hardware/custom.conf
etc/lirc/hardware/default.conf
etc/lirc/hardware/lirc_rpi.conf
etc/lirc/hardware/logitech_ultrax.conf
etc/lirc/hardware/mceusb.conf
etc/lirc/hardware/mceusb_event0.conf
etc/lirc/hardware/mceusb_event1.conf
etc/lirc/hardware/mceusb_event2.conf
etc/lirc/hardware/srm7500libusb.conf
etc/lirc/hardware/x10.conf
etc/lirc/hardware/xbox.conf