Xv Reput/Reget behaviour changes

[Luc Verhaegen]

On Fri, Oct 29, 2010 at 09:18:56PM +0300, ville.syrjala at nokia.com wrote:
> I'm trying to eliminate some rather nasty looking on/off blinking
> that's bothering my video overlays.
> 
> The xfree86 xv code hooks into ClipNotify, WindowExposures and
> AdjustFrame and does something a little different in each of them.
> I tried to decipher the intention of the original code, but even
> after trawling through the xfree86 cvs, I was unable to find any
> explanation for most of the differences. I suspect the code reached
> it's current state simply due to some ad-hoc copy pasting in an
> effort to fix some specific issues.
> 
> So I just gave up on the history and tried to think what would make
> the most sense for each case and did that. The end result is that
> Reput/Reget is done in most cases if the window is visible,
> StopVideo is done if the window is invisible, and if ReputImage
> isn't supported the port is removed from the window.
> 
> With these changes most of the blinking is gone. There is still at
> least one case left though. Window (un)redirection does an internal
> UnmapWindow+MapWindow cycle which causes ClipNotify to get called with
> visibility = NotViewable. If anyone has a suggestion how to eliminate
> that problem without a majore rewrite, I'd be happy to try it.
> 
> I'd also like the overlays to track RandR state properly so I added a
> new hook 'ModeSet' that gets called when something interesting happens.
> I just realized that I should probably call it from
> xf86DisableUnusedFunctions() as well. Hmm, actually it looks like
> xf86DisableUnusedFunctions() already has this crtc_notify hook I could
> maybe use. Would there be objections to adding more calls to that
> hook from set_origin (and perhaps some other mode setting functions)?
> 
> Also CCing Luc since he did something for xf86XVAdjustFrame at some
> point in the past...

Hi Ville,

Since i have a rather busy time now (family visits, and then visiting 
the nokia family later next week), i will only be able to review this 
properly on the train over to the munich airport on thursday. Sadly, i 
will not be able to give this code a run on a reputimage capable driver 
in at least two weeks (i am not dragging a unichrome over to helsinki 
:))

The modeset hook does make me frown, that is a serious addition to the 
api, which will make backwards compatibility (of for instance the omapfb 
driver) impossible. I am not sure whether this is really necessary. Can 
you explain why this is needed and why driver internal modesetting 
cannot handle this?

Luc Verhaegen.