Remote plugin breakage with 2.6.15-rc1+ kernel

Message ID 43771BE1.5020508@syphir.sytes.net
State New
Headers

Commit Message

C.Y.M Nov. 13, 2005, 10:56 a.m. UTC
  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,
  

Comments

C.Y.M Nov. 13, 2005, 11:53 a.m. UTC | #1
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,
  
Wolfgang Fritz Nov. 13, 2005, 1:23 p.m. UTC | #2
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
>
  
Oliver Endriss Nov. 13, 2005, 3:48 p.m. UTC | #3
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
  
Oliver Endriss Nov. 13, 2005, 4:05 p.m. UTC | #4
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
  

Patch

--- remote.c.orig	2005-11-13 01:59:30.000000000 -0800
+++ remote.c	2005-11-13 02:47:18.000000000 -0800
@@ -675,7 +675,7 @@ 
         {
             char nam[80];
 
-            for (int j = 0; ; j++)
+            for (int j = 1; ; j++)
             {
                 sprintf(nam, "/dev/input/event%d", j);
                 fh[i] = open(nam, O_RDONLY);
@@ -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/event1";
     } // for i
 
     for (int i = 0; i < devcnt; i++)