| View previous topic :: View next topic |
| Author |
Message |
sidamos
Apprentice
Joined: 16 Dec 2007
Posts: 153
|
 Posted: Wed Sep 15, 2010 11:54 am Post subject: Lirc does not work anymore (ioctl problem?) |
 |
|
HI!
I had a working setup with Lirc 0.8.5 and Kernel 2.6.32. I tried to update to 2.6.35 and Lirc would not compile. So, I tried various newer Lirc versions and patches. Eventually, it compiled, but did not create /dev/lirc0.
So, I decided to go back to 2.6.32 and Lirc 0.8.5. But this does not work anymore either now! /etc/modprobe.conf looks OK. Lircd config looks OK.
dmesg:
| Code: |
lirc_dev: IR Remote Control driver registered, major 253
lirc_dev: module is already loaded
lirc_dev: module is already loaded
lirc_serial: auto-detected active low receiver
|
Lircd starts OK. But when I start irw, I get this in /var/log/messages:
| Code: |
Sep 15 13:34:54 linux lircd-0.8.5[13972]: accepted new client on /dev/lircd
Sep 15 13:34:54 linux lircd-0.8.5[13972]: could not get hardware features
Sep 15 13:34:54 linux lircd-0.8.5[13972]: this device driver does not support the LIRC ioctl interface
Sep 15 13:34:54 linux lircd-0.8.5[13972]: major number of /dev/lirc0 is 253
Sep 15 13:34:54 linux lircd-0.8.5[13972]: LIRC major number is 61
Sep 15 13:34:54 linux lircd-0.8.5[13972]: check if /dev/lirc0 is a LIRC device
Sep 15 13:34:54 linux lircd-0.8.5[13972]: Failed to initialize hardware
|
When I start mode2, it is pretty much the same:
| Code: |
mode2: could not get hardware features
mode2: this device driver does not support the LIRC ioctl interface
mode2: major number of /dev/lirc0 is 253
mode2: LIRC major number is 61
mode2: check if /dev/lirc0 is a LIRC device
|
I have tried various stuff (including another receiver hardware) and searched the Internet all day, but can't get it working anymore. Any hints would be greatly appreciated.
The only other things I did was updating to a newer nvidia binary driver and VirtualBox version, so I could compile the modules for the newer kernel.
Thomas
Last edited by sidamos on Thu Sep 16, 2010 7:40 am; edited 2 times in total |
|
| Back to top |
|
 |
