En/na Joachim Wilke ha escrit:

2006/1/22, Wolfgang Fritz wolfgang.fritz@gmx.net:

...

I have as similar problem. On some channels, the repeat toggles between the next and the original channel. Starting from other channels, it is working better, but at some position, it switches back to the original channel and the sequence restarts.

Me too, but with lirc-0.7.0.

Here with lirc (0.6.6) it jumps at most two channels. When I release the key it goes back one channel (i.e. the net effect is the same as pressing the key just once). irw shows that lirc is receiving all the time (the sequence is increasing).

Bye

Udo Richter wrote:

...

...

• Switching channels with the Up/Down or Channel+/Channel- keys now

works a lot faster when the repeat function kicks in, by not actually switching the channel every time, but rather only displaying the channel info and doing the final switch when the key is released.

Nice idea, but not working for me.

If I hold down ChUp on my remote, VDR just goes one channel up. Then, the repeat kicks in and the channel number counts up rapidly, but resets to the current channel after 10-40 channels (1-2 seconds), then starts counting up again. No channel switches after the first one in log files. After releasing ChUp, the final channel switch happens, to the channel that was shown at that time.

With keyboard, the ChUp is waaay slower, but works. From the logs, each channel is switched separately, just as without repeat.

Remote support is based on remote-0.3.3, keyboard support is VDR-builtin. No other plugins loaded.

Well, I could only test this with my own RCU stuff, but I just assumed that it should work just as well with LIRC.

It can't work with the keyboard, because there is no "repeat" functionality in cKbdRemote. Maybe somebody could find a way to implement that ;-)

So basically I'm afraid I can't help here. The functionality works great with my RCU, so I would assume that there are some glitches in cLircRemote or the remote plugin you're using. My guess would be that there is no uninterrupted stream of "repeat" keypresses. As soon as a non-repeat keypress is received, a channel switch will take place.

Hi,

i also use the RCU, but i have the same effect as Udo....i use a old Dbox1 remote control.

Andreas

Klaus Schmidinger wrote:

...

...

My guess would be that there is no uninterrupted stream of "repeat" keypresses. As soon as a non-repeat keypress is received, a channel switch will take place.

The channel doesn't change. Just the displayed channel number counts up, then jumps back down.

Please put a line like

fprintf(stderr, "%04X\n", Key);

at the beginning of cDisplayChannel::ProcessKey()

I've added some more lines. Looks like the "makes sure a channel switch through the SVDRP CHAN command is displayed" part is causing the reset to the currently shown channel, whenever there's a kNone in the key sequence. This happens roughly once a second.

Here's a log, starting on channel 5:

cDisplayChannel::ProcessKey(None) cDisplayChannel::ProcessKey(None) cDisplayChannel::ProcessKey(None) cDisplayChannel::ProcessKey(None) cDisplayChannel::ProcessKey(Channel+) case kUp/Dn: channel=6 channel=NewChannel: Channel=6 cDisplayChannel::ProcessKey(None) cDisplayChannel::ProcessKey(None) cDisplayChannel::ProcessKey(None) cDisplayChannel::ProcessKey(None) cDisplayChannel::ProcessKey(None) cDisplayChannel::ProcessKey(Channel+|Repeat) case kUp/Dn: channel=7 cDisplayChannel::ProcessKey(None) timeout, kNone: Channel=6 cDisplayChannel::ProcessKey(Channel+|Repeat) case kUp/Dn: channel=7 cDisplayChannel::ProcessKey(Channel+|Repeat) case kUp/Dn: channel=8 cDisplayChannel::ProcessKey(Channel+|Repeat) case kUp/Dn: channel=9 cDisplayChannel::ProcessKey(Channel+|Repeat) case kUp/Dn: channel=10 cDisplayChannel::ProcessKey(Channel+|Repeat) case kUp/Dn: channel=11 cDisplayChannel::ProcessKey(None) timeout, kNone: Channel=6 cDisplayChannel::ProcessKey(Channel+|Repeat) case kUp/Dn: channel=7 cDisplayChannel::ProcessKey(Channel+|Repeat) case kUp/Dn: channel=8 cDisplayChannel::ProcessKey(Channel+|Repeat) case kUp/Dn: channel=9 [...] cDisplayChannel::ProcessKey(Channel+|Repeat) case kUp/Dn: channel=8 cDisplayChannel::ProcessKey(None) timeout, kNone: Channel=6 cDisplayChannel::ProcessKey(Channel+|Release) channel=NewChannel: Channel=6 cDisplayChannel::ProcessKey(None) cDisplayChannel::ProcessKey(None) cDisplayChannel::ProcessKey(None) cDisplayChannel::ProcessKey(None) cDisplayChannel::ProcessKey(None)

Channel=6 is always set within the last if block of ProcessKey(), the first time from the final channel=NewChannel, because the repeat did not yet kick in. Later, the channel is set from cDevice::CurrentChannel() on each kNone call. I have ChannelInfoTime=5, TimeoutRequChInfo=1.

Cheers,

Udo

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.

Klaus, could you please have a look at this log?

Oliver

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.

From the sequence of kNone right after you pressed the Up key it looks like something is inserting kNone events every 16 ms.

Klaus

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

