[MPlayer-dev-eng] Stuck mouse buttons

[Diego Biurrun]

Marius Gedminas writes:
> 
> Occasionally (but often enough to get annoying) when I click a mouse
> button on an mplayer window the button gets stuck -- hitting any key
> afterwards produces messages like
> 
>   No bind found for key MOUSE_BTN1-SPACE
> 
> although MOUSE_BTN1 is *not* held down.  It is easy for me to reproduce
> the problem by hitting a mouse button for a very brief period of time.
> 
> More than one mouse button can get stuck.  I managed all three of them.
> 
> I've traced the problem to mplayer_put_key in fifo.c.  After
> uncommenting the line that warns about dropped key events (FIFO full) I
> started seeing these messages every time a button got stuck.  While
> ignoring keypresses on a full FIFO buffer is a sensible thing to do
> with normal keys, it does not work well with mouse button release events...
> 
> I should mention that HAVE_NO_POSIX_SELECT is not defined here and thus
> the first version of mplayer_put_key is used (the one which uses select
> on a pipe).  This is a Debian system (mixed stable/testing/unstable)
> with glibc 2.3.2 (libc6 2.3.2.ds1-11), and kernel 2.4.24.  I do not use
> the mplayer GUI.
> 
> What seems strange to me is that the FIFO becomes full with just one key
> event in it.  Apparently trying to use a Unix pipe as a generic FIFO
> buffer does not work as expected.  When I defined HAVE_NO_POSIX_SELECT
> in config.h and recompiled mplayer the problem went away.
> 
> I suspect that select on a pipe will not say the fd is ready for writing
> if the buffer is not completely empty.  Normally you can write up to
> PIPE_BUF bytes without blocking, but if the buffer already contains
> something, then writing PIPE_BUF bytes would block.  IOW using select
> for a generic FIFO buffer does not work well.
> 
> I think a better solution would be to use nonblocking writes.  Something
> like the attached patch (tested here, but not tested for portability --
> and the #ifdef with HAVE_NO_POSIX_SELECT should be changed to something
> different as well).
> 
> Or maybe it would be simplest to always use the in-memory array solution
> (mplayer_put_key + mplayer_get_key).  I expect it to be marginally
> faster as well (no syscalls, no context switches).

I just tested this patch and it works as advertised.  We should really
fix this ancient bug.  Somebody please review and commit this.

I'm attaching the patch again since many will not have it readily
available.

Diego

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mplayer-stuck-buttons.patch
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20041021/f1a85366/attachment.asc>