Joerg Pulz wrote: > 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. Why didn't you just swap the cards? > 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. No, afaik the driver was not modified in this area. Probably the cards are initialized in a diffenent order. > now i'm thinking about a clean solution and a few things come to my mind. A clean solution would be a complete rewrite of the ir stuff: - a generic dvb remote control module - one event device for each card - keymap handling for each device using evdev ioctls - repeat rate handling etc. using evdev ioctls - ... It's on my todo list but I don't know when I'll find the time... > 1. is there a possibility to check if an IR receiver is connected to a > card... No, that's not possible. :( > 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? There is no big difference whether you use the first device or the last one. It would break the driver for other users. > 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? See above. Oliver -- -------------------------------------------------------- VDR Remote Plugin available at http://www.escape-edv.de/endriss/vdr/ --------------------------------------------------------
