[PATCH 2/2] DRI2: Add error message when working around driver bug

[Jesse Barnes]

On Tue, 26 Oct 2010 19:19:11 +0300
Pauli Nieminen <ext-pauli.nieminen at nokia.com> wrote:
> SGI_video_sync:
> "The kernel maintains a video sync counter for 
> each physical hardware pipe in a system; the counter is incremented 
> upon the completion of the display of each full frame of video data. An
> OpenGL context always corresponds to a pipe."

Right, this is the rule we break; we don't have a 1:1 correspondence
between gfx pipes and display pipes.

> "The single video sync counter is shared by all GLXContexts."
> 
> Yes. You have to extent both OML_sync_control and SGI_video_sync to expose
> separate MSC for different CRTCs. 
> 
> I can see race condition even with events.
> 
> * Client checks for event (none yet in queue)
> * Client prepares to call some blocking msc call
> * Window manager decides to move the window
> * xserver send MSC change event
> * Client calls blocking MSC call
> 
> But maybe there is solution. All blocking calls could fail if MSC base
> changes. Client would have to query for new base and rate before trying to
> issue same request again.

Yeah, that might work; I agree there's a race even with events that
we'll need to handle.  But even with that race handled I'd like the
server to fail gracefully rather than hanging the app if an old MSC
value is passed in (though in that case we could print an error message
since we could assume an app error as long as the app was using the
extended version of the spec).

> For swap interval it would be enough if DDX would notify DRI2 about crtc
> changes with offset (msc_for_new_crtc - msc_for_old_crtc) that can be applied
> to swaptarget.

Yeah, just jumping to the new value might be ok in general.  Hardcore
libraries like Mario's can do something fancier with the extensions
above to avoid unintended behavior.

Thanks again for all your work on this.  These are good improvements.

-- 
Jesse Barnes, Intel Open Source Technology Center