[vlc-devel] [PATCH] - issue with mouse-x/mouse-y on Linux

brezhoneg1 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 +
p_vout->fmt_in.i_x_offset  ]

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 mailing list