# lirc, nova-t remote & /dev/input issues SOLVED

## woZa

Hi. I am trying to get the nova-t-500 remote working with lirc.

I am using kernel 2.6.24-gentoo-r3 and running the latest v4l drivers...

I have emerged lirc with the devinput driver.

```
cat /etc/conf.d/lircd

# Arguments which will be used when launching lircd

LIRCD_ARGS=""

#Don't start lircmd even if there seems to be a good config file

#START_LIRCMD=false

#Try to load appropriate kernel modules

LOAD_MODULES=true

# Run "lircd --driver=help" for a list of supported drivers.

DRIVER="dev/input"

# If DEVICE is set to /dev/lirc and devfs is in use /dev/lirc/0 will be

# automatically used instead

DEVICE="/dev/input/event4"

MODULES=""

# Default configuration files for your hardware if any

LIRCD_CONF="/etc/lircd.conf"

LIRCMD_CONF=""

```

File is set to connect to /dev/input/event4 yet when I start irw to test the remote I get no output in the terminal. I check /var/log/messages I see

```
Mar 18 23:03:37 mythbox lircd-0.8.2[6471]: accepted new client on /dev/lircd

Mar 18 23:03:37 mythbox lircd-0.8.2[6471]: initializing '/dev/input/event0'
```

and it tries to connect to /dev/input/event0 not event4

WHY!!!!!

It worked fine in the old Ubuntu setup I had so I know it all works ok...

----------

## cyberjun

Have you seen this thread? https://forums.gentoo.org/viewtopic-t-655958-highlight-.html

----------

## woZa

Thanks. No I hadn't. So it seems that lirc changed it's conf.d file format somewhere along the line.

```
mythbox ~ # cat /etc/conf.d/lircd

# Options to pass to the lircd process

# for devices with lirc-kernel-module

#LIRCD_OPTS="-d /dev/lirc0"

#LIRCD_OPTS="-d /dev/lirc"

# for devices using the input-layer

LIRCD_OPTS="-H dev/input -d /dev/input/event4"

# Maybe this works (untested):

#LIRCD_OPTS="-H devinput name='*DVB*'"

```

The above works just fine with irw command. Now to setup the remote properly.

Thanks

Alex

----------

## furanku

The device which is assigned to your IR remote can change, as also for example USB mice or grachics tablets, get a devce node in /dev/input, and therefore these are dynamically created and deleted. IMHO the best way to avoid worrying about that is creating an udev rule which sets an symlink in your /dev/input directory with a meaningful name. First find out what name your device has, with my (old) Haupauge HVR-1100 that looks like that:

```
 $ cat /proc/bus/input/devices

...

I: Bus=0001 Vendor=0070 Product=9402 Version=0001

N: Name="cx88 IR (Hauppauge WinTV-HVR110"

P: Phys=pci-0000:01:09.2/ir0

S: Sysfs=/class/input/input4

U: Uniq=

H: Handlers=kbd event4

B: EV=100003

B: KEY=100fc312 214a80200000000 0 18000 41a800004801 9e168000000000 10000ffc

...

```

Then create an udev rule similar to this one:

```
 $ cat /etc/udev/rules.d/11-lirc.rules

KERNEL=="event*", SYSFS{name}=="cx88 IR (Hauppauge WinTV-HVR110", NAME="input/%k", SYMLINK="input/irremote", MODE="0666"
```

This should create a symlink /dev/input/eventX -> /dev/input/irremote", which you can use in your configs, without caring what is the correct value for "eventX".

Restart udev using

```
# udevstart

```

 if your system still have an undevstart script. I'm a bit confused by now as I just learnd, that udevstart has gone in newer versions, so I don't know the correct way to restart udev now. Reboot will cetainly work, but, hey .. we're not running windows

.

Alternativly you could give lirc itself the device as suggestet in the sample /etc/conf.d/lircd:

```
# for devices using the input-layer

LIRCD_OPTS="-H devinput -d /dev/input/by-path/pci-0000:01:09.2--event-ir"

# Maybe this works (untested):

#LIRCD_OPTS="-H devinput name='*DVB*'"

```

