[vdr] VDR 1.3.38: menu key no longer works

[Klaus Schmidinger]

Peter Bieringer wrote:
> Klaus Schmidinger wrote:
> 
>>Are you sure about that?
>>64 bit are 8 byte, and 5 ReadKey() calls should only result in
>>5 * 8 = 40 bit.
>>
>>Klaus
>>
>>
>>>cKbdRemote::ReadKeySequence: r=1 k=1b key1=0
>>>cKbdRemote::ReadKeySequence: r=2 k=1b5b key1=0
>>>cKbdRemote::ReadKeySequence: r=3 k=1b5b32 key1=0
>>>cKbdRemote::ReadKeySequence: r=4 k=1b5b3232 key1=0
>>>cKbdRemote::ReadKeySequence: r=5 k=5b323234 key1=1b
>>>cKbdRemote::ReadKeySequence: r=5 k=5b323234
> 
> 
> Tracked more down
> 
> remote.conf contains:
> 
> KBD.Menu       0000001B5B32347E
> 
> which works in 1.3.37
> 
> In 1.3.38, trailing 7E is missing because of while loop.
> 
> After fixing this temporary I still get "32" twice here:
> 
> cKbdRemote::ReadKeySequence: r=1 key1=1b
> cKbdRemote::ReadKeySequence: r=1 k=000000000000001b
> cKbdRemote::ReadKeySequence: r=2 key1=5b
> cKbdRemote::ReadKeySequence: r=2 k=0000000000001b5b
> cKbdRemote::ReadKeySequence: r=3 key1=32
> cKbdRemote::ReadKeySequence: r=3 k=00000000001b5b32
> cKbdRemote::ReadKeySequence: r=4 key1=32
> cKbdRemote::ReadKeySequence: r=4 k=000000001b5b3232
> cKbdRemote::ReadKeySequence: r=5 key1=34
> cKbdRemote::ReadKeySequence: r=5 k=000000005b323234
> cKbdRemote::ReadKeySequence: r=5 k=000000003232347e

Could there be someting wrong with your printf statement?
Looks like the upper 32 bit are cut off. You need to use
an format like "%016LX" (capital 'L').

> There is a logical bug in the code, the key after "5b" will be added
> twice, following will proper work:
> 
>                       switch (key1) {
>                         case 0x31 ... 0x3F: // more-byte sequence
>                              do {
>                                    if ((key1 = ReadKey()) < 0)
>                                       break; // Sequence ends here
>                                    k <<= 8;
>                                    k |= key1 & 0xFF;
>                              } while (key1 != 0x7E);
>                              break;
>                         }
>                       }

It would have worked just as well, since it always returns
the same code for a given key, but of course you're absolutely
right, that byte should be stored only once.

> But there is still a strangeness, F1 to F5 now report single key code,
> while from F6, 5 key code is reported.

Here I have

KBD.Red        00000000001B4F50
KBD.Green      00000000001B4F51
KBD.Yellow     00000000001B4F52
KBD.Blue       00000000001B4F53

I guess we also need to adjust KbdMap[] in remote.c to account
for the 0x7E that's no longer stored.

Or should we rather actually store the 0x7E as part of the key code?
After all, it _is_ part of it...
I tend to do the latter.

Klaus