Message ID | 43771BE1.5020508@syphir.sytes.net |
---|---|
State | New |
Headers |
Received: from c-24-10-6-146.hsd1.ca.comcast.net ([24.10.6.146] helo=nofear.bounceme.net) by www.linuxtv.org with esmtp (Exim 4.50) id 1EbFWU-0006ju-5m for vdr@linuxtv.org; Sun, 13 Nov 2005 11:55:47 +0100 Received: from [10.1.1.66] (hades [10.1.1.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by nofear.bounceme.net (Postfix) with ESMTP id 6958C73546 for <vdr@linuxtv.org>; Sun, 13 Nov 2005 02:55:10 -0800 (PST) Message-ID: <43771BE1.5020508@syphir.sytes.net> Date: Sun, 13 Nov 2005 02:56:33 -0800 From: "C.Y.M" <syphir@syphir.sytes.net> Organization: CooLNeT User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: VDR Mailing List <vdr@linuxtv.org> Subject: Re: [vdr] Remote plugin breakage with 2.6.15-rc1+ kernel References: <4377165F.3010105@syphir.sytes.net> In-Reply-To: <4377165F.3010105@syphir.sytes.net> X-Enigmail-Version: 0.92.1.0 Content-Type: multipart/mixed; boundary="------------040306080609030306080202" X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: syphir@syphir.sytes.net, VDR Mailing List <vdr@linuxtv.org> List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Sun, 13 Nov 2005 10:55:47 -0000 Status: O X-Status: X-Keywords: X-UID: 6058 |
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 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 >
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
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
--- 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++)