Oliver Endriss wrote:
...Klaus Schmidinger wrote:
Oliver Endriss wrote:
Klaus Schmidinger wrote:
Please put a line like
fprintf(stderr, "%04X\n", Key);
at the beginning of cDisplayChannel::ProcessKey() and check whether, when you press the Up key, hold it down for a while and finally release it, you get
0000 8000 8000 8000 8000 8000 8000 8000 8000 8000 8000 8000 8000 4000
The important thing is that there is not a single 0000 between all the 8000. If you do get an interruption there, then you should trace that back to where it comes from.
Ok, here is the log from holding down the 'up' key.
/dev/input/event2: press 0000000100010021 <-- debug output remote plugin: 'up' key pressed 50 0000 <-- (cDisplayChannel::ProcessKey 1st value = lastTime.Elapsed(), 2nd value = Key 307 0032 323 0032 339 0032 355 0032 371 0032 387 0032 403 0032 /dev/input/event2: repeat 0000000100010021 <-- key repeat kicks-in 404 8000 107 0032 /dev/input/event2: repeat 0000000100010021 92 8000 /dev/input/event2: repeat 0000000100010021 60 8000 75 0032 /dev/input/event2: repeat 0000000100010021 56 8000 /dev/input/event2: repeat 0000000100010021 68 8000 75 0032 /dev/input/event2: repeat 0000000100010021 56 8000 75 0032 /dev/input/event2: repeat 0000000100010021 64 8000 /dev/input/event2: repeat 0000000100010021 60 8000 79 0032 /dev/input/event2: repeat 0000000100010021 64 8000 /dev/input/event2: repeat 0000000100010021 66 8000 73 0032 /dev/input/event2: repeat 0000000100010021 56 8000 83 0032 /dev/input/event2: repeat 0000000100010021 60 8000 /dev/input/event2: repeat 0000000100010021 60 8000 71 0032 /dev/input/event2: repeat 0000000100010021 60 8000 75 0032 /dev/input/event2: repeat 0000000100010021 60 8000 /dev/input/event2: repeat 0000000100010021 71 8000 76 0032 /dev/input/event2: repeat 0000000100010021 56 8000 76 0032 /dev/input/event2: repeat 0000000100010021 55 8000 /dev/input/event2: repeat 0000000100010021 60 8000 71 0032 /dev/input/event2: repeat 0000000100010021 56 8000 79 0032 /dev/input/event2: repeat 0000000100010021 56 8000 79 0032 71 0032 87 0032 103 0032 119 0032 135 0032 152 0032 /dev/input/event2: release 0000000100010021 <-- key released 155 4000 540 0032 556 0032 572 0032 588 0032 604 0032 621 0032 636 0032 ... 4940 0032 4956 0032 4972 0032 4989 0032 5004 0032
The 0032 (kNone) keys look suspicious to me. The are _not_ created by the remote plugin.
Oliver
Well, then they must be created by something else. Here's the same output on my system:
56 0000 <--- Up key pressed 605 8000 <--- right the next Key is kUp|k_Repeat, no intermittent kNone 74 8000 73 8000 76 8000 72 8000 72 8000 73 8000 71 8000 72 8000 72 8000 72 8000 71 8000 67 8000 68 8000 132 8000 72 8000 52 8000 44 8000 lots of kUp|k_Repeat, without any intermittent kNone 52 8000 52 8000 51 8000 44 8000 28 8000 52 8000 72 8000 80 8000 73 8000 59 8000 52 8000 32 8000 52 8000 44 8000 28 8000 32 8000 71 8000 76 8000 71 8000 72 8000 51 8000 52 4000 <--- kUp|k_Release 1034 0032 <--- these kNone are normal 1058 0032 1082 0032 1106 0032 1130 0032 1154 0032 1178 0032 1202 0032 1226 0032 1250 0032
There must be something on your system that creates these intermittent kNone key events, but I don't see where that would be happening in plain vanilla VDR.
It happens with vanilla vdr plus remote plugin. No patches.
From the sequence of kNone right after you pressed the Up key it looks like something is inserting kNone events every 16 ms.
On my system vdr is creating kNone events every 16ms as long as the channel info is displayed. On your system this interval seems to be 24ms.
My system uses a preemtible kernel. HZ is set to 250. Non-NPTL system.
Could you please tell me where these 'normal' events come from? I'd like to change the interval and see whether it affects the problem.
Oliver
I believe I found what's causing this. In cInterface::GetKey() the line
return cRemote::Get(Wait ? 1000 : 10);
tries to fetch the next keypress from the remote control, and waits at most 10ms in this case. If the remote control doesn't provide another keypress within this timeout, cRemote::Get() returns kNone.
I was able to reproduce this here while debugging the case where the screen gets dark for a moment if pressing "Down" while on channel 1. Setting the timeout to 100ms, as in
return cRemote::Get(Wait ? 1000 : 100);
fixed it for me.
Can you confim this?
Klaus