En/na Klaus Schmidinger ha escrit:

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?

Here with lirc 100 isn't enough. I'm trying with 200 and it solves the problem of getting kNone in between key repeats *but* I still get 3 kNone between the last repeat and the kRelease, so the net effect is that the channel won't change. Still investigating...

Bye

En/na Luca Olivetti ha escrit:

En/na Luca Olivetti ha escrit:

...

En/na Klaus Schmidinger ha escrit:

...

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?

Here with lirc 100 isn't enough. I'm trying with 200 and it solves the problem of getting kNone in between key repeats *but* I still get 3 kNone between the last repeat and the kRelease, so the net effect is that the channel won't change. Still investigating...

Ok, I see in lirc.c that the REPEATDELAY is 350 (used not only to start the repeat but also to detect that there's no key pressed to generate a release), changing it to 150 and using a delay of 200 in interface.c seems to solve it (but still I'm not sure it is completely reliable).

It's not reliable. Maybe, instead of just raising the delay in interface (which kinda defeats the purpose of not waiting) cDisplayChannel should remember that a key repeat is in effect and just ignore kNone until a key release or a timeout.

Bye

Luca Olivetti wrote:

En/na Luca Olivetti ha escrit:

...

...

Ok, I see in lirc.c that the REPEATDELAY is 350 (used not only to start the repeat but also to detect that there's no key pressed to generate a release), changing it to 150 and using a delay of 200 in interface.c seems to solve it (but still I'm not sure it is completely reliable).

It's not reliable. Maybe, instead of just raising the delay in interface (which kinda defeats the purpose of not waiting) cDisplayChannel should remember that a key repeat is in effect and just ignore kNone until a key release or a timeout.

I just tried to do that with a quick and dirty hack (in order to avoid recompiling everything and plugins, instead of adding a boolean member I "overloaded" number) and it seems to work fine (with the original timeouts in lirc and interface).

Based on your suggestion I have implemented a repeat timeout in cRemote, so it should work with any kind of remote control, and for all kinds of menus.

Please try the attached patch (against VD 1.3.40) and run it with the original interface.c.

Originally I didn't want to release a new version of VDR today, but since this repeat thing is rather problematic, and there is also a serious problem with the version of EPG events after a restart, I'm thinking of making a new release later today. So if somebody could confirm that this patch actually works, that would be nice.

Klaus

Joachim Wilke wrote:

2006/1/29, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de:

...

Originally I didn't want to release a new version of VDR today, but since this repeat thing is rather problematic, and there is also a serious problem with the version of EPG events after a restart, I'm thinking of making a new release later today. So if somebody could confirm that this patch actually works, that would be nice.

I tried it with success. When pressing the up-key on channel 1, VDR switches to channel 2, keeps showing this program while counting up the channel numbers. When releasing the up-key, VDR switches to the final channel.

Ok, that's how it's supposed to work.

The first channel switch can't be suppressed, because at that time it's not yet known that there will be repeated key presses.

Klaus

Luca Olivetti wrote:

En/na Klaus Schmidinger ha escrit:

...

Originally I didn't want to release a new version of VDR today, but since this repeat thing is rather problematic, and there is also a serious problem with the version of EPG events after a restart, I'm thinking of making a new release later today. So if somebody could confirm that this patch actually works, that would be nice.

I'm afraid it's not reliable enough with the default REPEATDELAY of 350 in lirc.c (sometimes cDIsplayChannels still gets a kNone before the k_Release). Changing REPEATDELAY to 250 seems to work better, but I don't think is the definitive solution.

REPEATDELAY is the time from the first keypress until the repeat function actually kicks in. I'm afraid I don't see how this would have an effect here.

Ok, if the events from LIRC are actually more than 250ms apart, then skipping one could result in the repeatDelay timeout to expire. So maybe you should rather try increasing REPEATTIMEOUT in remote.c. I'd say a value of 1000 should really be enough for any remote control (after all, a repeat function is supposed to be _fast_ ;-).

Klaus

En/na Luca Olivetti ha escrit:

En/na Klaus Schmidinger ha escrit:

...

REPEATDELAY is the time from the first keypress until the repeat function actually kicks in. I'm afraid I don't see how this would have an effect here.

It's also used as a timeout to detect the release: else { printf("%d\n",LastTime.Elapsed()); if (FirstTime.Elapsed() < REPEATDELAY) continue; // repeat function kicks in after a short delay repeat = true; timeout = REPEATDELAY; <<<<<<<

note that I added the printf here to see the time between repeats (that's around 110ms with my remote and lirc version)

Bye

En/na Klaus Schmidinger ha escrit: ded the printf here to see the time between repeats

...

(that's around 110ms with my remote and lirc version)

So what about setting REPEATTIMEOUT in remote.c to 1000? Does that help?

I think that REPEATTIMEOUT should be at least double than REPEATDELAY (in lirc, I don't know other remotes). So I tried with the original REPEATDELAY 350 and REPEATTIMEOUT 700 as well as REPEATDELAY 250 and REPEATTIMEOUT 500. Both combinations work, so I'd say that a REPEATTIMEOUT of 1000 should definitely work (unless there's some remote that takes more than 500 ms to detect a release after a repeat).

Bye