Peter Bieringer wrote:

Klaus Schmidinger wrote:

...

...

are there any changes if lirc and terminal are used in common?

While menu key works on remote control, it no longer works on keyboard (I use F12 for that).

1.3.37 works fine.

Any hints available?

Maybe this has to do with the changes in cKbdRemote (remote.c) for reading key sequences.

Please try assigning the Menu function to a different key, like 'm', for instance, to test whether it works at all.

Yes, this words.

...

If this works then you might need to debug into cKbdRemote::ReadKeySequence() to see what's happening.

I can't debug this myself, because my keyboard doesn't have an F12 key.

Looks like all function keys are no longer working, I have assigned the color keys to F1 to F4, non of them working in 1.3.38.

Well, at least F1..F4 do work for me.

Please add some debug printf's to cKbdRemote::ReadKeySequence() and try to find out what goes wrong.

Klaus

Peter Bieringer wrote:

Klaus Schmidinger wrote:

...

...

Looks like all function keys are no longer working, I have assigned the color keys to F1 to F4, non of them working in 1.3.38.

Well, at least F1..F4 do work for me.

Please add some debug printf's to cKbdRemote::ReadKeySequence() and try to find out what goes wrong.

It's caused by the 64 bit shift limit, pressing F12 causes 5 ReadKey calls, resulting in 80 bit, but only lower 64 bit are returned:

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

I've added

r++; fprintf(stderr, "cKbdRemote::ReadKeySequence: r=%d k=%lx key1=%x\n", r, k, key1);

after each "k |=

and

if (k != 0) { fprintf(stderr, "cKbdRemote::ReadKeySequence: r=%d k=%lx\n", r, k); }

before "return k"

BTW: it' strange that key1 is set to 0 after k |=...

Peter

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

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; } }

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

Will try to debug this later, have to leave now.

Peter

Klaus Schmidinger wrote:

...

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').

Oh, this is the reason...I'm using "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.

Also it's bad because compatibility is broken to lower versions.

...

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