Author |
Message |
Martian
|
Posted: Fri Dec 02, 2011 10:51 am |
|
Joined: Wed Feb 08, 2006 6:13 pm
Posts: 480
Location:
IN
|
First of all let me start by thanking Cecil and the team for their hard work - you guys do a tremendous job and it is very appreciated by myself and my family!
As many of you now know there were many changes made to Lirc in LinHES 7.1. The biggest change is the move to kernel drivers for many IR receivers and transmitters which in many cases has made Lirc more or less unnecessary unless you require irexec events.
For years I've used a custom lircd.conf and lircrc with the Onkyo remote that came with my Receiver (using the CD/DVD button). After an upgrade I would just copy my custom config files over, restart Lirc and everything would "just work". No so this time.
I have a USB Streamzap IR receiver which has worked wonderfully for years. After finding a couple AAA batteries I have confirmed that the Streamzap remote that came with the Streamzap receiver works "out of the box" in 7.1 however nothing I have done has been able to get my custom Lirc config files to work with my Onkyo remote. I am however presently up and running using just the kernel drivers and a custom keymap - Lirc is disabled!!! The remote isn't quite as responsive as it was in previous versions but at least it works.
In theory it is possible to get the kernel dirvers to pass the IR codes to Lirc but I have been unsuccessful in getting that to work thus far, I think that would some the lack of responsiveness with the remote.
So, in the interest of shared knowledge (and heartache) here is what I've done so far - perhaps this information will be helpful to someone else (or at least serve as a warning)
Firstly, the following two threads from the XBMC forums have been extremely helpful and are a good read for anyone wanting to know more about the changes in Lirc:
http://forum.xbmc.org/showthread.php?t=104541
http://forum.xbmc.org/showthread.php?t=101151
For anyone wanting to use their own remote of course the most important thing is being able to use irw, mode2, and irrecord in order to test your setup and create your custom lircd.conf file. The problem is these commands just don't really work with the new kernel drivers. They have more or less been replaced by the ir-keytable command. In LinHES the ir-keytable command is provided in the v4l-utils package.
There is a problem however in LinHES. Version 0.8.1-1 of v4l-utils, which comes with LinHES 7.1 does NOT support the -t flag for the ir-keytable command which allows you to see the code outputs from your remotes in a similar fashion to irw and mode2.
I have opened a Bug report on this here: http://linhes.org/bugs/issues/800
I was able to build and install v4l-utils-0.8.5-1 from the main arch repo without any issues and can now use the ir-keytable -t command to discover the codes for my remotes. There were two additional packages needed to do this. One was in the LinHES repo and I forget what it was. The other was libjpeg-turbo which I build from the main Arch repo and replaces libjpeg.
This allowed me to create a custom keymap mapping the codes from my remote to keyboard keys. A full list of mappable keys can be found here:
http://xbmc.exstatic.org/ir_keys.txt
I placed this custom keymap in /etc/rc_keymaps and load it using ir-keytables -c -w /etc/rc_keymaps/myfile The -c flag clears any previous keymaps and the -w specifies my custom keymap file.
In order for this to work Lirc must NOT be running (sv stop lircd) This got my remote working using just the kernel drivers and a custom keymap. Lirc is no longer part of the equation (which means irexec is no longer an option).
I have yet to figure out how to load my custom keymap on reboot however I haven't really tried since my goal is still to be able to use Lirc eventually. I have a couple irexec events I like to use and as I stated earlier the remote just doesn't feel as "good" as it did with Lirc. I think this is do to it emulating key presses. Holding down a button on the remote behaves like holding down a key on a keyboard (one keypress, a pause, and then a barrage of keypresses in rapid fire). I'm sure there is a way to fix that but I haven't found it (nor have a looked for a solution).
Hopefully writing up my experience with my remotes in LinHES 7.1 will help someone else having a similar problem. If anyone has any questions or if anyone has found any solutions to my remaining problems (or has any suggestions) please let me know.
Martian
_________________ ABIT NF-M2 nView | Athlon 64 X2 3800+ | 2GB DDR2 800 | HDHomerun | GeForce 6150 (onboard) | WD 640 GB SATA HD | DVD-RW (sata) | StreamZap IR receiver with Logitech Harmony remote
Vizio 37" LCD HDTV (1080p)
|
|
Top |
|
|
alien
|
Posted: Mon Dec 05, 2011 10:39 am |
|
Joined: Mon Jun 21, 2004 5:28 am
Posts: 700
Location:
Germany
|
Wow. I wish those two summaries had existed when I was first confrontend with the IR kernel drivers. One of the downsides of open source is that the documentation often has to be reverse engineered by the users....
Anyway, I gave up and reverted to the old lirc. If you need to do that, the trick is to add the following to one of the startups (see http://www.gossamer-threads.com/lists/m ... 693#460693):
Code: echo none +lirc > /sys/class/rc/rc0/protocols
I get the feeling the kernel drivers are more appropriate for plug and play basic functionality and not so good for complex remote setups.
_________________ ASUS AT3N7A-I (Atom 330) TBS 8922 PCI (DVB-S2)
|
|
Top |
|
|
Martian
|
Posted: Mon Dec 05, 2011 12:36 pm |
|
Joined: Wed Feb 08, 2006 6:13 pm
Posts: 480
Location:
IN
|
Thanks for the reply alien!
Looks like similar advice to the LIRC entry on ArchWiki:
https://wiki.archlinux.org/index.php/LIRC
LIRC - ArchWiki wrote: After upgrading or installing Arch, an existing configuration stopped workingKernel module changeAs of kernel 2.6.36, LIRC modules have been included in the kernel. Arch's lirc package has included the older kernel modules, which work with lircd without any additional configuration. However, a recent update removed those older modules, which results in the stock kernel modules being used. Unfortunately, these kernel modules treat the remote as a keyboard by default, which is incompatible for lircd. To correct this, put the following line to /etc/rc.local: /etc/rc.local Code: echo lirc > /sys/class/rc/rc0/protocols You may also run that command as root to enable LIRC for your current session. Note: It is also a good idea to remove the old LIRC kernel module from your MODULES array in /etc/rc.conf, as it is no longer present. It appears to me that this does the same thing as Code: ir-keytable -p lirc but I could be wrong. Either way, I've had no success getting Lirc 9.x to play nice with my remote no matter what I have done.
I like the idea of the kernel drivers and I love the simplicity of the setup (get remote codes with ir-keytable -t and map them to keyboard presses in a keymap file) however in practice it falls far short of Lirc (at least for me). Key press detection is not very good and holding down a key has the same response as holding down on a keyboard key (which is expected but NOT desired).
Ideally I would like to get the kernel drivers to pass the key codes to Lirc (which in theory is possible) but I can't for the life of me get it working. I prefer not revert back to the old Lirc modules since obviously the kernel drivers are the path forward.
I've spent hours messing with this and have pretty much nothing to show for it (other than a less than happy wife). The thing that really kills me is that the StreamZap remote works flawlessly with Lirc "out of the box". In other words, going into Setup>LinHES Setup>Remotes and selecting Streamzap for both remote & receiver and Voila! I can run "irw" and see my key presses. So then, in theory, I should be able to simply copy my custom "lircd.conf" file over to "/etc/lircd.conf" and "irw" should work with my Onkyo remote (which has worked fine for years). Unfortunately this doesn't work.
The only difference I know of (other than obviously the codes) is that the Streamzap remote uses protocol=rc-5 and the Onkyo remote uses protocol=NEC. Changing the protocols with ir-keytable -p doesn't help however.
To add insult to injury I can't even get irrecord to work with my Onkyo remote. I've never had a problem before. Specifying a driver of "lirc-dev" and a device of "/dev/input/by-id/usb-Streamzap__Inc._Streamzap_Remote_Control-event-if00" allows irrecord to run and it works perfectly with the Streamzap remote however with the Onkyo remote after requesting that I hold down a key, I don't see the customary "...................." string, it just eventually errors out complaining about "gap not found".
Perhaps someone can explain to me how exactly Lirc is functioning in LinHES 7.1? Best I can tell the Streamzap receiver uses the kernel drivers but Lirc is also running and functional. Reviewing the conf file for the Streamzap remote shows that it is unchanged from previous versions therefore I see no reason why my known good Onkyo lircd.conf file doesn't appear to work.
I feel like I'm missing some simple thing that is unique to LinHES 7.1 that is preventing the kernel drivers and Lirc from playing nice. I'm really tempted to revert back to the Lirc modules however I fear that will be just delaying the problem.
Any help would be greatly appreciated!
Martian
_________________ ABIT NF-M2 nView | Athlon 64 X2 3800+ | 2GB DDR2 800 | HDHomerun | GeForce 6150 (onboard) | WD 640 GB SATA HD | DVD-RW (sata) | StreamZap IR receiver with Logitech Harmony remote
Vizio 37" LCD HDTV (1080p)
|
|
Top |
|
|
brfransen
|
Posted: Mon Dec 05, 2011 2:02 pm |
|
Joined: Fri Jul 21, 2006 11:12 pm
Posts: 1194
Location:
SC
|
alien wrote: Code: echo none +lirc > /sys/class/rc/rc0/protocols LH R7.1 does something very similar to this in the runit lircd run script. So if lircd is set to start on boot (by default it is) all in kernel ir decoding should be disabled. This can be confirmed by running ir-keytable and the only enabled protocol listed should be LIRC.
Martin, as for the Streamzap, I don't have one but I do have a MCE that is supported by the in kernel decoding and it works in R7.1 using LIRC. For your custom config did you create the remote in the ~/remotes as described at http://linhes.org/bugs/projects/linhes/wiki/Remotes?
Britney
|
|
Top |
|
|
bobmyth
|
Posted: Fri Feb 17, 2012 4:39 pm |
|
Joined: Wed Jan 18, 2006 8:36 pm
Posts: 199
|
brfransen wrote: Martin, as for the Streamzap, I don't have one but I do have a MCE that is supported by the in kernel decoding and it works in R7.1 using LIRC. For your custom config did you create the remote in the ~/remotes as described at http://linhes.org/bugs/projects/linhes/wiki/Remotes?
@Britney:
I also have an MCE receiver and I haven't been able to make any progress. Part of the issue may be that I also have an iMON receiver that I use for a display.
I've added both the MCE and iMON receivers to /etc/X11/xorg.conf.d/10-quirks.conf. When I run ir-keytable I get: Code: Found /sys/class/rc/rc0/ (/dev/input/event4) with: Driver mceusb, table rc-rc6-mce Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC Enabled protocols: LIRC Found /sys/class/rc/rc1/ (/dev/input/event5) with: Driver imon, table rc-imon-pad Supported protocols: other Enabled protocols: other
Not getting anything from irw. When I turn on debug for the mceusb kernel module I can see the receiver does see some pulses and spaces.
I tried using the link you mentioned in your post, but I am getting a 404 error. Maybe the server will be restored soon.
To add further confusion, the IR blaster on the MCE is working fine.
|
|
Top |
|
|
christ
|
Posted: Sun Feb 19, 2012 9:13 am |
|
Joined: Mon Dec 24, 2007 9:47 am
Posts: 535
Location:
Ottawa, Canada
|
|
Top |
|
|
christ
|
Posted: Mon Feb 20, 2012 10:06 am |
|
Joined: Mon Dec 24, 2007 9:47 am
Posts: 535
Location:
Ottawa, Canada
|
bobmyth wrote: Part of the issue may be that I also have an iMON receiver that I use for a display. I just went through this yesterday. The issue is that the imon driver has been completely rewritten. The good news is it is way simpler now than in the past! LinHes is using the kernel drivers and then feeding it up to lirc. I think is the right thing to do in general. Depending on the driver, lirc will either have to get its input through /dev/lircd? via the discussion above or DEVINPUT. Except for a few remotes, LinHES assumes the kernel driver supports lirc via the /dev/lircd? entry. imon uses DEVINPUT to communicate up the stack. You will need to create a file called /etc/runit/lirc.sh and put something like the following into it: Code: Code: #!/bin/bash /usr/sbin/lircd -r -n --driver devinput -d /dev/input/by-id/usb-15c2_ffdc- event-if00 --output /var/run/lirc/lircd replace the path after "-d" with what ever device your imon shows up as. You then need a new lircd.conf because the kernel driver passes up a normalized code set essentially matching other kernel driver output. A reasonably good starting point for your lircd.conf is at: http://lirc.sourceforge.net/remotes/devinput/lircd.conf.devinput Note with my imon the digits mapped differently so I had to change them. My digits started at 0x0200 as opposed to 0x000B. After that you will want to update your lircrc to match the new names in the "standardized" lircd.conf. Or you can butcher the lircd.conf which ever is easier for you. Per the wiki, your new lircrc and lircd.conf can then go into ~/remotes/imon- yourname/ so that you can select it from the LinHes service menu -> remotes. I also got my LCD going too last night which in reality is easier if you don't over think it like I did. It should just work with the driver although you may need to modify the /etc/LCDd.conf to match your specific device. For example I have the ffdc version of the LCD which requires the "imonlcd" driver vs the default "imon" driver specified in the LCDd.conf.
|
|
Top |
|
|
christ
|
Posted: Mon Feb 20, 2012 10:08 am |
|
Joined: Mon Dec 24, 2007 9:47 am
Posts: 535
Location:
Ottawa, Canada
|
BTW, to test these up the stack you need to know the following. The stack connects like this: device -> kernel driver (imon) -> lircd -> myth (via lircrc)
output from the kernel driver (any variant) is done with "ir-keytable -t". You must stop lirc for this to work with "sv stop lircd".
Once connected to lirc, you can test lirc output with irw as normal.
mode2 is not supported with at least devinput drivers but ith ir-keytable it doesn't matter.
|
|
Top |
|
|
bobmyth
|
Posted: Sat Feb 25, 2012 12:28 pm |
|
Joined: Wed Jan 18, 2006 8:36 pm
Posts: 199
|
Thank you to everyone who is trying to help me. To reduce complexity, I've blacklisted all imon drivers because I need to get the MCE usb working because it can both receive and transmit IR (need to control cable box). I was able to compile the ir-keytable with the "-t" option, though I keep getting an error, somethings about "protocols: No such file or directory". Now when I type ir-keytable, I get: Code: Found /sys/class/rc/rc0/ (/dev/input/event5) with: Driver mceusb, table rc-rc6-mce Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC Enabled protocols: LIRC Repeat delay = 500 ms, repeat period = 33 ms which is my MCE usb receiver, because the kernel shows this: Code: [ 4.439738] lirc_dev: IR Remote Control driver registered, major 249 [ 4.445855] Registered IR keymap rc-rc6-mce [ 4.445940] input: Media Center Ed. eHome Infrared Remote Transceiver (1784:0001) as /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.6/4-1.6:1.0/rc/rc0/input5 [ 4.445986] rc0: Media Center Ed. eHome Infrared Remote Transceiver (1784:0001) as /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.6/4-1.6:1.0/rc/rc0 [ 4.446160] mceusb 4-1.6:1.0: Registered Topseed eHome Infrared Transceiver on usb4:5 [ 4.446178] usbcore: registered new interface driver mceusb [ 4.462661] rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0 [ 4.462664] IR LIRC bridge handler initialized The bad news is that lirc does not work, nor does irw or irrecord. I am using 2 custom remote controls, but for now I pulled out my trusty Hauppauge silver from the closet. I used the remote set-up in the menu and selected the remote along with a SA-4200 for the IR blaster. The bad news is this did not work either, as best as I can tell it didn't even change any files in /etc/lirc. In the short term I would like to get 1 remote working. Next, I'd like to get my 2 custom remotes working. After that, I'd like to turn on the iMon driver again so I can get my VFD working.
|
|
Top |
|
|
christ
|
Posted: Sat Feb 25, 2012 10:51 pm |
|
Joined: Mon Dec 24, 2007 9:47 am
Posts: 535
Location:
Ottawa, Canada
|
bobmyth,
it looks like you should almost be there. If you stop lirc "sv stop lircd" and then use "ir-keytables -t" do you see the mapped key presses when you press the keys on the remote? You should get actual words like "KEY_PLAY" etc and a mapped number (e.g. KEY_PLAY (0x00CF) )
If you don't then the keytables aren't mapped correctly.
If you are, then start lirc again with "sv start lircd" and next check /etc/lirc/lircd.conf. It should have one or two entries which are includes to the relevant lircd.conf table for your remote. Look at the included file and verify that the numbers associated with the label (e.g. 0x00CF) output from "ir-keytables -t" match the entries in the included lircd.conf file. If they don't match then irw won't output anything.
|
|
Top |
|
|
bobmyth
|
Posted: Sun Feb 26, 2012 10:27 pm |
|
Joined: Wed Jan 18, 2006 8:36 pm
Posts: 199
|
Thanks again christ. Interesting news, when I do: Code: ir-keytable -c -w /etc/rc_keymaps/rc6_mce -p NEC,RC-5,RC-6,JVC,SONY -t and use the Hauppage silver remote, I get: Code: Read rc6_mce table Old keytable cleared Wrote 63 keycode(s) to driver Protocols changed to NEC RC-5 RC-6 JVC SONY Testing events. Please, press CTRL-C to abort. 1330316418.376010: event MSC: scancode = 1e01 1330316418.508011: event MSC: scancode = 1e01 1330316418.769006: event MSC: scancode = 1e02 1330316418.895008: event MSC: scancode = 1e02 1330316419.162002: event MSC: scancode = 1e03 1330316419.295009: event MSC: scancode = 1e03
However, I get nothing with my custom remotes. A few questions: 1. How to I get/make key maps for my custom remote controls? 2. From my readings, it appears this method avoid lirc all together, is that true? 3. Assuming I get this working , can I still use my IR blaster to control my cable box? Thanks so much.
|
|
Top |
|
|
christ
|
Posted: Mon Feb 27, 2012 8:46 am |
|
Joined: Mon Dec 24, 2007 9:47 am
Posts: 535
Location:
Ottawa, Canada
|
bobmyth wrote: However, I get nothing with my custom remotes. I don't know what your custome remotes are or what receiver you are using for these remotes. The remotes themselves will send out their own IR codes (depending on how you have programmed them) and the receiver must be able to receive them. The receiver will generate its own codes up to the driver layer. If they were working before they should start working when we figure this out. Note blacklisting the imon driver shouldn't be necessary and you can use it for the LCD later when you have the initial stuff worked out. bobmyth wrote: A few questions: 1. How to I get/make key maps for my custom remote controls? This shouldn't be necessary unless you have a very odd remote. All of the various keymaps are in /etc/rc_keymaps. You can try various ones using the "-w" switch on ir-keytables". The keymaps can depend on the receiver you are using so watch that. For example if you are using an MCE capable imon device then you would use the keymap imon_mce. If the keymaps are working you should get lines like "KEY_PLAY (0x00CF)" interspersed with the raw codes. Until you get something like this at this layer lirc won't work. If you still feel like you want to create a keymap, I found this thread which shows what one person did: http://forum.xbmc.org/showthread.php?t=101151bobmyth wrote: 2. From my readings, it appears this method avoid lirc all together, is that true? Not true. if you don't use lirc then key_map is intended to simulate a keyboard input. If you insert lirc then it won't go to the keyboard. However in your protocol list above, you did not add "lirc" which is required to create "/dev/lircd0". If you just use the command "ir-keytable" it will tell you what protocols are enabled and at least once above it did show lirc was enabled. Depending on the driver though it may send things to devinput instead of /dev/lircd0. You will need to look into the driver you are using to see which it uses. Usually if adding lirc to the protocol list does not create /dev/lircd0 (or similar) then it is likely using devinput. The imon for example used devinput. bobmyth wrote: 3. Assuming I get this working , can I still use my IR blaster to control my cable box?
You should be able to, although this will depend on the driver you are using; I'm not familiar enough with the device you have plugged in. I believe you also mentioned that you had an iMon LCD or VFD. I do have that working successfully. Note, time permitting over the next two days, I will write up a how-to on the wiki to explain the new architecture. I spent a weekend two weeks ago discovering it as I got my remotes going as well. I want to capture this while it is still fresh in my mind.
|
|
Top |
|
|
christ
|
Posted: Mon Feb 27, 2012 8:48 am |
|
Joined: Mon Dec 24, 2007 9:47 am
Posts: 535
Location:
Ottawa, Canada
|
BTW, what is the output of "lsusb". I want to see which imon device you have.
|
|
Top |
|
|
RacerX
|
Posted: Mon Feb 27, 2012 4:10 pm |
|
Joined: Sun Sep 05, 2004 7:06 pm
Posts: 690
|
Martian thanks for shedding a light on the change. My remote the snapstream firefly works fine in 7.2, but now I'm unable to extend that functionality into XBMC.
when I examine
/usr/share/xbmc/system/Lircmap.xml
my remote appears correct
What I can't figure out is the keymap file, previously I created a file and that worked since I updated to version 6.
/home/mythtv/.xbmc/userdata/keymaps/keymap.xml
Now it doesn't seem to work at all and I get no feedback so it's hard to isolate
|
|
Top |
|
|
bobmyth
|
Posted: Mon Feb 27, 2012 8:48 pm |
|
Joined: Wed Jan 18, 2006 8:36 pm
Posts: 199
|
christ wrote: BTW, what is the output of "lsusb". I want to see which imon device you have. Edited for brevity: Code: Bus 001 Device 003: ID 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller Bus 004 Device 005: ID 1784:0001 TopSeed Technology Corp. eHome Infrared Transceiver Again, I appreciate all your help. I believe you given me the techniques I need to get everything working. I will report back.
|
|
Top |
|
|