summaryrefslogtreecommitdiffstats
path: root/DOCS/man
diff options
context:
space:
mode:
authorUoti Urpala <uau@mplayer2.org>2011-05-01 15:57:39 +0300
committerUoti Urpala <uau@mplayer2.org>2011-05-02 00:44:21 +0300
commit5c4b059f1608f6d6a981b7d81a14f1c46e40ba52 (patch)
treea44d6824a334b23dd16ee60ef06302c973b00b28 /DOCS/man
parentb9eaafe1ed4f38efcd08d113d9e51e9ebb034f6e (diff)
downloadmpv-5c4b059f1608f6d6a981b7d81a14f1c46e40ba52.tar.bz2
mpv-5c4b059f1608f6d6a981b7d81a14f1c46e40ba52.tar.xz
input: rewrite -key-fifo-size limiting logic
Instead of strictly limiting the number of total entries in the internal fifo, make the overall buffer bigger and try to limit entries based on how many bound commands they're expected to generate. Now doubleclick and button down events aren't counted for that limit. Normally the sequence down-doubleclick-up generates at most one command, so this better matches the quantity we actually want to limit. Also add a mechanism to clear the button combination state kept by input.c when the fifo is full; this avoids "stuck button" problems due to button release events being dropped. The key combination state clearing is partially based on MPlayer 1 changes by Reimar Döffinger (though overall the effects of this commit are quite different). It still doesn't make "stuck button" problems completely impossible; at least if the VO gets closed while a button was down then nothing will send a button up event or reset state.
Diffstat (limited to 'DOCS/man')
-rw-r--r--DOCS/man/en/mplayer.111
1 files changed, 4 insertions, 7 deletions
diff --git a/DOCS/man/en/mplayer.1 b/DOCS/man/en/mplayer.1
index 7d96bd2773..0f3a2b2aa6 100644
--- a/DOCS/man/en/mplayer.1
+++ b/DOCS/man/en/mplayer.1
@@ -922,13 +922,10 @@ several 'echo "seek 10" > mp_pipe' and the pipe will stay valid.
.TP
.B \-key\-fifo\-size <2\-65000>
Specify the size of the FIFO that buffers key events (default: 7).
-A FIFO of size n can buffer (n\-1) events.
-If it is too small some events may be lost
-(leading to "stuck mouse buttons" and similar effects).
-If it is too big, MPlayer may seem to hang while it
-processes the buffered events.
-To get the same behavior as before this option was introduced,
-set it to 2 for Linux or 1024 for Windows.
+If it is too small some events may be lost.
+The main disadvantage of setting it to a very large value is that if you
+hold down a key triggering some particularly slow command then the player
+may be unresponsive while it processes all the queued commands.
.
.TP
.B \-lircconf <filename> (LIRC only)