[vlc-devel] [PATCH] - issue with mouse-x/mouse-y on Linux
brezhoneg1 at yahoo.fr
Wed Feb 11 18:54:06 CET 2009
Le mercredi 11 février 2009 18:34:33 brezhoneg1, vous avez écrit :
>> In xcommon.c and sdl.c, mouse-x and mouse-y lower/upper limits are
>> wrongly computed.
>> Lower limits set to zero may be considered a convention, but upper
>> is short of an x or y offset.
>> Only xcommon.c and sdl.c have got this problem. The other vout
>> just don't set limits at all. (Actually, that may be the best
>To me, these patches look like they create an asymetry between top/left
>bottom/right borders. That looks suspicious, or I am missing something.
Yes, it is asymmetric because I just corrected the upper limit which
leads to a real bug. I should have corrected to lower limit too for
beauty of symmetry.
Here is the formula used in xcommon.c :
/* Compute the x coordinate and check if the value is
in [0,p_vout->fmt_in.i_visible_width] */
val.i_int = ( xevent.xmotion.x - i_x ) *
p_vout->fmt_in.i_visible_width / i_width +
This formula __doesn't__ give [ 0 , p_vout->fmt_in.i_visible_width ] as
stated in the comment but
[ p_vout->fmt_in.i_x_offset, p_vout->fmt_in.i_visible_width +
And limits (against which tests must be done) are :
xevent.xmotion.x - i_x = 0
xevent.xmotion.x - i_x = i_width
Now, do we need [ p_vout->fmt_in.i_x_offset,
p_vout->fmt_in.i_visible_width + p_vout->fmt_in.i_x_offset ] as the
range of value is another question ? But, if this formula is used, this
is the segment that results from it.
More information about the vlc-devel