depontius
Advocate
Joined: 05 May 2004
Posts: 2156
|
| Posted: Wed Sep 15, 2010 2:18 pm Post subject: |
|
|
LIRC is in the midst of going into the mainline kernel, and there are too many changes happening right now for me to have fully digested what's going on.
So I've decided to keep my mythfrontend system that uses LIRC at 2.6.34-r* until this stuff all settles out. Even at that, I had to do some funny stuff in /etc/portage in order to get lirc-0.8.6-r3 to build properly, but a bit of consulting on bugzilla gave me what I needed. I don't have ready access to that system at the moment, so I can't tell exactly what I did until tonight.
By the time it all settles out, I'm under the impression that LIRC is going to work through the /dev/input/* subsystem instead of /dev/lirc*. I'm also under the impression that for many devices /dev/lircd.conf will essentially be subsumed into the kernel, though they will have provisions for "raw" devices that do userspace decoding, as is done today. I'm also under the impression that even lirc-0.8.6 today will work with the /dev/input/* subsystem if you have the right kernel stuff. I haven't had the time to futz around with it, so I've stayed back with what I know works - gentoo-sources-2.6.34-r* and lirc-0.8.6-r3.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
sidamos
Apprentice
Joined: 16 Dec 2007
Posts: 153
|
| Posted: Wed Sep 15, 2010 2:30 pm Post subject: |
|
|
In the meantime, I searched further and I think now that the problem is the different major number. Lirc expects/wants 61, but /dev/lirc0 is 253.
I also tried Lirc 0.8.6 (had to comment the i2c patch to make it compile), but there is the same problem. It wants 61.
And 0.8.7-pre1 hangs with kernel 2.6.32 during boot.
Can someone perhaps tell me, how I get /dev/lirc0 to be created with major number 61? I tried
| Code: | alias char-major-61 lirc_serial
alias /dev/lirc* lirc_serial |
in /etc/modprobe.conf to no avail.
I also found some udev rules, but I don't know how to force the major number to 61. |
|
| Back to top |
|
|
sidamos
Apprentice
Joined: 16 Dec 2007
Posts: 153
|
| Posted: Thu Sep 16, 2010 7:42 am Post subject: |
|
|
I talked to the maintainer of Lirc and he says, that the problem is incompatible ioctl versions between kernel and userspace.
I cannot figure out, why this happens with Lirc 0.8.5 and 2.6.32, when it worked before.
I also don't understand, why Lirc cvs (0.8.7) and 2.6.35 does not create /dev/lirc0 and gives me this in dmesg:
| Code: |
lirc_dev: IR Remote Control driver registered, major 253
lirc_dev: exports duplicate symbol lirc_get_pdata (owned by kernel)
lirc_dev: exports duplicate symbol lirc_get_pdata (owned by kernel)
lirc_serial: auto-detected active low receiver
|
|
|
| Back to top |
|
|
Fitzcarraldo
Guru
Joined: 30 Aug 2008
Posts: 345
Location: United Kingdom
|
| Posted: Thu Sep 16, 2010 1:11 pm Post subject: Device /dev/lirc/0 isn't being created |
|
|
I was successfully using LIRC 0.8.6 source (patched with lirc-LP529514.patch and autoconf.patch) with the lirc-0.8.6-r2.ebuild (no longer in the Portage tree) and the 2.6.33 kernel. But I upgraded the kernel to 2.6.35-r4 to close the kernel security hole in earlier kernels, and now I'm having the same problem as you with LIRC not creating /dev/lirc/0. I've tried building LIRC 0.8.7, with the drivers patched by hand along the same lines of autoconf.patch, i.e.:
| Code: | #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 33)
#include <linux/autoconf.h>
#else
#include <generated/autoconf.h>
#endif |
by just renaming lirc-0.8.7_pre1.ebuild in the Portage tree to lirc-0.8.7.ebuild. It builds, but I end up with no /dev/lirc/0. According to section 13.7 in the Gentoo Wiki article on LIRC (Device /dev/lirc/0 isn't being created), "it is likely because udev is unable to complete the creation of the device" and "re-emerging udev may fix the problem". Unfortunately, it doesn't in my case.
I also noticed the following message at boot:
| Code: | | Sep 15 14:41:02 localhost udevd-work[6061]: kernel-provided name 'lirc0' and NAME= 'lirc/0' disagree, please use SYMLINK+= or change the kernel to provide the proper name |
so I changed the file /etc/udev/rules.d/lirc.rules from:
| Code: | | KERNEL=="lirc[0-9]*", NAME="lirc/%n" |
to:
| Code: | | KERNEL=="lirc[0-9]*", SYMLINK+="lirc/%n" |
which I'm not sure is correct, but has got rid of the error message at boot.
Anyway, LIRC is extremely frustrating. |
|
| Back to top |
|
|
sidamos
Apprentice
Joined: 16 Dec 2007
Posts: 153
|
| Posted: Thu Sep 16, 2010 1:19 pm Post subject: |
|
|
| I don't even have lirc.rules for udev... |
|
| Back to top |
|
|
Fitzcarraldo
Guru
Joined: 30 Aug 2008
Posts: 345
Location: United Kingdom
|
| Posted: Thu Sep 16, 2010 1:43 pm Post subject: |
|
|
| sidamos wrote: | | I don't even have lirc.rules for udev... |
According to the Gentoo Wiki article on LIRC:
| Quote: | | Warning: When you are using devfs or sysfs with your kernel, the /dev/lirc device node will disappear again once you reboot your machine. In that case the LIRC kernel module will generate the required entry every time it is loaded. But the device node will not be visible as /dev/lirc, but might be located in a different location like e.g. /dev/lirc/0. Please be aware of this fact when starting programs that access the device node like mode2 or lircd. You will have to use the --device command line option of these programs to point them to the correct location. When using sysfs together with the udev daemon you should copy the lirc.rules file located in the contrib directory of the source package to /etc/udev/rules.d/. This will make sure that the device node will be created. |
so that's what I did, and it worked (at least when I was using 0.8.6-r2 and the 2.6.33 kernel). No dice with LIRC 0.8.7 and the 2.6.35-r4 kernel, though, although that could be for a completely different reason. I'm at a loss. |
|
| Back to top |
|
|
sidamos
Apprentice
Joined: 16 Dec 2007
Posts: 153
|
| Posted: Thu Sep 16, 2010 8:56 pm Post subject: |
|
|
| OK, 2.6.34 and Lirc 0.8.7-pre1 works for me, even without udev rules. 2.6.35 does not create /dev/lirc0. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 2156
|
| Posted: Mon Sep 20, 2010 7:13 pm Post subject: |
|
|
| sidamos wrote: | | OK, 2.6.34 and Lirc 0.8.7-pre1 works for me, even without udev rules. 2.6.35 does not create /dev/lirc0. |
Did you have to do anything special? I've been struggling with lirc since early this year, occasionally hitting "stable spots". Early this year before the problems started, I was happily running gentoo-sources-2.6.32-r? (number forgotten) with lirc-0.8.6-r2. Then for some time, nothing I tried worked, until some time this summer I built gentoo-sources-2.6.34-r? (6?) and found some tricks with /etc/portage/env to get lirc-0.8.6-r3 to work.
This past weekend I was upgrading the kernel because of the recent 32-bit hole. I first tried gentoo-sources-2.6.34-r10, but now lirc-0.8.6-r3 won't build against it. Next I decided to go back to gentoo-sources-2.6.32-r17, which still has the 32-bit fix, but lirc-0.8.6-r3 won't build against that, either. Right now I'm back to the old 2.6.32-r(6?) with the exposed kernel, banking on the fact that this is a limited function myth backend machine, so the exposure is low.
So you are able to build gentoo-sources-2.6.34-r10 with lirc-0.8.7-pre1 without extra patches, fixes, etc? I'm more than a little paranoid about this setup, because if I lose my current lirc-0.8.6-r2/-r3 install, I don't know how to get back to a working remote. I have no faith in even trying 2.6.35 until all of the /dev/input stuff is worked out, and even with that I have no idea what level of lirc to use with it, or how.
Incidentally, the other reason for going back to 2.6.32 is that wake-on-usb stopped working with 2.6.34. I had thought it was just my problem, but recently there was a thread here where someone else lost wake-on-lan going from 2.6.32 to 2.6.34.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
sidamos
Apprentice
Joined: 16 Dec 2007
Posts: 153
|
| Posted: Mon Sep 20, 2010 8:18 pm Post subject: |
|
|
| I have 2.6.34-gentoo-r6 and lirc 0.8.7_pre1 working with no special tricks that I know of. |
|
| Back to top |
|
|
M
Guru
Joined: 12 Dec 2006
Posts: 427
|
| Posted: Mon Sep 20, 2010 9:00 pm Post subject: |
|
|
I use 2.6.35 with lirc-9999 which I hacked from portage ebuild and I use it for some time, with new kernel version and that ebuild never had the troubles.
I used before lirc_gpio driver which is now incompatible with kernel, I managed for some time to patch every new version of kernel and to add back the stuff that was removed from it to have my remote working as usual.
Now I have serial irda controller which just works, because with my stupid tv card I don't have /dev/input/event* which I can control (with other card I do have it but it is not mine )
I hope that once all problems are sorted out, moving lirc to kernel will solve problems, I really had nothing but trouble with lirc for years... |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 2156
|
| Posted: Sun Oct 03, 2010 3:22 pm Post subject: |
|
|
| sidamos wrote: | | I have 2.6.34-gentoo-r6 and lirc 0.8.7_pre1 working with no special tricks that I know of. |
Finally got around to trying this with this morning's servicing. Built the newest gentoo-sources-2.6.34-r? and lirc-0.8.7_pre1 built and works just fine on it. Thanks.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
miroR
Apprentice
Joined: 05 Mar 2008
Posts: 228
|
| Posted: Wed Apr 20, 2011 6:21 am Post subject: |
|
|
This suggestion in the main text of this wiki:
http://en.gentoo-wiki.com/wiki/LIRC
File: /etc/udev/rules.d/20-lircd.rules
| Code: | | SUBSYSTEM=="usb", ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="xxxx", SYMLINK+="the_name_you_want" |
in my kernel:
# uname -r
for my IR remote (lines are from /var/log/messages):
| Code: | Apr 20 06:30:33 myBox kernel: [ 10.033458] input: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci0000:00/0000:00:1a.0/0000:05:15.0/rc/rc0/input4
Apr 20 06:30:33 myBox kernel: [ 10.033517] rc0: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci0000:00/0000:00:1a.0/0000:05:15.0/rc/rc0
Apr 20 06:30:33 myBox kernel: [ 10.033595] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 0 |
I had to modify into:
| Code: | | KERNEL=="event*",ATTRS{vendor}=="0x14f1",SYMLINK="input/irremote" |
to get (after reboot) the symlink:
| Code: | # ls -l /dev/input/irremote
lrwxrwxrwx 1 root root 6 2011-04-20 08:38 /dev/input/irremote -> event4 |
The other possible details of my configuration of interest for this hardware,
File: /etc/make.conf
| Code: | [...]
USE="lirc"
LIRC_DEVICES="hauppauge_dvb"
[...] |
File: /etc/conf.d/lircd
| Code: | | LIRCD_OPTS="-d input/irremote" |
######## so far so good. But... ########
dmesg output:
...
| Code: | [ 9.654895] IR RC5(x) protocol handler initialized
[ 9.656982] tuner 0-0061: chip found @ 0xc2 (cx88[0])
[ 9.677670] cx88/0: cx2388x v4l2 driver version 0.0.8 loaded
...
[ 9.705579] IR RC6 protocol handler initialized
...
[ 9.799864] input: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci0000:00/0000:00:1a.0/0000:05:15.1/rc/rc0/input4
[ 9.799928] rc0: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci0000:00/0000:00:1a.0/0000:05:15.1/rc/rc0
...
[ 9.818318] lirc_dev: IR Remote Control driver registered, major 251
[ 9.821571] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 0
[ 9.821576] IR LIRC bridge handler initialized
... |
File: /var/log/messages
...
| Code: | Apr 20 06:39:09 myBox kernel: [ 9.818318] lirc_dev: IR Remote Control driver registered, major 251
Apr 20 06:39:09 myBox kernel: [ 9.821571] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 0
Apr 20 06:39:09 myBox kernel: [ 9.821576] IR LIRC bridge handler initialized
..
Apr 20 06:39:17 myBox lircd-0.8.7[7022]: lircd(default) ready, using /var/run/lirc/lircd
...
Apr 20 06:42:50 myBox lircd-0.8.7[7022]: accepted new client on /var/run/lirc/lircd
Apr 20 06:42:50 myBox lircd-0.8.7[7022]: could not get file information for input/irremote
Apr 20 06:42:50 myBox lircd-0.8.7[7022]: default_init(): No such file or directory
Apr 20 06:42:50 myBox lircd-0.8.7[7022]: Failed to initialize hardware
Apr 20 06:44:49 myBox lircd-0.8.7[7022]: removed client
Apr 20 06:45:25 myBox lircd-0.8.7[7022]: caught signal
Apr 20 06:45:25 myBox lircd-0.8.7[8396]: lircd(default) ready, using /var/run/lirc/lircd
... |
A few more details of possible interest.
Both
| Code: | | myBox # cat /dev/input/irremote |
and
| Code: | | myBox # cat /dev/lirc/0 |
react on pressing keys on my standard gray Hauppauge remote, but
| Code: | myBox # irrecord /dev/lirc/0
irrecord: error in configfile line 1
irrecord: reading of file '/dev/lirc/0' failed
irrecord: file "/dev/lirc/0" does not contain valid data |
| Code: | myBox # irrecord /dev/input/irremote
irrecord: error in configfile line 1
irrecord: reading of file '/dev/input/irremote' failed
irrecord: file "/dev/input/irremote" does not contain valid data
myBox # |
Baffling and frustrating...
Anyone trying to get similar issues done, here's a few links with clues I ended up at in these excruciating few hours I spent, but to no avail yet:
http://forums.gentoo.org/viewtopic-t-844718-start-0.html
http://www.hardwareforums.com/threads/howto-hauppauge-remote-control-in-kubuntu.10264/
I'm still hopeful this can be done, because this is fairly recent:
http://archive.pfb.no/2010/12/14/fully-working-remote-control/
But that's a whole lot of studying for me to understand... I don't know if I have that much time, really.
Anyone made it on gentoo? |
|
| Back to top |
|
|
miroR
Apprentice
Joined: 05 Mar 2008
Posts: 228
|
| Posted: Mon May 16, 2011 6:52 pm Post subject: Mr. Kernel still misunderstands Ms. Lirc language? |
|
|
So.
Does Mr. Kernel still misunderstand Ms. Lirc language?
Or did you leave me behind?
Little time, less expertise here.
Anyone knows a little more on this kernel talk saga, to share with the needy here?
 |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
