As of 2.6.15-rc1 (actually the change was originally made in 2.6.14-git8), there is no more /dev/input/event0 node. The nodes now start at event1 and up. This breaks the autodetect feature in the remote plugin for VDR. I was able to kludge a fix by hacking the default to the event I am currently using, but a real fix should be made instead.
This is *hacked* fix for a remote that is using event3. This only a kludge.
--SNIP--
--- remote-0.3.3/remote.c.orig 2005-11-13 01:59:30.000000000 -0800 +++ remote-0.3.3/remote.c 2005-11-13 02:19:18.000000000 -0800 @@ -706,7 +706,7 @@
// use default device if nothing could be identified if (devtyp[i] == 'i' && strcmp(devnam[i], "autodetect") == 0) - devnam[i] = "/dev/input/event0"; + devnam[i] = "/dev/input/event3"; } // for i
for (int i = 0; i < devcnt; i++)
C.Y.M wrote:
As of 2.6.15-rc1 (actually the change was originally made in 2.6.14-git8), there is no more /dev/input/event0 node. The nodes now start at event1 and up. This breaks the autodetect feature in the remote plugin for VDR. I was able to kludge a fix by hacking the default to the event I am currently using, but a real fix should be made instead.
This is *hacked* fix for a remote that is using event3. This only a kludge.
OK, this seems like a much better fix for 2.6.15-rc1+ kernels and the remote plugin. Now autodetect works again for the events.
Regards,
C.Y.M wrote:
C.Y.M wrote:
As of 2.6.15-rc1 (actually the change was originally made in 2.6.14-git8), there is no more /dev/input/event0 node. The nodes now start at event1 and up. This breaks the autodetect feature in the remote plugin for VDR. I was able to kludge a fix by hacking the default to the event I am currently using, but a real fix should be made instead.
This is *hacked* fix for a remote that is using event3. This only a kludge.
OK, this seems like a much better fix for 2.6.15-rc1+ kernels and the remote plugin. Now autodetect works again for the events.
Now that I think about it more, this is only going to be a problem for people using udev (where devices are created in /dev each time on boot).
Regards,
C.Y.M wrote:
C.Y.M wrote:
C.Y.M wrote:
As of 2.6.15-rc1 (actually the change was originally made in 2.6.14-git8), there is no more /dev/input/event0 node. The nodes now start at event1 and up. This breaks the autodetect feature in the remote plugin for VDR. I was able to kludge a fix by hacking the default to the event I am currently using, but a real fix should be made instead.
This is *hacked* fix for a remote that is using event3. This only a kludge.
OK, this seems like a much better fix for 2.6.15-rc1+ kernels and the remote plugin. Now autodetect works again for the events.
Now that I think about it more, this is only going to be a problem for people using udev (where devices are created in /dev each time on boot).
How is the autodetect feature intended to work? Is it able to follow a "moving target"? I had the problem that the IR device changes from event1 to event2 when I connect a keyboard to the VDR box (what I do only in the rare cases where access via SSH cannot be used).
On my SuSE 9.3 based VDR this is solved by an udev rule that generates a symbolic link /dev/input/ir to the /dev/input/eventx where the IRC is actually located.
Wolfgang
Regards,
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Wolfgang Fritz wrote:
How is the autodetect feature intended to work? Is it able to follow a "moving target"? I had the problem that the IR device changes from event1 to event2 when I connect a keyboard to the VDR box (what I do only in the rare cases where access via SSH cannot be used).
The autodetect feature uses the first DVB remote control which can be found.
If you add a keyboard the event device will move. The remote plugin will find the DVB receiver and start key-learning for that interface. This has to be done only once for each interface.
I'm using this feature for a long time with my dual 2.4/2.6 system.
On my SuSE 9.3 based VDR this is solved by an udev rule that generates a symbolic link /dev/input/ir to the /dev/input/eventx where the IRC is actually located.
You can do that but it's not worth the effort imho. ;-)
Oliver
C.Y.M wrote:
C.Y.M wrote:
As of 2.6.15-rc1 (actually the change was originally made in 2.6.14-git8), there is no more /dev/input/event0 node. The nodes now start at event1 and up. This breaks the autodetect feature in the remote plugin for VDR. I was able to kludge a fix by hacking the default to the event I am currently using, but a real fix should be made instead.
This is *hacked* fix for a remote that is using event3. This only a kludge.
OK, this seems like a much better fix for 2.6.15-rc1+ kernels and the remote plugin. Now autodetect works again for the events. ...
No, that's not the way to go. It would break the remote plugin for kernel 2.4.
<flame> The way kernel 2.6.x is being developed is a pain in the a**. :§$% They are changing interfaces at will, and it is virtually impossible to write drivers for the 2.6 series... </flame>
I will not look into this before 2.6.15 is out. For now you should specify the interface with the '-i' option.
Oliver
I demand that C.Y.M may or may not have written...
C.Y.M wrote:
As of 2.6.15-rc1 (actually the change was originally made in 2.6.14-git8), there is no more /dev/input/event0 node. The nodes now start at event1 and up. This breaks the autodetect feature in the remote plugin for VDR. I was able to kludge a fix by hacking the default to the event I am currently using, but a real fix should be made instead.
This is *hacked* fix for a remote that is using event3. This only a kludge.
OK, this seems like a much better fix for 2.6.15-rc1+ kernels and the remote plugin. Now autodetect works again for the events.
There could be gaps in the list due to some other device (probably USB) having been unplugged, leaving, for example, event0, event1 and event3. Now imagine that event3 is for the DVB remote control.
The attached patch *should* fix this.
(For completeness, I'm also attaching my older patches.)
There could be gaps in the list due to some other device (probably USB) having been unplugged, leaving, for example, event0, event1 and event3. Now imagine that event3 is for the DVB remote control.
The attached patch *should* fix this.
(For completeness, I'm also attaching my older patches.)
Thanks, Darren. This works great with both 2.4 and 2.6 kernels.
Best Regards,
-
C.Y.M -
Darren Salt -
Oliver Endriss -
Wolfgang Fritz