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 <[email protected]>
Thanks for the thorough review. Anything else that stops this code from being stuck in master? Luc Verhaegen. _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
