[PATCH] Xv: Fix AdjustFrame when driver implements ReputImage.

[Luc Verhaegen]

On Thu, Nov 26, 2009 at 05:47:25PM -0800, Keith Packard wrote:
> > 
> > 2 week bump, for something that fixes a 4 year old bug.
> 
> I suspect the fact that the underlying code is twisty and
> incomprehensible may have made people reluctant to even try and review
> this patch.
> 
> I spent a few minutes looking at the code and it looks good to me, in
> particular, the patch makes the code look more sensible.
> 
> XV_PENDING is set when trying to do a video operation and the output is
> completely clipped or failed for some other reason (line 744, 835, 922,
> 1491, 1606 and 1794). It is also set when the window is exposed and the
> driver doesn't provide a ReputImage function (line 1083), or when the
> window becomes invisible during ClipNotify (line 1137), or becomes
> FullyObscured in AdjustFrame (line 1318).
> 
> XV_PENDING appears to be an indication that video *should* be presented,
> but just isn't because the driver has returned an error or because the
> window is fully obscured. So, every time the window becomes more
> visible, we should try to make it no longer XV_PENDING.
> 
> The patch simply makes the AdjustFrame code actually look at XV_PENDING
> windows and, if the window is not fully obscured, calls ReputImage to
> get bits on the screen. The second change in the patch handles the XV_ON
> case (now that the block includes both XV_ON and XV_PENDING) separately,
> setting the port to XV_PENDING if the window is now fully obscured.
> 
> One case which wasn't clear when I started reading the code was whether
> xf86XVReputImage would handle XV_PENDING ports correctly; reading that
> code, it looks like it will work as it sets portPriv->isOn along every
> potential code path.
> 
> So, with that,
> 
> Reviewed-by: Keith Packard <keithp at keithp.com>

Thanks for the thorough review.

Anything else that stops this code from being stuck in master?

Luc Verhaegen.