I was aware of the new ir-keytable package, but we could not test this - no hardware. I also provided this info to the other users having problems with mceusb, but they overlooked the info or didn't test or just didn't respond about failure / success.
so to summarize, you installed the package, of course also module has to be loaded, but no lircd should be started at all ? how xbmc is then accessing the remote ? through uinput and mapping to just userlevel input device?
I have an old af9015 DVBT usb stick with remote ... would this be worth trying to see it myself?
or maybe should we add/install ir-keytable to default image ?
(25th Aug, 2013 10:11 PM)mk01 Wrote: [ -> ]I was aware of the new ir-keytable package, but we could not test this - no hardware. I also provided this info to the other users having problems with mceusb, but they overlooked the info or didn't test or just didn't respond about failure / success.
so to summarize, you installed the package, of course also module has to be loaded, but no lircd should be started at all ? how xbmc is then accessing the remote ? through uinput and mapping to just userlevel input device?
I have an old af9015 DVBT usb stick with remote ... would this be worth trying to see it myself?
or maybe should we add/install ir-keytable to default image ?
The gist of how it works is without lirc all together.
Mapping is done through udev and /etc/rc_keymaps/yourfile
ir-keytable should be included and the linked tutorial should be refined (exactly which remotes work with the kernel method) and included in the xbian wiki.
You should definitely try your old USB stick with remote to gain the necessary knowledge of how ir-keytable works.
ok, will put ir-keytable into dependencies for beta2 and will try stick if I find it. from the discussion is it 100%, that USB connected remotes should make lircd not to start or is it still not conclusive ?
mk
I'm not sure if all USB adapters should use ir-keytable, it is also possible to use a combination of ir-keytable with lirc.
I only have a GPIO IR receiver I ripped out of an old Sharp combination DVD/VHS player so I'm unable to test.
The kernel modules for common usb-ir-remotes are already in the distribution, and they are loaded by default.
The kernel modules map those remotes to keys. What happens then depends on who is listening for these key-events.
XBMC listens vents on key events by default, so does lirc devinput driver, both together cause a conflict. So in order to use lirc with devinput, you have to somehow tell xbmc to expect input only from lirc, and not from keyboard events - and while I succeeded in making it work this way *once*, I could not figure out how I did it. Its a complicated setup and I don;t believe it is worth it.
ir-keytables exist with the ir-keytable package for most popular remotes. Customization is really easy. New xbmc compatible ir-keytables are by far simpler to distribute or customize than dealing with lirc, devinput & keyboard.xml
Dan
(26th Aug, 2013 06:01 PM)Dbbd Wrote: [ -> ]So in order to use lirc with devinput, you have to somehow tell xbmc to expect input only from lirc, and not from keyboard events - and while I succeeded in making it work this way *once*, I could not figure out how I did it. Its a complicated setup and I don;t believe it is worth it.
Dan,
the XBMC setting whether input device is sending keyboard presses does not make any difference here ?
Thanks for the help -- for me, it was a usb issue. From
http://elinux.org/R-Pi_Troubleshooting#R-Pi_does_not_respond_to_key_presses_.2F_Keyboard_randomly_repeats_key_presses
I added dwc_otg.speed=1 to the end of my cmdline.txt and now the remote works better.
Just to summarize a bit, my remote was working very partially (less than in other forum posts: no key worked on the first press, and then only some keys worked after holding down). It wasn't a lirc/ir-keytable conflict or anything because I could kill lirc and xbmc and just run ir-keytable -t and get similar bad results. I updated xbian as of 8/26, and it was still sticking. Then I added the one "dwc_otg.speed=1" to cmdline.txt and now it is working. I guess this slows down the usb speed, so I hope my usb hard drive will still be fast enough to read from.
I do have some keys that aren't working in xbmc, but they are showing up in ir-keytable -t, so I figure I can make them work.
I'd like ideally to use the IR blaster portion of the receiver, so I might try to migrate from keymaps to lirc or at least get lirc working as a blaster only. I suppose I can have xbmc send irsend commands via lirc.
I'm happy to do any testing.
unfortunately you will limit you hdd a lot. speed=1 means USB1, 12MBit/s. So theoretical speed of 1.5MB/s. and of course shared on bus, not per device.
To use lirc instead of the built in kernel method I believe this is what must be done to resolve conflicts.
Terminal
sudo echo lirc > /sys/class/rc/rc0/protocols
(28th Aug, 2013 01:55 PM)f1vefour Wrote: [ -> ]To use lirc instead of the built in kernel method I believe this is what must be done to resolve conflicts.
Terminal
sudo echo lirc > /sys/class/rc/rc0/protocols
Is that the same as ir-keytable -p lirc ?
And I would still need to slow down usb, right?