Relace the pci device number whit the correct values for your setup (there should be only one /dev/input/by-path/*--event-ir if you have just one IR reciever).

And in the end, it might turn out that all this is useless, as the kernel now treats IR devices by itself in the input-layer, so that you don't need lircd, but inputlircd, as discussed in the thread mentioned above.

I'm sorry but getting your IR control to work seems like a moving target these days, and most of the HOWTOS about that seems to be outdated. Looks like time to clean up the Gentoo documentation.

----------

## woZa

Hey thanks for that. Worked a treat (and udevstart still worked). Like you said it will probably break sometime soon with a kernel upgrade and we'll have to go through it all again with inputlircd

Cheers

Alex

----------

## furanku

 *woZa wrote:*   

> 
> 
> ```
> mythbox ~ # cat /etc/conf.d/lircd
> 
> ...

 

During my investigations to get my IR remote working I also found a lot of sources claiming that the name of the driver is "devinput" not "dev/input" (a slash in a name is IMHO calling for troubles). I'm no expert in lirc (well, I unintentionally learned a lot about it ...). So if there are still problems it might be worth a try to change that.

----------

## woZa

A quick restart of mythfrontend and it's working like a charm...   :Smile: 

----------

## woZa

 *furanku wrote:*   

>  *woZa wrote:*   
> 
> ```
> mythbox ~ # cat /etc/conf.d/lircd
> 
> ...

 

I tried devinput first off and it complained that it couldn't find the driver so tried dev/input and it worked. Go figure!

----------

## woZa

 *furanku wrote:*   

> The device which is assigned to your IR remote can change, as also for example USB mice or grachics tablets, get a devce node in /dev/input, and therefore these are dynamically created and deleted. IMHO the best way to avoid worrying about that is creating an udev rule which sets an symlink in your /dev/input directory with a meaningful name. First find out what name your device has, with my (old) Haupauge HVR-1100 that looks like that:
> 
> ```
>  $ cat /proc/bus/input/devices
> 
> ...

 

The above works fine from boot but if I restart mythbackend the IR attaches to the next free device (moves from input4 to input5) but the irremote link stays with input4 and the remote no longer works... Any ideas?

----------

## furanku

Hmmm .. that's strange. I don't see why restarting mythbackend should reconnect the IR receiver, and even if, udev should take care of this and delete the old device in /dev/input (and the symlink) and recreate them when the IR receiver is reconnected.

Could you take a look in your syslog if anything special happens when you restart the MythTV backend?

----------

## woZa

```
dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.

DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T)

DVB: registering frontend 1 (DiBcom 3000MC/P)...

MT2060: successfully identified (IF1 = 1220)

ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00c8681c00001a4d]

input: IR-receiver inside an USB DVB receiver as /class/input/input4

dvb-usb: schedule remote query interval to 150 msecs.

dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized and connected.

usbcore: registered new interface driver dvb_usb_dib0700

```

and if I restart the backend

```
input: IR-receiver inside an USB DVB receiver as /class/input/input5
```

while

```
mythbox ~ # ls -lah /dev/input/irremote

lrwxrwxrwx 1 root root 6 Mar 20 16:11 /dev/input/irremote -> event4

```

remains the same...   :Question: 

----------

## woZa

Ok. Just tried restarting mythbackend again and no change this time... Weird. The dvb_usb module must have been reloaded last time. Tried restarting the backend a few times and it seems to work fine now...

----------

## furanku

OK, maybe starting the Myth TV backend just loads the dvb_usb module, which is not done before, and that causes the new device being created. In my case it's similar, the cx88_dvb module also wasn't autoloaded by udev at boot time, when it created the device for the IR receiver. So I simply put it in /etc/modules.autoload.d/kernel-2.6, to ensure it's loaded at boot time. Although reloading that module in my setup didn't cause a remapping of the IR device, maybe that helps in your case too. I still don't understand why the reloading of the dvd_usb module doesn't triggers an udev event, if that's the reason for the remapping ...

----------

