[linux-dvb] IR and dvb-kernel trouble

Joerg Pulz Joerg.Pulz at frm2.tum.de
Tue Mar 29 17:13:46 CEST 2005

Hash: SHA1


i've used the DVB CVS driver together with kernel-2.4.x for a very long 
time now. My vdr system consists of two FF dvb cards, one Hauppauge 
Nexus-S rev. 2.2 (modified to 4MB) and one Hauppauge DVB-S rev. 1.3. i've 
an 3.5" CI connected to the rev. 2.2 card which is the first card 
recognized by the driver. the CI also contains the IR receiver.
As long as i used this setup, everything was working very well.

Last weekend i switched over to kernel- and dvb-kernel CVS and 
spent hours to get the IR stuff up and running.
so far, the compilation and loading of the dvb-kernel driver was 
the rev. 2.2 card is still the first one the driver detects.
an IR event device was registered/created and the proc entry for the IR 
device is also there. but evtest or loading the driver with debug=xx gives 
nothing about any key i pressed on the RC.
i decided to take out the rev. 1.3 card as there is no IR receiver 
connected to J2, and the IR stuff was working again.
After that, i compared the IR parts of the DVB CVS driver and dvb-kernel 
CVS driver, but found no real difference between them. the only thing i 
stumbled over was the:
 	Hack! we save the last av7110 ptr....
comment for
but this is in both versions of the driver.

i removed the following lines from this function:
         if (!av7110)
                 av7110 = last;
                 last = av7110;
and compiled the driver again. after plugging in the rev. 1.3 card again 
and loading the driver, the IR was attached to the rev. 2.2 device like it 
was with kernel-2.4.xx and DVB CVS driver.

i think that, what i've done is really an ugly hack but the only way to 
get a quick fix.
is there a change to the supported capabilities for rev. 1.3 cards between 
DVB CVS and dvb-kernel CVS that i expect differnt behavior between both of 
them, 'cause the IR code looks very similar to me.

now i'm thinking about a clean solution and a few things come to my mind.

1. is there a possibility to check if an IR receiver is connected to a 
card and only register an event device and proc entry for this card 
instead of reregistering the same event dev and the same proc entry for 
every IR'able card so that the last card wins the fight, IR receiver 
connected or not, which is the current behavior?
2. if it is not possible to check for the existance of an IR receiver, why 
not attach the event dev and proc entry to the first card that is found 
and skipping over all other IR'able card which are probably present?
3. why not register an event dev and proc entry for every IR capable card, 
so one can easily choose which card to use for IR transactions?

solutions number 2 still is an ugly hack and should not be considered.
the cleanest solution in my opinion is a combination of 1 and 3, but 1 
depends on the possibility to check for the existance of an IR receiver. I 
don't know if it is possible to implement this.
solution 3 is hardware independent but is a little bit programming work.

unfortunately, i'm not so familiar with the dvb driver and linux 
kernel internals to provide a working implementation but i'm willing to 
help wherever i can.

any comments would be welcome

- -- 
The beginning is the most important part of the work.
Version: GnuPG v1.4.0 (FreeBSD)


More information about the linux-dvb mailing list