-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
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-2.6.11.5 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
successful.
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
av7110_setup_irc_config()
but this is in both versions of the driver.
i removed the following lines from this function:
if (!av7110)
av7110 = last;
else
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
regards
Joerg
- --
The beginning is the most important part of the work.
-Plato
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFCSXCsSPOsGF+KA+MRAvt+AJ9OLjp+zllAxXtI6nu1nJL4B4q/8wCeKWjM
q7PVF9lXX+Pw4rKZ7Q6H0MU=
=E14g
-----END PGP SIGNATURE-----
