Re: MCE receiver problem
Alec Leamas <[email protected]>
| Newsgroups | gmane.comp.hardware.lirc |
|---|---|
| Message-ID | <[email protected]> |
Hi again! > Hello Alec, > > On Friday, March 17, 2017 Alec Leamas wrote: >> On 15/03/17 01:29, Petric Frank wrote: >> > maybe this is not exactly a lirc problem. Please point me to correct >> > location if i am wrong here. >> >> As presented, this is a kernel issue - the basic decoding and >> ir-keytable is part of the kernel package. > > This was my impression also. I think the main problem here ist that the ir > remote is not detected as remote control device and no entry > /sys/class/rc/rc* is created. So i was not able to switch to the correct > keymap and i'm stuck with the default one. It might be that the kernel now uses it as a hid device. The output (tail) from dmesg when (re-)inserting the USB dongle is the key info here. > Is there an easy way to "sniff" the ir receiver ? > And perhaps evaluate the correct (kernel) scan codes as result ... Basically, no idea. This is hairy, kernel stuff. > Currently lirc 0.9.0 is marked stable in gentoo. Would it be better to use > the latest unstable version in gentoo of lirc (0.9.4) ? Perhaps. But it's not just to install, you need to do some packaging or similar to be able to install it. To make things more complicated. 0.9.4 is systemd-oriented... > At a first read of [1] - take the data via devinput driver by lirc from > /dev/input/eventxx, correct ? Only if you get all keys from the kernel. Otherwise, you need to use the default driver, if the kernel provides a /dev/lirc0 device. > As i have read older versions of lirc had a driver named mceusb(2). This > module seem no more part of lirc. Would this be a problem ? No. The former mcesub lirc driver has been upstreamed to the kernel since long. --alec ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot