Hi,
I want to use RC5 keycodes with different adresses in the remote.conf because my RC uses different ones for the normal (TV) keys and the keys for the VCR-control.
In learning mode only the adress of the first key is taken, the rest of the keys are useless then.
I think the adress is the last parameter in the following line remote-event3._Setup /proc/av7110_ir 00000000 31
But how to establish a second set with a different adress? What is the meaning of the other parameter?
Jörg.
Jörg Schneide wrote:
I want to use RC5 keycodes with different adresses in the remote.conf because my RC uses different ones for the normal (TV) keys and the keys for the VCR-control.
This is a limit of the DVB IR driver interface. The driver interface only transmits codes from a single RC5 address, or alternatively ignores the RC5 address completely and maps all codes together, probably mapping different keys to one code.
This leaves one solution: Patching the DVB driver. I've been using a patch for a long time that hard-codes up to three additional RC5 addresses to unused code numbers, eg. codes 0-63 from one programmable RC5 address as before, and 64-255 are hard-coded. Let me know if you're interested.
Cheers,
Udo
Udo Richter wrote:
Jörg Schneide wrote:
I want to use RC5 keycodes with different adresses in the remote.conf because my RC uses different ones for the normal (TV) keys and the keys for the VCR-control.
This is a limit of the DVB IR driver interface. The driver interface only transmits codes from a single RC5 address, or alternatively ignores the RC5 address completely and maps all codes together, probably mapping different keys to one code.
This leaves one solution: Patching the DVB driver. I've been using a patch for a long time that hard-codes up to three additional RC5 addresses to unused code numbers, eg. codes 0-63 from one programmable RC5 address as before, and 64-255 are hard-coded. Let me know if you're interested.
Another "solution" I'm using for a long time:
"Declare" the lower 2 address bits to be data bits, getting 8 bits data and 3 bits address. Then map the 256 RC codes to keycodes with av7110_loadkeys as usual.
Wolfgang
Cheers,
Udo
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Udo Richter wrote:
Jörg Schneide wrote:
I want to use RC5 keycodes with different adresses in the remote.conf because my RC uses different ones for the normal (TV) keys and the keys for the VCR-control.
This is a limit of the DVB IR driver interface. The driver interface only transmits codes from a single RC5 address, or alternatively ignores the RC5 address completely and maps all codes together, probably mapping different keys to one code.
Are you shure? I remember using a self made *.rc5 loaded with the following line DVB_REMOTE_KEYMAP="-a 31 -a 5 /mnt/hda5/mld030/etc/vdr/uni.rc5"
and i think it worked fine, but maybe in spite of the 2 a- parameters. I am not shure its too long ago.
Jörg.
Jörg Schneide wrote:
Are you shure? I remember using a self made *.rc5 loaded with the following line DVB_REMOTE_KEYMAP="-a 31 -a 5 /mnt/hda5/mld030/etc/vdr/uni.rc5" and i think it worked fine, but maybe in spite of the 2 a- parameters.
No. Unless I'm overlooking something important, the official driver still only accepts one address parameter and has only one translation table. It might be some patched driver though.
Cheers,
Udo
Wolfgang Fritz wrote:
Another "solution" I'm using for a long time:
"Declare" the lower 2 address bits to be data bits, getting 8 bits data and 3 bits address. Then map the 256 RC codes to keycodes with av7110_loadkeys as usual.
My patch is derived from that old solution, but just does it in a more selective way. Your solution fails in case that the two addresses don't differ in the lower two bits. And, the original patch did not mask out the address, so it did not work together with address selection. Since I have another RC5 device close by, I wanted address filtering too.
Cheers,
Udo
Udo Richter schrieb:
No. Unless I'm overlooking something important, the official driver still only accepts one address parameter and has only one translation table. It might be some patched driver though.
What I really don't understand is, why? When the debug mode is enabled the driver seems to know the adresses very well, so why they can't be used by the plugin?
btw.: I needed hours to find out how to enable the IR-debugging, it seems to be documented nowhere. A posting in this list stated it has to be enabled with debug=16 as a parameter for dvb_ttpci, that seems to be not correct or outdated. I found out -more by accident- that the parameter debug_ir=16 works.
Jörg.
Jörg Schneide wrote:
What I really don't understand is, why? When the debug mode is enabled the driver seems to know the adresses very well, so why they can't be used by the plugin?
Poor design. The driver knows the 5-bit address and the 6-bit key data and translates this into a key code event using a static table with 256 entries. (RCMM has 8 bit data) Everything, down to the /proc/av7110_ir format, uses this 256 entry table format, and there is no way to specify two tables for two devices.
If you want to take a look, this is in drivers\media\dvb\ttpci\av7110_ir.c. The code is easy to understand. Older drivers may have this file in a different location.
btw.: I needed hours to find out how to enable the IR-debugging, it seems to be documented nowhere. A posting in this list stated it has to be enabled with debug=16 as a parameter for dvb_ttpci, that seems to be not correct or outdated. I found out -more by accident- that the parameter debug_ir=16 works.
This seems to have changed several times on different driver versions, and documentation is minimal anyway.
Cheers,
Udo
Jörg Schneide wrote:
Udo Richter schrieb:
No. Unless I'm overlooking something important, the official driver still only accepts one address parameter and has only one translation table. It might be some patched driver though.
What I really don't understand is, why? When the debug mode is enabled the driver seems to know the adresses very well, so why they can't be used by the plugin?
There is no easy way to pass that information through the input driver to the plugin. The input driver requires key codes in the range 1..511.
btw.: I needed hours to find out how to enable the IR-debugging, it seems to be documented nowhere. A posting in this list stated it has to be enabled with debug=16 as a parameter for dvb_ttpci, that seems to be not correct or outdated.
debug=16 is correct for all recent dvb-kernel drivers.
With kernel 2.6.x you can simply type echo 16 > /sys/module/dvb_ttpci/parameters/debug
I found out -more by accident- that the parameter debug_ir=16 works.
Wrong, this never worked. Older drivers used av7110_ir_debug=1.
Oliver
Hello Oliver,
at first: Thank you for your plugin.
Oliver Endriss wrote:
debug=16 is correct for all recent dvb-kernel drivers.
I don't know the exact version, maybe the driver is not so recent. The only version strings I found in the log: Oct 16 13:58:12 (none) user.warn kernel: saa7146_vv: saa7146 (0): registered device video0 [v4l2] ... Oct 16 13:58:13 (none) user.info kernel: bttv: driver version 0.9.15 loaded
The file dvb-ttpci.ko (comes with a precompiled addon in *.tgz) has the date 06.10.2004, so I think its rather old.
With kernel 2.6.x you can simply type echo 16 > /sys/module/dvb_ttpci/parameters/debug
Oct 16 13:58:12 (none) user.warn kernel: Linux version 2.6.8-24-default (geeko@buildhost) (gcc version 3.3.4 (pre 3.3.5 20040809)) #1 Wed Oct 6 09:16:23 UTC 2004
So it should work, but it doesn't.
I found out -more by accident- that the parameter debug_ir=16 works.
Wrong, this never worked. Older drivers used av7110_ir_debug=1.
The older driver worked with av7110_ir_debug=1, the driver that comes with the mini distri I use did not. It also works not with debug=16, it works exactly with debug_ir=16 as parameter and with echo 16 > /sys/module/dvb_ttpci/debug_ir The fact that /sys/module/dvb_ttpci/debug_ir exists brought me to the idea to try the above line and suddenly it worked. Believe me. /sys/module/dvb_ttpci/debug also exists but I can write what I want to it there seems to be no effect. Maybe there are some patches applied to the driver, but I don't believe they are related to the IR remote stuff. As far as I know from the forum of the distribution I use, I am the only one who has problems with the IR-interface (or better: with my remotes), and I never asked the maintainer to apply a patch.
But when you know that debug_ir never worked, you probably know where debug=16 is documented, do you have a link? And what I would like to know abaout this line in the remote.conf: remote-event0._Setup /proc/av7110_ir 00000000 18 I think the last parameter is the RC5 adress, but what does the one before (besides the one bit for inversion)?
Jörg.
Jörg Schneide wrote:
Oliver Endriss wrote:
debug=16 is correct for all recent dvb-kernel drivers.
... The file dvb-ttpci.ko (comes with a precompiled addon in *.tgz) has the date 06.10.2004, so I think its rather old.
With kernel 2.6.x you can simply type echo 16 > /sys/module/dvb_ttpci/parameters/debug
So it should work, but it doesn't.
I found out -more by accident- that the parameter debug_ir=16 works.
Wrong, this never worked. Older drivers used av7110_ir_debug=1.
The older driver worked with av7110_ir_debug=1, the driver that comes with the mini distri I use did not. It also works not with debug=16, it works exactly with debug_ir=16 as parameter and with echo 16 > /sys/module/dvb_ttpci/debug_ir The fact that /sys/module/dvb_ttpci/debug_ir exists brought me to the idea to try the above line and suddenly it worked. Believe me.
Ok, I checked the history of av7110_ir.c in CVS. You are right. 'debug_ir' was introduced on Jul 29th 2004 and dropped again on Sep 20 2004. I must have missed that. ;-)
/sys/module/dvb_ttpci/debug also exists but I can write what I want to it there seems to be no effect. Maybe there are some patches applied to the driver, but I don't believe they are related to the IR remote stuff. As far as I know from the forum of the distribution I use, I am the only one who has problems with the IR-interface (or better: with my remotes), and I never asked the maintainer to apply a patch.
But when you know that debug_ir never worked, you probably know where debug=16 is documented, do you have a link?
Well, from a recent av7110_ir.c: | /* enable ir debugging by or'ing debug with 16 */
Afaik it is not documented anywhere else. There are some notes about ir debugging in the dvb-apps package, but it is still referring to the old DVB driver (av7110_ir_debug).
And what I would like to know abaout this line in the remote.conf: remote-event0._Setup /proc/av7110_ir 00000000 18 I think the last parameter is the RC5 adress, but what does the one before (besides the one bit for inversion)?
Basically, it's the configuration word which is used to configure the driver: - bit 0: RC5 or RCMM remote control - bit 15: inverted or not inverted signal
The last parameter is the RC5 address.
Oliver
Oliver Endriss wrote:
When the debug mode is enabled the driver seems to know the adresses very well, so why they can't be used by the plugin?
There is no easy way to pass that information through the input driver to the plugin. The input driver requires key codes in the range 1..511.
It wouldn't be that hard to implement dynamic key_map tables for different addresses. Just the total number of used key codes is limited to 511. And if 511 is not enough, why not use shift codes that announce switching to a different address?
Basically, it would be possible, but its simply not a priority.
Cheers,
Udo
Oliver Endriss wrote:
Ok, I checked the history of av7110_ir.c in CVS. You are right. 'debug_ir' was introduced on Jul 29th 2004 and dropped again on Sep 20 2004. I must have missed that. ;-)
Thanks for the info, now I can extend the little remote-howto I wrote in the forum of the used vdr-distribution, becuse the debug_ir=16 will be outdated in one of the next releases. It is planned to change the parameter in the near future? ;-)
Well, from a recent av7110_ir.c: | /* enable ir debugging by or'ing debug with 16 */
Afaik it is not documented anywhere else. There are some notes about ir debugging in the dvb-apps package, but it is still referring to the old DVB driver (av7110_ir_debug).
In my desparate search I downloaded v4l-kernel-20051011.tar.gz and video4linux-20051011.tar.gz from http://www.linuxtv.org/downloads/video4linux/ and searched it, but obviously this where not the right files. The http://www.linuxtv.org/downloads/dvb directory seems to be recusive. What are the right files and where to get them?
Jörg.
Jörg Schneide wrote:
Oliver Endriss wrote:
Ok, I checked the history of av7110_ir.c in CVS. You are right. 'debug_ir' was introduced on Jul 29th 2004 and dropped again on Sep 20 2004. I must have missed that. ;-)
Thanks for the info, now I can extend the little remote-howto I wrote in the forum of the used vdr-distribution, becuse the debug_ir=16 will be outdated in one of the next releases. It is planned to change the parameter in the near future? ;-)
No.
Well, from a recent av7110_ir.c: | /* enable ir debugging by or'ing debug with 16 */
Afaik it is not documented anywhere else. There are some notes about ir debugging in the dvb-apps package, but it is still referring to the old DVB driver (av7110_ir_debug).
In my desparate search I downloaded v4l-kernel-20051011.tar.gz and video4linux-20051011.tar.gz from http://www.linuxtv.org/downloads/video4linux/ and searched it, but obviously this where not the right files. The http://www.linuxtv.org/downloads/dvb directory seems to be recusive. What are the right files and where to get them?
All dvb driver packages on the download page are obsolete.
With kernel 2.6 you should use the drivers shipped with the kernel unless you have very new hardware and you have to use CVS drivers.
The latest greatest CVS dvb-kernel drivers can be found here: http://linuxtv.org/cgi-bin/viewcvs.cgi/dvb-kernel.tar.gz?view=tar For these drivers you need kernel 2.6.13 or later.
Oliver
-
Jörg Schneide -
Oliver Endriss -
Udo Richter -
Wolfgang Fritz