# Lirc does not work anymore (ioctl problem?)

## sidamos

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:

```

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:

```

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:

```

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.

ThomasLast edited by sidamos on Thu Sep 16, 2010 7:40 am; edited 2 times in total

----------

## depontius

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.

----------

## sidamos

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.

 :Sad: 

Can someone perhaps tell me, how I get /dev/lirc0 to be created with major number 61? I tried

```
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.

----------

## sidamos

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:

```

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

```

----------

## Fitzcarraldo

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.:

```
#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:

```
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:

```
KERNEL=="lirc[0-9]*",   NAME="lirc/%n"
```

to:

```
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.

----------

## sidamos

I don't even have lirc.rules for udev...

----------

## Fitzcarraldo

 *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.

----------

## sidamos

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.

----------

## depontius

 *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.

----------

## sidamos

I have 2.6.34-gentoo-r6 and lirc 0.8.7_pre1 working with no special tricks that I know of.

----------

## M

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  :Sad:  )  

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...

----------

## depontius

 *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.

----------

## miroR

This suggestion in the main text of this wiki:

http://en.gentoo-wiki.com/wiki/LIRC

File: /etc/udev/rules.d/20-lircd.rules

```
SUBSYSTEM=="usb", ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="xxxx", SYMLINK+="the_name_you_want"
```

in my kernel:

# uname -r

```
2.6.38-gentoo-r2
```

for my IR remote (lines are from /var/log/messages):

```
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:

```
KERNEL=="event*",ATTRS{vendor}=="0x14f1",SYMLINK="input/irremote"
```

to get (after reboot) the symlink:

```
# 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

```
[...]

USE="lirc"

LIRC_DEVICES="hauppauge_dvb"

[...]
```

File: /etc/conf.d/lircd

```
LIRCD_OPTS="-d input/irremote"
```

######## so far so good. But... ########

dmesg output:

...

```
[    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

...

```
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

```
myBox # cat /dev/input/irremote 
```

and

```
myBox # cat /dev/lirc/0 
```

react on pressing keys on my standard gray Hauppauge remote, but

```
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
```

```
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:

https://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?

----------

## miroR

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?

 :Wink: 

----------

