[vdr] Re: Remote Plugin/DVB-Driver problem

[Oliver Endriss <o.endriss@gmx.de>]

Joerg Schneide wrote:
> >Oliver Endriss wrote:
> >
> > As I wrote before, the old driver ignores the 3 upper address bits.
> > There are 5 address bits = 32 possible values for the -a option
> > (0..31). If your codes were in the range 0x40..0x7f, the correct
> > values for -a might be 1,5,9,13,17,21,25 or 29.
>
> Maybe I simply dont understand "address" in this context, but if
> I pass any wrong address with the '-a [adress]' parameter
> no keycode should be accepted at all.
> (except those cases where the upper address bits are ignored)
> So when I try adress 0-3 there should be a minimum of 3 values
> where no codes are accepted.

Correct.

> As I wrote there is no change at all, wich means all codes are
> accepted (0x00-0x3f and 0x40-0x7f) in every case.

Hmm, are you using an outdated av7110_loadkeys? 
Are you sure that the av7110_loadkeys tool of your driver package 
is the one originally delivered with the driver? 
An old av7110_loadkeys tool would simply ignore the -a parameter
(and explain the behaviour you encountered).

Try av7110_loadkeys without parameters, it will display all
accepted parameters. You should see
  usage: av7110_loadkeys [-i|--invert] [-a|--address <num>] keymap_filename.(rc5|rcmm)
If [-a|--address <num>] is missing you have a wrong av7110_loadkeys.

> [playing around with the -a parameter]

Try to run av7110_loadkeys manually. You can do this while vdr is
running. Simply type
  /path_to_av7110_loadkeys/av7110_loadkeys -a 1 /video/haupneu1.rc5 > /proc/av7110_ir
to change the keymap parameters on the fly.

> > You have to fix your keymap, too:
> > All codes must be in the range 0..0x3f:
> > - For old codes 0x40..0x7f, subtract 0x40.
> > - For old codes 0x80..0xbf, subtract 0x80.
> > - For old codes 0xc0..0xff, subtract 0xc0.
>
> It is in this range, otherwise i get the "... emit key unknown key
> 0xXX" message, no RC is possible at all.

Ok, this indicates that the driver is a recent one.

> So I think the parameter is simply not parsed, or stripped
> before the commandline is built.

See above. Maybe your distribution delivers an old av7110_loadkeys.

> Or are there "special" addresses in RC5 wich tells the receiving
> device to accept the codes in any case?

No, the driver decides which addresses to accept or not.

> If so, is this implemented in the driver?
> Maybe my RC is programmed with this address, it is
> not easy to figure this out in the programming tools because
> they work with strange codes wich are not directly related to
> what codes are really send.

The driver works as follows:
If no address is specified by av7110_loadkeys, accept all addresses.
Otherwise accept only the specified address (0..31). 

An outdated av7110_loadkeys would never pass the address to the driver,
so all addresses would be accepted.

> > See above. If nothing helps, enable debugging in the driver (add
> > option 'av7110_ir_debug=1' when loading dvb-ttpci.o) and check the
> > debug output: 'addr' is the address value sent by the transmitter.
>
> Its a bit tricky to change this because this is not a complete
> distribution, except of some basic config files all the stuff is
> packed in images or archives.

The problem with binary distributions is that you never know
which version at you are using. :-(

> I would try it if it helps to find out why the parameter is ignored,
> but I doubt this is the case (especially when '-a ' is lost
> somewhere before the av71110_loadkeys... line).

I don't know how the driver modules are loaded in your package.
There should be some config file which controls this and could be 
modified to pass the parameter av7110_ir_debug=1 to dvb-ttpci.o.

Oliver


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.