From: Simon H. <sim...@co...> - 2011-04-15 02:43:37
|
Sorry James, I just had another quick look at the nec decoder in the latest stable kernel and it will not correctly decode your tivo remote, failing on the command checksum. Support for it is in the current mainline (2.6.39-rc3), but this means you won't be able to use my approach (yet). Sorry for wasting your time, please ignore my earlier email. Maybe you'll have better luck with one of the .conf files Jarod pointed to in another email. Simon. On 15 April 2011 11:41, Simon Haines <sim...@co...>wrote: > On 15 April 2011 04:14, James Sumners <jam...@gm...> wrote: > > >> Yes, if you could point me to the documentation (or other), that would >> be helpful. >> > > From Jarod's mail later in this thread, it seems the TiVo keymap will at > some future stage make it into the kernel mainline. When this happens, your > remote will just work. Until then you could try the lircd.conf Jarod > mentions is sitting on his laptop, or try the path I am on, which is to > route decoded signals via the keymap to the input layer, and use lircd to > route the input layer events to applications that use the lirc subsystem (eg > mythtv). > > Up to you. The reason I'm using this approach is that the userspace > lirc_mceusb driver is 'dead and gone' and so I can't decode pulse/space > signals from /dev/lirc0 (there is no valid driver option to pass to lircd > anymore). Instead the kernel mceusb driver now handles this. It loads its > own keymap for the remotes that usually are bundled with the receiver, which > I need to override because I'm using a different remote altogether. > > Note that I'm using a recent kernel (a spanking new 2.6.38) and lirc 0.9.0. > As I understand it, it's a bit of a mess at the moment with everything in > flux due to major changes in kernel's IR subsystem. I expect within this > year things will have settled down and the major distributions will have > embraced the new order, and remote control handling will be significantly > better than it ever has been before. Let me caveat all of this by saying > that I've only recently started looking into the IR subsystem and don't know > much about it at all. A lot of what I'm saying could very well be nonsense, > and indeed I could be giving you bad information. If so, I hope someone more > familiar with the project will jump in and correct me as soon as possible. > > If you want to try the approach I'm testing (routing via the event layer), > and don't want to recompile your kernel with Jarod's patch that provides a > kernel keymap for the tivo remote, you can create your own keymap from > Jarod's patch. Look at the 'struct rc_map_table tivo' and for each entry > take the hex number (first part), strip off the first four hex digits 'a10c' > and combine it with the second part in the form: 0x900f=KEY_MEDIA etc. Put > each new entry on its own line in a file and call it 'tivo.table' (or > whatever). > > Now load the table with the command: sudo ir-keytable -v -s rc0 -p nec -c > -w tivo.table > This should give you a bunch of debug output to the effect that the > protocol is now 'nec', and your keytable has been decoded and loaded, after > clearing whatever keytable was already there (most likely the "rc-rc6-mce"). > > Now you can test whether this all hangs together by looking at the events > generated using 'evtest'. Point this to the event device mounted by dev_lirc > on your system (in my case it was /dev/input/event5) and press a few buttons > on your remote. All going well, you'll get output like this: > Input driver version is 1.0.1 > Input device ID: bus 0x3 vendor 0x471 product 0x815 version 0x0 > Input device name: "Media Center Ed. eHome Infrared Remote Transceiver > (0471:0815)" > Supported events: > Event type 0 (Sync) > Event type 1 (Key) > Event code 2 (1) > Event code 3 (2) > ...etc... > Event type 20 (Repeat) > Testing ... (interrupt to exit) > Event: time 1302779158.714791, type 4 (Misc), code 4 (ScanCode), value 409 > Event: time 1302779163.454581, type 4 (Misc), code 4 (ScanCode), value 40a > > If you get something like this, it means the kernel-side of your setup > works OK. It's now a matter of routing the scancodes to applications > listening on the lirc interface. This should be a matter of starting lircd > using the devinput driver, the /dev/input/eventX device, and the > lircd.conf.devinput file, but I haven't had the time to test this myself > yet. I think that's how it's supposed to work anyway. > > If anyone on the list knows a better way of doing this, or thinks that I'm > giving bum advice, please jump in and set matters straight. In the meantime > James I'll let you know how I get on. Good luck! > Simon. > > > On 15 April 2011 04:14, James Sumners <jam...@gm...> wrote: > >> On 4/13/2011 23:32, Simon Haines wrote: >> > I've only decoded the first two entries from your .conf file, if you >> > need any help with how to decode the rest, let me know >> >> Yes, if you could point me to the documentation (or other), that would >> be helpful. >> >> ~ James >> >> >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about >> boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> > > |