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