VDR developer version 1.3.41 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.41.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.40-41.diff
The changes since version 1.3.40:
- EPG events from epg.data or SVDRP's PUTE command now have their Title set to "No Title" if none was set. - Fixed checking toFile in cCuttingThread::Action() (found in a larger patch from Artur Skawina). - Fixed a crash when pressing '0' in the "Schedule" menu on a channel that doesn't have any EPG data (reported ny Alexander Hans). - Updated the Danish OSD texts (thanks to Mogens Elneff). - Fixed a missing ',' in the Greek OSD texts (thanks to Arthur Konovalov). - Updated the Estonian OSD texts (thanks to Arthur Konovalov). - Fixed handling the tfRecording flag when reading timers (bug reported by Andreas Mair). - Now checking whether the channel exists before setting the PMT filter in cPatFilter::Process() (thanks to Thomas Bergwinkl). - Now trying to reestablish the connection to the LIRC daemon in case it breaks (thanks to Ville Skyttä). - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Fixed channel switching with the Down (Up) key in case the current channel is already the first (last) in the list (reported by Frank Krömmelbein). - Removed the "buffer reserve" in Transfer Mode - it's no longer necessary with recent driver/firmware versions. - The epg.data file is now written when VDR exits (suggested by Daniel Karsubka). - Fixed cTimers::GetNextActiveTimer() so that it won't return an expired timer (reported by Rolf Ahrenberg). - Changed DVBS_TUNE_TIMEOUT and DVBC_TUNE_TIMEOUT to 9000ms to avoid problems with channels that have low symbol rates (reported by Suur Karu). - Fixed displaying the current audio track in the channel display. - When reading epg.data (or data from PUTE), the version number of events with table IDs smaller than 0x50 is now ignored because otherwise the current running status would not be set after a restart of VDR. - Implemented a timeout for remote controls that don't deliver "repeat" keypresses very fast (based on a suggestion by Luca Olivetti; problem with the new handling of k_Repeat keypresses in channel switching reported by Udo Richter). - When looking for the present or following EPG event, the running status is now always taken into account. - Now initializing the channels' schedule pointers when reading the epg.data file, so that the first WhatsOn menu will come up faster. - If a shutdown is requested, but the shutdown script doesn't actually halt the system, it is now tried again after 5 minutes (suggested by Helmut Auer). - Separated the 'install' target into several individual targets; renamed the 'plugins-install' target to 'install-plugins' (thanks to Helmut Auer).
Have fun!
Klaus
En/na Klaus Schmidinger ha escrit:
- Implemented a timeout for remote controls that don't deliver "repeat"
keypresses very fast
Just nitpicking, but the actual problem was remotes that don't deliver a release event soon enough.
Bye
Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
- Implemented a timeout for remote controls that don't deliver "repeat"
keypresses very fast
Just nitpicking, but the actual problem was remotes that don't deliver a release event soon enough.
Well, maybe this is a general flaw of cLircRemote? Doesn't LIRC provide the information that the key has been released? That would make it unnecessary to wait for such a long time (REPEATDELAY) before signaling a "release".
Klaus
En/na Klaus Schmidinger ha escrit:
Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
- Implemented a timeout for remote controls that don't deliver "repeat"
keypresses very fast
Just nitpicking, but the actual problem was remotes that don't deliver a release event soon enough.
Well, maybe this is a general flaw of cLircRemote? Doesn't LIRC provide the information that the key has been released? That would make it unnecessary to wait for such a long time (REPEATDELAY) before signaling a "release".
I don't think it does (at least irw doesn't report anything on key release), but even if it did surely it'd have to use a timeout to detect that there's nothing more coming from the remote, so the problem would be the same (unless the remote itself sends something to signal a key release).
Bye
Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
- Implemented a timeout for remote controls that don't deliver "repeat"
keypresses very fast
Just nitpicking, but the actual problem was remotes that don't deliver a release event soon enough.
Well, maybe this is a general flaw of cLircRemote? Doesn't LIRC provide the information that the key has been released? That would make it unnecessary to wait for such a long time (REPEATDELAY) before signaling a "release".
I don't think it does (at least irw doesn't report anything on key release), but even if it did surely it'd have to use a timeout to detect that there's nothing more coming from the remote, so the problem would be the same (unless the remote itself sends something to signal a key release).
Well, if things work ok with version 1.3.41 I guess we're fine, anyway.
Klaus
On Sun, Jan 29, 2006 at 05:23:13PM +0100, Luca Olivetti wrote:
Well, maybe this is a general flaw of cLircRemote? Doesn't LIRC provide the information that the key has been released? That would make it unnecessary to wait for such a long time (REPEATDELAY) before signaling a "release".
I don't think it does (at least irw doesn't report anything on key release), but even if it did surely it'd have to use a timeout to detect that there's nothing more coming from the remote, so the problem would be the same (unless the remote itself sends something to signal a key release).
I don't think any remote sends anything on key release. The codes usually allow distinguishing initial keypress events from key-repeat events. At key-release, the transmission simply stops.
For what it is worth, the driver of the bundled Hauppauge Nova-T RCU in the Linux kernel 2.6.12 and later will even map key-repeat to a timer. That is, if it gets a repeated RC5 frame within the timeout, it will keep generating key-repeat events, at a different rate. This makes many things inaccurate, such as scrolling in menus.
I would very much like to have a direct correspondence between repeated RC5 frames and key-repeat events, but I could not figure out how to do this in cx88-input.c or ir-common.c.
There's also a bug in cx88-input.c: if a RC5 frame is lost (e.g., when the RCU is almost out-of-range), the kernel driver will generate a key-press event instead of key-repeat. Similarly, if one presses a key in very rapid succession (at 10 Hz), repeat events will be generated instead of key-press. I managed to fix the first bug: http://www.iki.fi/~msmakela/software/vdr/#cx88-repeat
Marko
I demand that Marko Mäkelä may or may not have written...
On Sun, Jan 29, 2006 at 05:23:13PM +0100, Luca Olivetti wrote:
Well, maybe this is a general flaw of cLircRemote? Doesn't LIRC provide the information that the key has been released? That would make it unnecessary to wait for such a long time (REPEATDELAY) before signaling a "release".
I don't think it does (at least irw doesn't report anything on key release), but even if it did surely it'd have to use a timeout to detect that there's nothing more coming from the remote, so the problem would be the same (unless the remote itself sends something to signal a key release).
I don't think any remote sends anything on key release. The codes usually allow distinguishing initial keypress events from key-repeat events. At key-release, the transmission simply stops.
This is true...
For what it is worth, the driver of the bundled Hauppauge Nova-T RCU in the Linux kernel 2.6.12 and later will even map key-repeat to a timer. That is, if it gets a repeated RC5 frame within the timeout, it will keep generating key-repeat events, at a different rate.
This makes many things inaccurate, such as scrolling in menus.
I don't see how: with the unmodified budget-ci, it's slow enough...
I would very much like to have a direct correspondence between repeated RC5 frames and key-repeat events, but I could not figure out how to do this in cx88-input.c
cx88? That'd be the newer Nova-T, not the Nova-T :-)
or ir-common.c.
I've posted a set of patches to the v4l list which should be of some help; you should have a look at budget-ci after applying the patches, which you can also get from here: URL:http://ymbj/progs/linux/dvb-ir-20060129.patch.tar.gz
(You need to apply the keymaps patches first.)
[snip]
On Sun, Jan 29, 2006 at 10:36:32PM +0000, Darren Salt wrote:
For what it is worth, the driver of the bundled Hauppauge Nova-T RCU in the Linux kernel 2.6.12 and later will even map key-repeat to a timer. That is, if it gets a repeated RC5 frame within the timeout, it will keep generating key-repeat events, at a different rate.
This makes many things inaccurate, such as scrolling in menus.
I don't see how: with the unmodified budget-ci, it's slow enough...
RC5 frames are repeated every 113.8 ms (64*T, T=16/9 ms). The key-release timeout in cx88-input.c is 120 ms. I can't locate the repeat timer value in the sources now, but I think it was less than 100 ms. In your patch, you have defined IR_MIN_REPEAT_PERIOD to 133, so it should not be a problem. However, you also have IR_MIN_REPEAT_DELAY equal to 250 ms, which means that the first repeated RC5 frame will not result in any event.
I would very much like to have a direct correspondence between repeated RC5 frames and key-repeat events, but I could not figure out how to do this in cx88-input.c
cx88? That'd be the newer Nova-T, not the Nova-T :-)
Well, Nova-T 90002 REV C176, then. :-)
I've posted a set of patches to the v4l list which should be of some help; you should have a look at budget-ci after applying the patches, which you can also get from here: URL:http://ymbj/progs/linux/dvb-ir-20060129.patch.tar.gz
Hmm, I may be mistaken, but it looks to me as if your patches try to do the same thing for older cards as the new Nova-T driver already does. What I would really like to have is to map every RC5 frame either to a key-press or to a key-repeat, and a timer for generating key-release events. Does any existing driver (or patch) do that?
Marko
Marko Mäkelä wrote:
On Sun, Jan 29, 2006 at 10:36:32PM +0000, Darren Salt wrote:
For what it is worth, the driver of the bundled Hauppauge Nova-T RCU in the Linux kernel 2.6.12 and later will even map key-repeat to a timer. That is, if it gets a repeated RC5 frame within the timeout, it will keep generating key-repeat events, at a different rate.
This makes many things inaccurate, such as scrolling in menus.
I don't see how: with the unmodified budget-ci, it's slow enough...
RC5 frames are repeated every 113.8 ms (64*T, T=16/9 ms). The key-release timeout in cx88-input.c is 120 ms. I can't locate the repeat timer value in the sources now, but I think it was less than 100 ms. In your patch, you have defined IR_MIN_REPEAT_PERIOD to 133, so it should not be a problem. However, you also have IR_MIN_REPEAT_DELAY equal to 250 ms, which means that the first repeated RC5 frame will not result in any event.
I would very much like to have a direct correspondence between repeated RC5 frames and key-repeat events, but I could not figure out how to do this in cx88-input.c
cx88? That'd be the newer Nova-T, not the Nova-T :-)
Well, Nova-T 90002 REV C176, then. :-)
I've posted a set of patches to the v4l list which should be of some help; you should have a look at budget-ci after applying the patches, which you can also get from here: URL:http://ymbj/progs/linux/dvb-ir-20060129.patch.tar.gz
Hmm, I may be mistaken, but it looks to me as if your patches try to do the same thing for older cards as the new Nova-T driver already does. What I would really like to have is to map every RC5 frame either to a key-press or to a key-repeat, and a timer for generating key-release events. Does any existing driver (or patch) do that?
The av7110 driver does it exactly this way. I did a lot of testing to find the optimal method. ;-)
(1) The repeat timer of the input layer must be turned off, and the natural repeat rate of the RC5 frames should be used. Anything else will result in inaccurate operation.
(2) The key-up timeout should be set to 280ms or higher (>= 2x repeat rate). This will allow for one missing RC5 frame which may happen due to transmission errors.
Oliver
On Wed, Feb 01, 2006 at 07:51:04PM +0100, Oliver Endriss wrote:
cx88? That'd be the newer Nova-T, not the Nova-T :-)
Well, Nova-T 90002 REV C176, then. :-)
I've posted a set of patches to the v4l list which should be of some help; you should have a look at budget-ci after applying the patches, which you can also get from here: URL:http://ymbj/progs/linux/dvb-ir-20060129.patch.tar.gz
Hmm, I may be mistaken, but it looks to me as if your patches try to do the same thing for older cards as the new Nova-T driver already does. What I would really like to have is to map every RC5 frame either to a key-press or to a key-repeat, and a timer for generating key-release events. Does any existing driver (or patch) do that?
The av7110 driver does it exactly this way. I did a lot of testing to find the optimal method. ;-)
(1) The repeat timer of the input layer must be turned off, and the natural repeat rate of the RC5 frames should be used. Anything else will result in inaccurate operation.
(2) The key-up timeout should be set to 280ms or higher (>= 2x repeat rate). This will allow for one missing RC5 frame which may happen due to transmission errors.
Thanks, this sounds exactly what I'm looking for!
The 280 ms you mention matches the #define UP_TIMEOUT (HZ*7/25) in /usr/src/linux-2.6.14.3/drivers/media/dvb/ttpci/av7110_ir.c on my vdr box. I'll see if I'm smart enough to port the code to the cx88 driver.
Marko
I demand that Marko Mäkelä may or may not have written...
On Wed, Feb 01, 2006 at 07:51:04PM +0100, Oliver Endriss wrote:
[snip]
(1) The repeat timer of the input layer must be turned off, and the natural repeat rate of the RC5 frames should be used. Anything else will result in inaccurate operation.
(2) The key-up timeout should be set to 280ms or higher (>= 2x repeat rate). This will allow for one missing RC5 frame which may happen due to transmission errors.
Thanks, this sounds exactly what I'm looking for!
The 280 ms you mention matches the #define UP_TIMEOUT (HZ*7/25) in /usr/src/linux-2.6.14.3/drivers/media/dvb/ttpci/av7110_ir.c on my vdr box. I'll see if I'm smart enough to port the code to the cx88 driver.
linux/drivers/media/common/ir-functions.c would seem to be the right place for that code...
On Wed, Feb 01, 2006 at 09:56:40PM +0000, Darren Salt wrote:
I demand that Marko Mäkelä may or may not have written...
On Wed, Feb 01, 2006 at 07:51:04PM +0100, Oliver Endriss wrote:
[snip]
(1) The repeat timer of the input layer must be turned off, and the natural repeat rate of the RC5 frames should be used. Anything else will result in inaccurate operation.
(2) The key-up timeout should be set to 280ms or higher (>= 2x repeat rate). This will allow for one missing RC5 frame which may happen due to transmission errors.
Thanks, this sounds exactly what I'm looking for!
The 280 ms you mention matches the #define UP_TIMEOUT (HZ*7/25) in /usr/src/linux-2.6.14.3/drivers/media/dvb/ttpci/av7110_ir.c on my vdr box. I'll see if I'm smart enough to port the code to the cx88 driver.
linux/drivers/media/common/ir-functions.c would seem to be the right place for that code...
Which kernel version are you referring to? 2.6.14.3 lacks that file. I see that 2.6.16 is right around the corner.
I would really appreciate it if you could have a look at this. I have very little experience in kernel hacking. Last time I wrote something nontrivial was about 8 years ago. If you're not interested, I can try to come up with a cx88-specific patch, which can be refactored later.
Marko
Hello again! :)
Trying to compile Xine with XvMC, I am using Debian and have setup I believe the wrapper fine, which was packages in Debian, I am on AMD64, but once I do the compile I get the following error:
/usr/bin/ld: /usr/X11R6/lib/libXvMCW.a(XvMCWrapper.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/X11R6/lib/libXvMCW.a: could not read symbols: Bad value
Not completely sure on how to compile with the -fPIC, I think it is just CXXFLAGS=-fPIC before the make, but looking at the Makefile it appears as though info like that is already in there, and I get the same error regardless. Any idears? I am using Xine CVS from bout the 26th of January.
Thanks as always.
On Thu, 02 Feb 2006 12:26:13 -0600 Chad Flynt hoochster@sofnet.com wrote:
Hello again! :)
Trying to compile Xine with XvMC, I am using Debian and have setup I believe the wrapper fine, which was packages in Debian, I am on AMD64, but once I do the compile I get the following error:
/usr/bin/ld: /usr/X11R6/lib/libXvMCW.a(XvMCWrapper.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/X11R6/lib/libXvMCW.a: could not read symbols: Bad value
Not completely sure on how to compile with the -fPIC, I think it is just CXXFLAGS=-fPIC before the make, but looking at the Makefile it appears as though info like that is already in there, and I get the same error regardless. Any idears? I am using Xine CVS from bout the 26th of January.
There seems to be a missing symbolic link in the Debian X.org library package that prevents the linker from seeing the libXvMCW.so.1.0 shared library, so that it tries to use the static one instead. I fixed this by: ln -s /usr/X11R6/lib/libXvMCW.so.1.0 /usr/X11R6/lib/libXvMCW.so
Most of the x64-64 MMX-optimization problems should now be fixed in the latest Xine CVS. Xine developer Miguel Freitas has been doing a lot of nice work this weekend.
I still had the chcon problem on Debian unstable though. If you get an error from chcon during install, move it away for a while (mv /usr/bin/chcon /usr/bin/chcon-backup) and run "make install" again. This could be a problem with my system only. I'll need to check it before reporting a bug to the Xine developers.
-- Niko Mikkilä
On Wed, Feb 01, 2006 at 09:56:40PM +0000, Darren Salt wrote:
I demand that Marko Mäkelä may or may not have written...
On Wed, Feb 01, 2006 at 07:51:04PM +0100, Oliver Endriss wrote:
[snip]
(1) The repeat timer of the input layer must be turned off, and the natural repeat rate of the RC5 frames should be used. Anything else will result in inaccurate operation.
(2) The key-up timeout should be set to 280ms or higher (>= 2x repeat rate). This will allow for one missing RC5 frame which may happen due to transmission errors.
Thanks, this sounds exactly what I'm looking for!
The 280 ms you mention matches the #define UP_TIMEOUT (HZ*7/25) in /usr/src/linux-2.6.14.3/drivers/media/dvb/ttpci/av7110_ir.c on my vdr box. I'll see if I'm smart enough to port the code to the cx88 driver.
linux/drivers/media/common/ir-functions.c would seem to be the right place for that code...
I guess you meant ir-common.c, after all.
I made a quick&dirty patch to ir-common.c and cx88-input.c that maps each incoming RC5 frame to a key-press or a key-repeat event. The key-release timeout is set to 280 ms. I tried blocking the IR beam for a couple of seconds while holding the Volume+ button down. After I unblocked the beam, the repeat events would continue.
Thanks to the patch, it is now possible to reach any line on long listings such as the EPG menu, by holding the Down button and releasing it when the selection mark reaches the line.
The only drawback in my patch is that it is sometimes hard to press a repeating key (e.g., Channel+) quickly enough to only generate a key-press event without any key-repeat. After all, it might be good to discard the first key-repeat event. Do av7110 users have this problem?
It'd be nice if this patch could be polished and submitted to the kernel. Are there any v4l-dvb developers on this list?
Marko
Marko Mäkelä wrote:
On Wed, Feb 01, 2006 at 09:56:40PM +0000, Darren Salt wrote:
I demand that Marko Mäkelä may or may not have written...
On Wed, Feb 01, 2006 at 07:51:04PM +0100, Oliver Endriss wrote:
[snip]
(1) The repeat timer of the input layer must be turned off, and the natural repeat rate of the RC5 frames should be used. Anything else will result in inaccurate operation.
(2) The key-up timeout should be set to 280ms or higher (>= 2x repeat rate). This will allow for one missing RC5 frame which may happen due to transmission errors.
Thanks, this sounds exactly what I'm looking for!
The 280 ms you mention matches the #define UP_TIMEOUT (HZ*7/25) in /usr/src/linux-2.6.14.3/drivers/media/dvb/ttpci/av7110_ir.c on my vdr box. I'll see if I'm smart enough to port the code to the cx88 driver.
linux/drivers/media/common/ir-functions.c would seem to be the right place for that code...
I guess you meant ir-common.c, after all.
I made a quick&dirty patch to ir-common.c and cx88-input.c that maps each incoming RC5 frame to a key-press or a key-repeat event. The key-release timeout is set to 280 ms. I tried blocking the IR beam for a couple of seconds while holding the Volume+ button down. After I unblocked the beam, the repeat events would continue.
Thanks to the patch, it is now possible to reach any line on long listings such as the EPG menu, by holding the Down button and releasing it when the selection mark reaches the line.
The only drawback in my patch is that it is sometimes hard to press a repeating key (e.g., Channel+) quickly enough to only generate a key-press event without any key-repeat. After all, it might be good to discard the first key-repeat event. Do av7110 users have this problem?
No, this problem is handled by input_repeat_key/delay_timer_finished magic. ;-)
The driver discards all keypresses until the delay timer of the input layer has expired. Btw, this delay may be adjusted by user space tools.
It'd be nice if this patch could be polished and submitted to the kernel. Are there any v4l-dvb developers on this list?
Darren posted a patch on the v4l/dvb lists. Maybe you could join your efforts and submit a patch against the current hg repository.
Oliver
I demand that Oliver Endriss may or may not have written...
Marko Mäkelä wrote:
On Wed, Feb 01, 2006 at 09:56:40PM +0000, Darren Salt wrote:
I demand that Marko Mäkelä may or may not have written...
On Wed, Feb 01, 2006 at 07:51:04PM +0100, Oliver Endriss wrote:
[snip]
(1) The repeat timer of the input layer must be turned off, and the natural repeat rate of the RC5 frames should be used. Anything else will result in inaccurate operation.
(2) The key-up timeout should be set to 280ms or higher (>= 2x repeat rate). This will allow for one missing RC5 frame which may happen due to transmission errors.
Thanks, this sounds exactly what I'm looking for!
The 280 ms you mention matches the #define UP_TIMEOUT (HZ*7/25) in /usr/src/linux-2.6.14.3/drivers/media/dvb/ttpci/av7110_ir.c on my vdr box. I'll see if I'm smart enough to port the code to the cx88 driver.
linux/drivers/media/common/ir-functions.c would seem to be the right place for that code...
I guess you meant ir-common.c, after all.
Both, really: it was renamed fairly recently.
I made a quick&dirty patch to ir-common.c and cx88-input.c that maps each incoming RC5 frame to a key-press or a key-repeat event. [...]
I've altered ir-functions.c:ir_input_keydown() here to make this easier: there should no longer any need for other modules to alter ir->keypressed. If you have a new keypress, call ir_input_nokey() then ir_input_keydown(), else call ir_input_keydown() only and the patched code will notice that it's for the same key and cause a repeat event instead.
[snip]
The only drawback in my patch is that it is sometimes hard to press a repeating key (e.g., Channel+) quickly enough to only generate a key-press event without any key-repeat. After all, it might be good to discard the first key-repeat event.
I have logic for that currently in budget-ci, but it really belongs in ir-common.
Do av7110 users have this problem?
No, this problem is handled by input_repeat_key/delay_timer_finished magic. ;-)
The driver discards all keypresses until the delay timer of the input layer has expired. Btw, this delay may be adjusted by user space tools.
Hmm. So the standard repeat code should be used everywhere...?
[snip]
It'd be nice if this patch could be polished and submitted to the kernel. Are there any v4l-dvb developers on this list?
Darren posted a patch on the v4l/dvb lists. Maybe you could join your efforts and submit a patch against the current hg repository.
FWIW, my current patch sets are linked from URL:http://www.youmustbejoking.demon.co.uk/progs.linux.html#dvb
And we need to take this to the v4l list :-)
On Tue, Feb 07, 2006 at 01:17:56AM +0000, Darren Salt wrote:
I made a quick&dirty patch to ir-common.c and cx88-input.c that maps each incoming RC5 frame to a key-press or a key-repeat event. [...]
I've altered ir-functions.c:ir_input_keydown() here to make this easier: there should no longer any need for other modules to alter ir->keypressed. If you have a new keypress, call ir_input_nokey() then ir_input_keydown(), else call ir_input_keydown() only and the patched code will notice that it's for the same key and cause a repeat event instead.
This sounds reasonable. However, how do you distinguish rapid keypresses from repeat? In RC5 code, there is a toggle bit that changes state at a new keypress. In other codes, the repeat code may differ from the code of the first keypress.
I think that ir_input_keydown() or equivalent function should take the repeat flag as a parameter. The function should never convert a repeat code to a keypress or vice versa. Two examples:
(1) If I press the '1' key two times very quickly, I want VDR to see '11'. In your scheme, I'm afraid it will produce '1' and '1'|kRepeat, and VDR will ignore the second keypress.
(2) When I press the '1' button close to the maximum range of the remote (which is not much with the Hauppauge receiver that is driven out of spec), the driver should deliver the events 12022020 instead of 12012010, so that VDR will switch to channel 1 and not 111.
FWIW, my current patch sets are linked from URL:http://www.youmustbejoking.demon.co.uk/progs.linux.html#dvb
And we need to take this to the v4l list :-)
Sure.
Marko
I demand that Marko Mäkelä may or may not have written...
On Tue, Feb 07, 2006 at 01:17:56AM +0000, Darren Salt wrote:
I made a quick&dirty patch to ir-common.c and cx88-input.c that maps each incoming RC5 frame to a key-press or a key-repeat event. [...]
I've altered ir-functions.c:ir_input_keydown() here to make this easier: there should no longer any need for other modules to alter ir->keypressed. If you have a new keypress, call ir_input_nokey() then ir_input_keydown(), else call ir_input_keydown() only and the patched code will notice that it's for the same key and cause a repeat event instead.
This sounds reasonable. However, how do you distinguish rapid keypresses from repeat? In RC5 code, there is a toggle bit that changes state at a new keypress. In other codes, the repeat code may differ from the code of the first keypress.
There's a toggle bit: bit 5 of the second byte.
I think that ir_input_keydown() or equivalent function should take the repeat flag as a parameter.
No need. If you want a keypress not to be flagged as a repeat, call ir_input_nokey() first. For a key to be flagged as being repeated, don't call ir_input_nokey() between two successive calls to ir_input_keydown().
The function should never convert a repeat code to a keypress or vice versa. Two examples:
(1) If I press the '1' key two times very quickly, I want VDR to see '11'. In your scheme, I'm afraid it will produce '1' and '1'|kRepeat, and VDR will ignore the second keypress.
That won't be a problem unless interrupts are being missed. AFAICT (printk), that isn't happening.
(2) When I press the '1' button close to the maximum range of the remote (which is not much with the Hauppauge receiver that is driven out of spec), the driver should deliver the events 12022020 instead of 12012010,
Meaning what?
so that VDR will switch to channel 1 and not 111.
Well... it'll generate a repeat for each received signal (assuming that the key is held down) and it may time out, causing the next received signal to be treated as a key-down event.
With the /other/ scheme (using the input layer's own repeat handler), you will get repeats - and maybe a few more 1s (although I'm enforcing lower limits on the repeat/delay times, and the timeout is shorter than the repeat time).
[snip]
On Tue, Feb 07, 2006 at 06:24:02PM +0000, Darren Salt wrote:
I've altered ir-functions.c:ir_input_keydown() here to make this easier: there should no longer any need for other modules to alter ir->keypressed. If you have a new keypress, call ir_input_nokey() then ir_input_keydown(), else call ir_input_keydown() only and the patched code will notice that it's for the same key and cause a repeat event instead.
This sounds reasonable. However, how do you distinguish rapid keypresses from repeat? In RC5 code, there is a toggle bit that changes state at a new keypress. In other codes, the repeat code may differ from the code of the first keypress.
There's a toggle bit: bit 5 of the second byte.
Yes, in the RC5 code there is, just like I wrote.
The function should never convert a repeat code to a keypress or vice versa. Two examples:
(1) If I press the '1' key two times very quickly, I want VDR to see '11'. In your scheme, I'm afraid it will produce '1' and '1'|kRepeat, and VDR will ignore the second keypress.
That won't be a problem unless interrupts are being missed. AFAICT (printk), that isn't happening.
The RC5 repeat rate is 113.8 ms. If I press the same button twice within that time frame, it does happen. I must admit that this seems to happen with my own patch as well. I'll have to add some debug code to display the RC5 frames to see whether the toggle bit really is toggling.
(2) When I press the '1' button close to the maximum range of the remote (which is not much with the Hauppauge receiver that is driven out of spec), the driver should deliver the events 12022020 instead of 12012010,
Meaning what?
0=key-release 1=key-press 2=key-repeat
I see that I should have picked another button than '1', to avoid confusing it with the number of the key-press event.
so that VDR will switch to channel 1 and not 111.
Well... it'll generate a repeat for each received signal (assuming that the key is held down) and it may time out, causing the next received signal to be treated as a key-down event.
With 240 ms key-release timeout, it will time out if two RC5 frames are lost. If you hold the RCU in the wrong angle or far away from the receiver and press the button longer to ensure that the event will be noticed, you will end up getting multiple keypress events instead of one keypress and multiple repeat events.
With the /other/ scheme (using the input layer's own repeat handler), you will get repeats - and maybe a few more 1s (although I'm enforcing lower limits on the repeat/delay times, and the timeout is shorter than the repeat time).
I tested patch 3326 of the hg/v4l-dvb tree with your patches dvb-ir-20060206.patch.tar.gz applied. I changed the key-release timeout in cx88-input.c from 120 to 240 ms. Few keys were recognized. Among the working keys were the number keys, although they were shifted by 1 (e.g., '6' would be reported as '7'). The input layer's own repeat handler was not disabled, that is, I think there were too many repeat events. I couldn't figure out how budget-ci.c disables the repeat timer.
I was unable to use this driver, because one of the cx88 modules failed to load and the computer crashed after some time.
Marko
I demand that Marko Mäkelä may or may not have written...
On Tue, Feb 07, 2006 at 06:24:02PM +0000, Darren Salt wrote:
I've altered ir-functions.c:ir_input_keydown() here to make this easier: there should no longer any need for other modules to alter ir->keypressed.
[snip]
The function should never convert a repeat code to a keypress or vice versa. Two examples:
(1) If I press the '1' key two times very quickly, I want VDR to see '11'. In your scheme, I'm afraid it will produce '1' and '1'|kRepeat, and VDR will ignore the second keypress.
That won't be a problem unless interrupts are being missed. AFAICT (printk), that isn't happening.
The RC5 repeat rate is 113.8 ms.
That matches what I'm seeing. It seems safe to assume that my remote control does indeed use RC5.
If I press the same button twice within that time frame, it does happen. I must admit that this seems to happen with my own patch as well. I'll have to add some debug code to display the RC5 frames to see whether the toggle bit really is toggling.
I just stuck in a printk: either it wasn't being toggled or I wasn't properly releasing the button. (I could probably tell, but I don't plan on opening up the remote control until I have to for other reasons.)
(2) When I press the '1' button close to the maximum range of the remote (which is not much with the Hauppauge receiver that is driven out of spec), the driver should deliver the events 12022020 instead of 12012010,
Meaning what?
0=key-release 1=key-press 2=key-repeat
Oh, right: input_event last parameter.
Both are possible, depending on the number of consecutive unreceived frames.
[snip]
so that VDR will switch to channel 1 and not 111.
Well... it'll generate a repeat for each received signal (assuming that the key is held down) and it may time out, causing the next received signal to be treated as a key-down event.
With 240 ms key-release timeout, it will time out if two RC5 frames are lost.
Which seems reasonable to me, although this should perhaps be a module parameter with, at least, a fixed minimum value. The right place for it is in ir-common, but one step at a time...
If you hold the RCU in the wrong angle or far away from the receiver and press the button longer to ensure that the event will be noticed, you will end up getting multiple keypress events instead of one keypress and multiple repeat events.
You might get a mixture of both.
With the /other/ scheme (using the input layer's own repeat handler), you will get repeats - and maybe a few more 1s (although I'm enforcing lower limits on the repeat/delay times, and the timeout is shorter than the repeat time).
I tested patch 3326 of the hg/v4l-dvb tree with your patches dvb-ir-20060206.patch.tar.gz applied. I changed the key-release timeout in cx88-input.c from 120 to 240 ms. Few keys were recognized. Among the working keys were the number keys, although they were shifted by 1 (e.g., '6' would be reported as '7').
Oops. The last patch in that series is broken - part of it got lost. It's attached.
The input layer's own repeat handler was not disabled, that is, I think there were too many repeat events. I couldn't figure out how budget-ci.c disables the repeat timer.
If ir->rep[0] and ir->rep[1] are both zero then input_register_device() will set default delay and repeat values and install its repeat handler.
I was unable to use this driver, because one of the cx88 modules failed to load and the computer crashed after some time.
All that I can say is that budget-ci is fine...
On Tue, Feb 07, 2006 at 11:00:23PM +0000, Darren Salt wrote:
If I press the same button twice within that time frame, it does happen. I must admit that this seems to happen with my own patch as well. I'll have to add some debug code to display the RC5 frames to see whether the toggle bit really is toggling.
I just stuck in a printk: either it wasn't being toggled or I wasn't properly releasing the button. (I could probably tell, but I don't plan on opening up the remote control until I have to for other reasons.)
I loaded cx88xx with ir_debug=1 or something like that, and got debug output in dmesg. Indeed, the toggle bit did not toggle. If this is the case with two RCUs, then this is probably not an issue (that is, the bug is already in the RCU).
[snip]
With 240 ms key-release timeout, it will time out if two RC5 frames are lost.
Which seems reasonable to me, although this should perhaps be a module parameter with, at least, a fixed minimum value. The right place for it is in ir-common, but one step at a time...
Agreed.
[snip]
I tested patch 3326 of the hg/v4l-dvb tree with your patches dvb-ir-20060206.patch.tar.gz applied. I changed the key-release timeout in cx88-input.c from 120 to 240 ms. Few keys were recognized. Among the working keys were the number keys, although they were shifted by 1 (e.g., '6' would be reported as '7').
Oops. The last patch in that series is broken - part of it got lost. It's attached.
Thanks, I'll try it out after some time (hopefully, with a snapshot that has better working cx88 drivers).
The input layer's own repeat handler was not disabled, that is, I think there were too many repeat events. I couldn't figure out how budget-ci.c disables the repeat timer.
If ir->rep[0] and ir->rep[1] are both zero then input_register_device() will set default delay and repeat values and install its repeat handler.
Thanks, I'll try setting those.
Marko
On Tue, Feb 07, 2006 at 11:00:23PM +0000, Darren Salt wrote:
I tested patch 3326 of the hg/v4l-dvb tree with your patches dvb-ir-20060206.patch.tar.gz applied. I changed the key-release timeout in cx88-input.c from 120 to 240 ms. Few keys were recognized. Among the working keys were the number keys, although they were shifted by 1 (e.g., '6' would be reported as '7').
Oops. The last patch in that series is broken - part of it got lost. It's attached.
Thanks. All keys seem to be mapped correctly now. The only difference I was able to spot was that previously, the number keys were mapped to KP0..KP9 instead of 0..9.
I was unable to use this driver, because one of the cx88 modules failed to load and the computer crashed after some time.
All that I can say is that budget-ci is fine...
cx88 sure isn't. The tuner module could not be loaded, and vdr drops frames when playing recordings via softdevice. I'll try fixing the cx88-input.c auto-repeat later based on hg/v4l-dvb and your patches.
Marko
On Thu, Feb 09, 2006 at 09:30:50AM +0200, Marko Mäkelä wrote:
All that I can say is that budget-ci is fine...
cx88 sure isn't. The tuner module could not be loaded, and vdr drops frames when playing recordings via softdevice. I'll try fixing the cx88-input.c auto-repeat later based on hg/v4l-dvb and your patches.
Done; see the video4linux list for details.
I also improved my patch to the Hauppauge Nova-T PCI 90002 driver in Linux 2.6.15.2. Now it will discard the first repeated RC5 frame, effectively doubling the repeat delay from 113.8 milliseconds to 227.6 milliseconds. The 113.8-millisecond repeat delay of the previous patch was too short for my wife, and occasionally also too short for me. The repeat rate remains at 113.8 milliseconds, that is, the built-in repeat rate (64*T, T=16/9 ms) of the remote control unit.
You can get the updated 2.6.15.2 patch at the following location: http://www.iki.fi/~msmakela/software/vdr/linux-2.6.15.2-cx88_input2.patch
Marko
Am Sonntag, 29. Januar 2006 16:34 schrieb Klaus Schmidinger:
- Separated the 'install' target into several individual targets;
renamed the 'plugins-install' target to 'install-plugins' (thanks to Helmut Auer).
It would be consistent to rename the plugins-clean target to clean-plugins too.
S.
.
Klaus Schmidinger wrote:
- Removed the "buffer reserve" in Transfer Mode - it's no longer
necessary with recent driver/firmware versions.
I had set GotBufferReserve = true in the previous version. Things improved a lot - ARD Dolby Digital stuttering went away. Yesterday I still had problems when recording ARD ( Dolby Digital ) and ZDF ( Dolby Digital ) in parallel yesterday on my 2 card system.
System was almost unusable as long as I watched the ZDF live signal or the ZDF recording. Switching to another (available channel) helped alltough recording went on.
I tried today and it things worked much better (only a little slower OSD). Maybe at has to do with the fact that yesterday's "Wetten dass" was in DD 5.1 and today's program is DD 2.0.
I noticed that the code in transfer.c has reduced a lot - can that be reason or is it the same a previous code with GotBufferReserver = true ?
It seems to me that ARD/ ZDF Dolby Digital is some kind of corrupted because there have been no problems with Pro/ or SAT.1
Thanks Peter
Peter Juszack wrote:
Klaus Schmidinger wrote:
- Removed the "buffer reserve" in Transfer Mode - it's no longer
necessary with recent driver/firmware versions.
I had set GotBufferReserve = true in the previous version. Things improved a lot - ARD Dolby Digital stuttering went away. Yesterday I still had problems when recording ARD ( Dolby Digital ) and ZDF ( Dolby Digital ) in parallel yesterday on my 2 card system.
System was almost unusable as long as I watched the ZDF live signal or the ZDF recording. Switching to another (available channel) helped alltough recording went on.
I tried today and it things worked much better (only a little slower OSD). Maybe at has to do with the fact that yesterday's "Wetten dass" was in DD 5.1 and today's program is DD 2.0.
I noticed that the code in transfer.c has reduced a lot - can that be reason or is it the same a previous code with GotBufferReserver = true ?
That should actually be the same.
It seems to me that ARD/ ZDF Dolby Digital is some kind of corrupted because there have been no problems with Pro/ or SAT.1
Since around the beginning of this year the ZDF broadcasts with a much higher bandwidth than before. That's why recording and watching channels on that transponder is a problem on a single card system.
Klaus
Klaus Schmidinger schrieb:
Since around the beginning of this year the ZDF broadcasts with a much higher bandwidth than before. That's why recording and watching channels on that transponder is a problem on a single card system.
Arrrrgh! It's a higher bit (data) rate but _not_ bandwidth!
Alain
Alain Vaslet wrote:
Klaus Schmidinger schrieb:
Since around the beginning of this year the ZDF broadcasts with a much higher bandwidth than before. That's why recording and watching channels on that transponder is a problem on a single card system.
Arrrrgh! It's a higher bit (data) rate but _not_ bandwidth!
Alain
But doesn't that ultimately result in a higher bandwidth of that particular broadcast?
Klaus
Klaus Schmidinger schrieb:
Since around the beginning of this year the ZDF broadcasts with a much higher bandwidth than before. That's why recording and watching channels on that transponder is a problem on a single card system.
Arrrrgh! It's a higher bit (data) rate but _not_ bandwidth!
But doesn't that ultimately result in a higher bandwidth of that particular broadcast?
??? NO! The reason why ZDF is broadcasting at a higher bit rate is that Eurosport and Euronews went off their transponder (to KDG transponder on 23,5°). Bandwidth is a measure of frequency range, measured in hertz. This range has _not_ changed which would be rather difficult because frequencies on satellites are pretty fix. Also modulation, FEC and symbol rate have not been changed.
Alain
Alain Vaslet wrote:
Klaus Schmidinger schrieb:
Since around the beginning of this year the ZDF broadcasts with a much higher bandwidth than before. That's why recording and watching channels on that transponder is a problem on a single card system.
Arrrrgh! It's a higher bit (data) rate but _not_ bandwidth!
But doesn't that ultimately result in a higher bandwidth of that particular broadcast?
??? NO! The reason why ZDF is broadcasting at a higher bit rate is that Eurosport and Euronews went off their transponder (to KDG transponder on 23,5°). Bandwidth is a measure of frequency range, measured in hertz. This range has _not_ changed which would be rather difficult because frequencies on satellites are pretty fix. Also modulation, FEC and symbol rate have not been changed.
Alain
I was not referring to the bandwidth of the entire transponder. I'm pretty sure that hasn't changed. I was referring to the individual signal of the ZDF channel, with
VPID: 110 APID: 120=deu,121=2ch DPID: 125=dd
Apparently they are broadcasting that channel using a bigger chunk of the total transponder capacity, which means a higher data rate, ok, but ultimately results in a sharper image with more details and better audio (why else would they do it?). And a sharper image means that the video signal has a higher bandwidth, doesn't it?
Klaus
Klaus Schmidinger schrieb:
I was not referring to the bandwidth of the entire transponder. I'm pretty sure that hasn't changed. I was referring to the individual signal of the ZDF channel, with
VPID: 110 APID: 120=deu,121=2ch DPID: 125=dd
Apparently they are broadcasting that channel using a bigger chunk of the total transponder capacity, which means a higher data rate, ok, but ultimately results in a sharper image with more details and better audio (why else would they do it?). And a sharper image means that the video signal has a higher bandwidth, doesn't it?
In analog video transmission I would agree but here the bandwidth applies only to the entire transponder only, not to one TV channel. Because of modulation (e.g. DVB-T -> COFDM) a single program cannot be associated to a special frequency (range). Just nitpicking but bandwidth is too often mixed up with data rate.
Alain
-
Alain Vaslet -
Chad Flynt -
Darren Salt -
Klaus Schmidinger -
Luca Olivetti -
Marko Mäkelä -
Niko Mikkila -
Oliver Endriss -
Peter Juszack -
Sebastian Frei