Peter Bieringer wrote:
> ...
>>>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
>
>
> My config (working with 1.3.37 and earlier, using since long time)
> KBD.Red 000000001B5B5B41 F1
> KBD.Green 000000001B5B5B42 F2
> KBD.Yellow 000000001B5B5B43 F3
> KBD.Blue 000000001B5B5B44 F4
>
> KBD.Power 0000001B5B32307E F10
> KBD.Menu 0000001B5B32347E F12
>
>
>
>>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.
>
>
> We should store it.
>
> Now I found the problem for the non working F1...F4, "5b" occurs twice
> in 1.3.37 remote.conf, so it should be accepted by 1.3.38, too:
>
> switch (key1) {
> case 0x31 ... 0x3F: // more-byte sequence
> case 0x5b: // more-byte sequence
> do {
> if ((key1 = ReadKey()) < 0)
> break; // Sequence ends here
>
> k <<= 8;
> k |= key1 & 0xFF;
>
> } while (key1 != 0x7E);
> break;
>
> Now it looks like it's all fixed again.
>
> Peter
I wonder if there's some standard anywhere that defines exactly
these byte sequences.
Any ideas, anybody?
Klaus
