[mythtv-users] MCE remote after 0.21 -> 0.27 upgrade

[Alec Leamas]

On 10/09/15 21:02, Jerome Yuzyk wrote:
> On Thursday, September 10, 2015 11:22:08 AM Alec Leamas wrote:
>>
>> I have gone back to the config guide, from the top, and I fail at
>>
>>       $ irdb-get download devinput/devinput.lircd.conf
>>       $ sudo cp devinput/devinput.lircd.conf  /etc/lirc/lircd.conf.d
>>       $ lircd --device /dev/input/event13 --driver devinput
>>       $ irw
>>
>> Here, you mess things up (poorly written guide?). The path we have
>> entered when using mode2 and pulse/space durations does *not* involve
>> devinput. It's about "Getting the key symbols using an LIRC driver",
>> which uses another config file.
>
> I took this right from the config guide and adjusted for my event when I made another pass at it after getting mode2 to show something from setting the LIRC protocol.
>
>> But since you *do* have a working setup giving pulse/space durations,
>> you should actually be fine. The first step is to try one or two
>> existing config files, found using 'irdb-get find mceusb' (skip the imon
>> ones). If these does not work, you need to use irrecord(1) to record a
>> new config file. It is some work, but usually not that hard.

 > The remote does work - I've been using it by editing my rc6_mce > > i
 > keymap to provide keysymbols that are recognized by Myth, like
 > turning the KEY_MEDIA that the green Windows button generates into
 > KEY_M because neither LIRC nor Myth recognize KEY_MEDIA. I think.
 > Still, I'm determined to get LIRC running so I can ir-blast and do
 > some things with ireexec.

OK, this means that you must use the path described as "Getting the Key 
Symbols using LIRC".  In general, this means that you cannot use
the devinput driver or config file. In fact, you must disable the the 
kernel decoding in the kernel.

[longer explanation] Obviously, the kernel driver (a. k. a.  kernel 
module) works fine. In the default state, it sends the IR input 
(actually a sequence of space/mark durations) to the linux input layer 
which decodes it into events and makes them available on a 
/dev/input/whatever device. These events are then basically treated as 
keyboard events, with it's limitations. These include that you can't 
write to a keyboard (no IR blasting) and that only a single application 
can receive the events (i. e., no irexec in parallel with other apps.)

What the devinput driver does is to claim the decoded events from the 
/dev/input/X device. It then maps them to LIRC events using the 
devinput.lircd.conf file and makes them available on the LIRC socket. 
This makes it possible for multiple programs to use the events, but 
there is still no blasting capabilities. So, we need another path. We 
cannot use the devinput driver or config file for anything.

The first step is to instruct the kernel module to send the IR input to 
/dev/lirc0 instead of /dev/input/X. This is a big change, the data on 
/dev/lirc0 is not decoded in any way, it's just the space/mark durations 
received. This is what ir-keytable -p LIRC  (or the echo ... thing) 
does. From this point, there is no data available to anyone except on 
/dev/lirc0[/longer explanation]


> I was wondering how I use this file. I've had a /etc/lirc/lircd.conf.d/mceusb.lircd.conf in place from the beginning but it's never made a difference. I've tried setting "driver=mceusb" in /etc/lirc/lirc_options.conf but it's never resulted in anything: I can only use "default" or "devinput". I've also made it the sole contents of
> /etc/lirc/lircd.conf but nothing there either. How do I enable it?


Next step is to instruct lircd to fetch the data from /dev/lirc0. This 
is done through the two options --driver=default and 
--device=/dev/lirc0. This works, since this is what we test with mode2. 
Give the same options to lircd (using lirc_options.conf).

The third step is to give the right decoding info to lircd so it knows 
how to translate the timing info from /dev/lirc0 to keypresses. This is 
where the mceusb.lircd.conf comes into play. Just drop it in 
/etc/lirc/lirc.conf.d/ (you might want to remove other files there).

At this point you should be able to test by starting the service and 
using irw. If ot doesn't work, the most plausible reason is that the 
config file is broken somehow.

In case of problems, don't forget to check the logs: journalctl -b0 
/usr/sbin/lircd.

If nothing else works, use irrecord to create a new config file. 
However, the one you have used should be OK, there are no changes in the 
data format.


> It _might_ be a packaging thing. Starting in Fedora 22 (lirc 0.9.2a) there is no lirc-remotes package, as there is in Fedora 21 and CentOS 7.1. Instead I think it's replaced by lirc-config, which doesn't have any mceusb*.conf. The hauppauge*.conf in there are RC-5.
>

No, it's an upstream thing. Upstream has ditched the lirc-remotes which 
was part of the distribution. The reason was that there was two sets of 
remotes, one in the distribution (~300) and the rest on the website. It 
was concluded that it was better to have everything in one place and add 
some tooling to make it easier to manage the remotes (there is roughly 
2500 remotes there as of now).

Try 'irdb-get find mceusb' It definitely lists and downloads a file, at 
least for me. lirc-setup should work fine as well, using the devinput 
driver and searching for 'mceusb' in the remote search form. However, 
lirc-setup has a lot of rough edges so to speak.

Since mceusb is such a common case, it indeed might make sense to add a 
canned configuration to lirc-setup for it. Perhaps to 0.9.4 (where we 
will try to make it easier to configure also inn other ways...)



Cheers!


--alec