You are not logged in.
In Linux everything is treated as a file, which is something it borrowed from UNIX's design. The kernel sets up special files where you can both read and write states to query and change various settings. For example, you can tune how often virtual memory swaps out, or the set the scheduler for various disk drives by writing to these special files. In the case of remote controls, it sets up these special files to configure how the kernel interprets the signals from the remote. By default, it treats the remotes like a keyboard, and writing "lirc" to these special files tells it to interpret the signals in the way lirc requires.
For the remotes, it sets up a directory for the remotes (/sys/class/rc), and a directory for each remote (such as /sys/class/rc/rc0) to place the special files to control the remote. I would expect to see only one directory for each remote, but you have three (rc0, rc1, and rc2) which seems really weird. Either your kernel isn't reading your USB buses correctly, or there's something wonky with your receiver. If you can get it working with one or more of those echo statements, I suppose it doesn't matter much each way, but if you encounter other issues you might need to debug it further. If you do need to investigate further, you'll probably need to post in the kernel mailing list. (http://kernel.org/)
Last edited by akb825 (2011-04-12 06:46:19)
Offline
Thanks for that info. Regarding getting my lirc to work its unfortunately not happening. I added all 3 of those lines to /etc/rc.local and then tried one at a time (I had already tried the rc0) doing a /etc/rc.d/lircd restart each time. Still no response to the remote and no irw responses. So do you reckon I need to post in the kernel forums?
Offline
Restarting lircd isn't sufficient. Whenever you change rc.local, you must either manually apply the changes (such as by running those commands as root) or reboot. Keep in mind that if you run those commands manually, when you try something new what you did previously may still be in affect. In order to be in a truly "clean" state, the easiest way is to reboot.
I would suggest that you first execute
echo lirc | sudo tee /sys/class/rc/rc0/protocols
and see if your remote works. If so, then put the echo for rc0 in your rc.local file. If not, then execute the following:
echo lirc | sudo tee /sys/class/rc/rc1/protocols
If that works, then put the echo for rc1 in your rc.local file. If that doesn't work, then execute the following:
echo lirc | sudo tee /sys/class/rc/rc2/protocols
If that works, then put the echo for rc2 in your rc.local file.
Assuming one of those works, reboot after adding the appropriate line to rc.local. If it works, great, otherwise you may need to echo to multiple rc directories in your rc.local.
Last edited by akb825 (2011-04-13 02:51:21)
Offline
Beautiful. It works after the echo lirc commands for both rc1 and rc2 (or perhaps as you say its only rc1 and that setting is persisting after the rc2 command). Will try them one at a time in the rc.local file and reboot - probably tomorrow morning when the system isn't recording anything.
I need to read up on what these echo pipe tee commands do when I have a moment.
Thanks for your help. Very much appreciated. Wouldn't have been able to get close to figuring this out on my own.
Offline
Excellent - and thanks again. I put the rc1 echo in /etc/rc.local rebooted and the remote is working. Will try rc2 out of interest next time I decide to reboot. Any ideas how to interrogate why I have 3 rc devices?
Offline
I think your best bet is to ask on the mailing list at http://kernel.org, especially since it could potentially be due to a bug.
Offline
Thanks. Will do.
Offline
I still have a problem;
ir-keytable shows me 2 devices (weird i only have one)
Found /sys/class/rc/rc0/ (/dev/input/event3) with:
Driver budget_ci, table rc-tt-1500
Supported protocols:
Enabled protocols:
Extra capabilities: <access denied>
Found /sys/class/rc/rc1/ (/dev/input/event5) with:
Driver mceusb, table rc-rc6-mce
Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC
Enabled protocols: LIRC
Extra capabilities: <access denied>
I enabled the lirc function on boot in /sys/class/rc/rc1 and irw is working fine now.
But XBMC doesnt recognize any key of my MCE Remote. Worked perfectly fine before the update.
Offline
Sorry plantoschka can't help you. I'm sure akb will be able to, but thanks to your as I didn't know about the ir-keytables command. It has solved the mystery of why I have 3 remote devices. Two of them (rc0 and rc2) are my pci tv tuner cards which come with remote controls, but which I don't use. (Is there any benefit to blocking the creation of the rc device file for them and if so how would I do that?).
sudo ir-keytable -
Found /sys/class/rc/rc0/ (/dev/input/event3) with:
Driver cx88xx, table rc-winfast
Supported protocols:
Enabled protocols:
Repeat delay = 500 ms, repeat period = 33 ms
Found /sys/class/rc/rc1/ (/dev/input/event6) 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
Found /sys/class/rc/rc2/ (/dev/input/event9) with:
Driver af9015, table rc-empty
Supported protocols: NEC
Enabled protocols:
Repeat delay = 500 ms, repeat period = 33 ms
Cheerrs
belbo
Offline
But XBMC doesnt recognize any key of my MCE Remote. Worked perfectly fine before the update.
Did you overwrite your /etc/lircd.conf (or /etc/lirc/lircd.conf) file since updating? Or is your /etc/lircd.conf including the default mceusb configuration instead of being a copy of it? If either of these are the case, then the names of the buttons have changed, since the default configuration file has changed. If this is the cause of your problems, you have two options: one is to re-map the controls for your remote, and the other is to replace your /etc/lircd.conf with this. (https://wiki.archlinux.org/index.php/Li … ion_change)
Sorry plantoschka can't help you. I'm sure akb will be able to, but thanks to your as I didn't know about the ir-keytables command. It has solved the mystery of why I have 3 remote devices. Two of them (rc0 and rc2) are my pci tv tuner cards which come with remote controls, but which I don't use. (Is there any benefit to blocking the creation of the rc device file for them and if so how would I do that?).
The only way I know of blocking the creation of those devices is to disable kernel module for them. However, I don't think it hurts anything by having them there. I will, however, update my bug report to suggest setting the protocol to all rc directories for cases such as yours.
Offline
Ok, I've tried everything written in this thread and in the wiki. I tried even more. But the RC is absolutely not working. Actually I can create a /etc/lircd.conf with irrecord -d /dev/lirc0. I can start lircd. But after spending hours for trying to reconfigure it, the RC still doesn't do anything - at least not with irexec or irw -, but now the keyboard doesn't do anything, too, if I start lircd and irw. So I need to reset the computer.
# echo lirc > /sys/class/rc/rc0/protocols doesn't do anything. In fact lirc is already in this file.
I don't have mceusb loaded, but edac_mce_amd. I don't know if this is related. Loading mceusb doesn't help either. But I doubt that I need mceusb, because I haven't got a USB IR receiver. I've got a Terratec Cinergy 1400 DVB-T.
These are the relevant devices:
# ls -l /dev/lirc*
crw------- 1 root root 252, 0 22. Apr 12:43 lirc0
# ls -l /dev/input/by-path
insgesamt 0
lrwxrwxrwx 1 root root 9 22. Apr 12:43 pci-0000:03:06.0-event-ir -> ../event4
# ls -l /dev/input
insgesamt 0
crw-r----- 1 root root 13, 68 22. Apr 12:43 event4
This is my current /etc/conf.d/lircd.conf:
#
# Parameters for lirc daemon
#
PIDFILE0="/var/run/lircd0.pid"
#LIRC_DEVICE0='/dev/input/event3'
#LIRC_DEVICE0=phys='pci*/ir0'
LIRC_DEVICE0='/dev/input/by-path/pci-0000:03:06.0-event-ir'
#LIRC_DRIVER='dev/input'
LIRC_DRIVER='devinput'
LIRC_EXTRAOPTS=''
LIRC_CONFIGFILE='/etc/lircd.conf'
I tried every commented option, too. Btw., when I tried LIRC_DEVICE0='/dev/input/event3' the correct device was, of course, event3. It just changes after almost every reboot.
These are the relevant modules which are loaded:
# lsmod | grep lirc
ir_lirc_codec 4179 0
lirc_dev 9471 1 ir_lirc_codec
rc_core 14623 9 ir_lirc_codec,rc_cinergy_1400,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,ir_nec_decoder,cx88xx
# lsmod | grep ir
ir_lirc_codec 4179 0
lirc_dev 9471 1 ir_lirc_codec
ir_sony_decoder 2179 0
ir_jvc_decoder 2273 0
ir_rc6_decoder 2785 0
ir_rc5_decoder 2273 0
ir_nec_decoder 2593 0
rc_core 14623 9 ir_lirc_codec,rc_cinergy_1400,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,ir_nec_decoder,cx88xx
# lsmod | grep rc
ir_lirc_codec 4179 0
rc_cinergy_1400 1217 0
lirc_dev 9471 1 ir_lirc_codec
ir_rc6_decoder 2785 0
ir_rc5_decoder 2273 0
rc_core 14623 9 ir_lirc_codec,rc_cinergy_1400,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,ir_nec_decoder,cx88xx
And removing /etc/udev/rules.d/70-infrared.rules doesn't help either.
This has worked for many years without any big changes.
Has anybody an idea how to fix this, if it's not a bug at all?
Offline
Ok, after searching a lot I found that my /proc/bus/input/devices says that about my RC:
I: Bus=0001 Vendor=153b Product=1166 Version=0001
N: Name="cx88 IR (TerraTec Cinergy 1400 "
P: Phys=pci-0000:03:06.0/ir0
S: Sysfs=/devices/pci0000:00/0000:00:14.4/0000:03:06.0/rc/rc0/input3
U: Uniq=
H: Handlers=kbd event3
B: PROP=0
B: EV=100013
B: KEY=108fc210 204300000000 0 8000 208000000001 9e168000000000 ffc
B: MSC=10
How can I remove this kbd handler for this device? I guess this could be the culprit. It actually should only be event3.
Offline
It looks like your lircd.conf is specifying a driver, so if that driver has changed with the recent update it might not work. For reference, my /etc/conf.d/lircd.conf is:
LIRC_DEVICE="/dev/lirc0"
LIRC_DRIVER=""
LIRC_EXTRAOPTS=""
LIRC_CONFIGFILE=""
By having it as simple as possible, it will be less sensitive to changes such as the recent update.
If that doesn't work, can you post the output of the following commands?
cat /sys/class/rc/rc0/protocols
sudo ir-keytable
Offline
Changing /etc/conf.d/lircd.conf to yours indeed doesn't work.
In the past it only worked with specifying this driver. Originally I had to use devinput and sometime I had to change it to dev/input. It doesn't find this device even if it's existing while it finds the device phys='pci*/ir0'. Btw., upsteam's documentation also mentions this device.
cat /sys/class/rc/rc0/protocols:
rc-5 nec rc-6 jvc sony lirc
I tried every protocol by executing
echo {protocol} > /sys/class/rc/rc0/protocols
Nothing worked.
sudo ir-keytable:
Found /sys/class/rc/rc0/ (/dev/input/event4) with:
Driver cx88xx, table rc-cinergy-1400
Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC
Enabled protocols:
Repeat delay = 500 ms, repeat period = 33 ms
I also changed the ir-keytable to rc-cinergy-1400 before. I can't remember which ir-keytable I had before. But both didn't work.
And this is the output of irrecord:
# irrecord -H dev/input -d phys='pci*/ir0' /tmp/remote
Hold down an arbitrary button.
irrecord: gap not found, can't continue
irrecord: closing '/dev/input/event4'
Running
# echo lirc > /sys/class/rc/rc0/protocols
# irrecord -d /dev/lirc0 /tmp/remote
let me enter the keys and indeed creates a /tmp/remote but with a very strange content. Copying this file to /etc/lirc/lircd.conf and running lircd with this config, irw still doesn't do anything and my keyboard doesn't work anymore, too, so that I need to hard reset my computer.
This is the first part of my usual /etc/lirc/lircd.conf:
begin remote
name Terratec_Cinergy_1400_DVB-T
bits 16
eps 30
aeps 100
one 0 0
zero 0 0
pre_data_bits 16
pre_data 0x8001
gap 135787
toggle_bit 0
begin codes
power 0x0074
1 0x0002
2 0x0003
3 0x0004
This is the first part of the /tmp/remote created by irrecord -d /dev/lirc0 /tmp/remote:
begin remote
name /tmp/remote
flags RAW_CODES|CONST_LENGTH
eps 30
aeps 100
gap 123512
begin raw_codes
name KEY_POWER
9250 4500 500 500 750 500
500 1750 500 500 750 500
500 500 750 500 500 500
750 1500 750 1500 750 500
500 1750 750 250 750 1500
750 1500 750 1500 750 1500
750 500 750 250 750 500
750 500 500 500 750 500
500 500 750 250 750 1750
500 1750 500 1750 500 1750
500 1750 500 1750 500 1750
500
name KEY_1
9000 4500 500 500 750 500
750 1500 750 500 500 500
750 500 500 500 750 500
500 1750 500 1750 500 500
750 1500 750 500 500 1750
500 1750 500 1750 500 500
750 1500 750 500 500 500
750 500 500 500 750 500
500 500 750 1500 750 500
500 1750 500 1750 500 1750
750 1500 750 1500 750 1500
750
name KEY_2
9000 4500 750 250 750 500
750 1500 750 500 500 500
750 250 750 500 750 500
500 1750 500 1750 500 500
750 1500 750 500 500 1750
500 1750 500 1750 500 1750
500 1750 500 500 750 500
500 500 750 500 500 500
750 500 500 500 750 500
500 1750 500 1750 500 1750
750 1500 750 1500 500 1750
750
name KEY_3
9250 4250 750 500 750 500
500 1750 500 500 750 500
500 500 750 500 500 500
750 1500 750 1500 750 500
500 1750 500 500 750 1500
750 1500 750 1500 750 500
500 500 750 1500 750 500
500 500 750 500 500 500
750 500 500 1750 750 1500
750 250 750 1500 750 1500
750 1500 750 1500 750 1750
500
Offline
That's weird, it looks like it's not enabling any protocols, even though it lists them. You can try specifying cx88xx as the driver in /etc/conf.d/lircd.conf. If that doesn't work, you'll probably have to ask on the lirc for further help. (https://lists.sourceforge.net/lists/listinfo/lirc-list)
Offline
I already asked on this mailing list but haven't got an answer, yet.
I guess it could have something to do with this output of /proc/bus/input/devices:
I: Bus=0001 Vendor=153b Product=1166 Version=0001
N: Name="cx88 IR (TerraTec Cinergy 1400 "
P: Phys=pci-0000:03:06.0/ir0
S: Sysfs=/devices/pci0000:00/0000:00:14.4/0000:03:06.0/rc/rc0/input3
U: Uniq=
H: Handlers=kbd event3
B: PROP=0
B: EV=100013
B: KEY=108fc210 204300000000 0 8000 208000000001 9e168000000000 ffc
B: MSC=10
See "H: Handlers=kbd event3". I guess it's somehow handled as a keyboard and the event handler is ignored. That's why I asked if somebody knows how this kbd handler can be disabled or deactivated for this device.
cx88xx is not a supported driver, btw.
Offline
I guess the driver parameter is different from the kernel module, then.
The newer kernel modules treat the remote as a keyboard by default, but setting the protocol is supposed to change how it treats it. (such as "lirc" for use with lirc) Either there's something in your configuration that we're missing that's making it so you can't set the protocol, or the kernel module for your remote is broken. If further attempts to configure lirc fail, you might want to ask on the kernel mailing list to see if it's the kernel module itself acting up.
Offline
My problem seems to be identical. I'm using a hauppauge grey with a pinnacle pctv hdtv pci card cx88xx ir reciever. Worked until the update, same issues as cyberpatrol.
Offline
Just uploaded files and whatnot on this bug
Need help before the wife kills me!
Last edited by lastdeadmouse (2011-04-28 05:56:30)
Offline
Really man, linux devs need to freaking stop breaking things that are working just fine! Getting my remote to work AGAIN is taking the good part of the day already! And for what reason..? I've not seen any reason to change it. Good job screwing up guys, specially good for the "stable" linux image. Yuck, quit fooling around! Things like this make me mad.
Edit
I QUIT trying! I tried every option provided in here and it's still not working. I tried it on 2 different pc's and the results remain the same. Absolutely nothing in irw. Odd since irrecord works but the resulting conf file isn't working!
Last edited by markg85 (2011-04-30 18:49:11)
Offline
I started a thread on the lirc mailing list which is in the meantime moved resp. CC'ed to the linux-media mailing list. And there seem to be one or two other threads about the same or at least similar issues. But there's no solution, yet.
Offline
The problem seems to have causeed the ir device to corrupt data, at least on mine. After an irrecord that "works", irw shows random codes over and over for any key I press. Obviously not the remote as it does it with the harmony as well.
Offline
I've been hit by the changing /dev/input/event id numbers problem since the upgrade to kernel 2.6.38 and solved it today by giving in and accepting that a remote control which can be configured as a keyboard using lirc's devinput driver should be configured as a keyboard using lirc's devinput driver. My problem is three potential remote controls
$ ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event3) with:
Driver mceusb, table rc-rc6-mce
Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC
Enabled protocols: RC-6
Extra capabilities: <access denied>
Found /sys/class/rc/rc1/ (/dev/input/event7) with:
Driver dib0700, table rc-dib0700-rc5
Supported protocols: NEC RC-5 RC-6
Enabled protocols: RC-5
Extra capabilities: <access denied>
Found /sys/class/rc/rc2/ (/dev/input/event8) with:
Driver ir-kbd-i2c, table rc-msi-tvanywhere-plus
Supported protocols:
Enabled protocols:
Extra capabilities: <access denied>
but only one, a trusty old Microsoft MCE RC-6, that is connected and that I want to use. I don't have lirc installed, just lirc-utils, and what I did was:
Copied /usr/share/lirc/remotes/devinput/lircd.conf.devinput to /etc/lirc/lircd.conf
Found the /dev/input/by-id name for the MCE remote:
$ ls /dev/input/by-id
usb-Logitech_USB_RECEIVER-event-mouse
usb-Logitech_USB_RECEIVER-mouse
usb-NOVATEK_USB_Keyboard-event-if01
usb-NOVATEK_USB_Keyboard-event-kbd
usb-Philips_eHome_Infrared_Transceiver_PH00GHNI-event-if00 <--That one!
Added it to /etc/conf.d/lircd.conf as the LIRC_DEVICE and also specified devinput as the LIRC_DRIVER
#
# Parameters for lirc daemon
#
LIRC_DEVICE="/dev/input/by-id/usb-Philips_eHome_Infrared_Transceiver_PH00GHNI-event-if00"
LIRC_DRIVER="devinput"
LIRC_EXTRAOPTS=""
LIRC_CONFIGFILE=""
Rebooted
Adjusted ~/.lircrc to the new key names, using irw and a listing generated by running
$ sudo ir-keytable -s rc0 -r
scancode 0x800f0400 = KEY_NUMERIC_0 (0x200)
scancode 0x800f0401 = KEY_NUMERIC_1 (0x201)
...
scancode 0x800f0480 = KEY_BRIGHTNESSDOWN (0xe0)
scancode 0x800f0481 = KEY_PLAYPAUSE (0xa4)
Enabled protocols: RC-6
Moving to devinput has actually given me a simpler setup with no need to use ir-keytable at boot to change the ir-remote protocol to lirc (neater than echoing lirc to /sys/class/rc/rc?/protocols) and no need to set any kernel module options to stop double-keystrokes. Now I have time to concentrate on whatever consequences Gnome 3.0 is going to bring now that it's escaped from [testing]!
Offline
@lastdeadmouse: This can have something to do with the ir-keytables, the protocols (none of them are activated by default in Arch Linux) or other things. I don't know enough about that. It's just what I understood so far. But there indeed seem to be some upstream issues. Maybe you should also read and post on the lirc and linux-media mailing lists.
Last edited by cyberpatrol (2011-05-01 00:21:48)
Offline
@lastdeadmouse: This can have something to do with the ir-keytables, the protocols (none of them are activated by default in Arch Linux) or other things. I don't know enough about that. It's just what I understood so far. But there indeed seem to be some upstream issues. Maybe you should also read and post on the lirc and linux-media mailing lists.
I had the same problem with any protocol activated (of the ones that actually worked). My assumption is that 2.6.38 broke the cx88xx kernel module at least for some chipsets. At least everyone I've seen with my problem has a cx88. I gave up on the problem for the time being (had worked on it for days) and just went back to 2.6.37.4-1 and lirc-0.9.whatever a few minutes ago. Restored my lircd.conf backups (and nvidia-beta lol) and all is working again for now. I'll just hold off on a kernel upgrade until I have a good reason, as this is my myth box and kind of important (with a wife and kids )
Offline