DRI2 Protocol Spec Draft

Jesse Barnes jbarnes at virtuousgeek.org
Thu Sep 11 12:49:10 PDT 2008

On Thursday, September 11, 2008 8:59 am Kristian Høgsberg wrote:
> On Thu, Sep 11, 2008 at 6:40 AM, Michel Dänzer
> <michel at tungstengraphics.com> wrote:
> > On Wed, 2008-09-10 at 14:09 -0400, Kristian Høgsberg wrote:
> >> On Tue, Sep 9, 2008 at 11:46 AM, Keith Packard <keithp at keithp.com> wrote:
> >> > On Tue, 2008-09-09 at 13:27 +0200, Michel Dänzer wrote:
> >> >> For DRI2CopyRegion, you're leaving it to the DDX driver to pick the
> >> >> CRTC to synchronize to? I'm not sure that'll work too well with
> >> >> overlapping viewports, where the user may want to choose which CRTC
> >> >> to synchronize to for each application.
> >> >
> >> > Yeah, I don't see a good way to avoid this, and the client can always
> >> > pass in 'Automatic' (0) and let the server pick the 'right' one.
> >>
> >> Do we need this?  When will the client have a better idea of which
> >> pipe a window is on than the X server?
> >
> > Whenever a window is visible on multiple CRTCs (in particular, think
> > fullscreen video/presentation on laptop panel and beamer), only the user
> > can know which CRTC should be synchronized to.
> I don't know that we need to make it this complicated... there is no
> right choice when your window spans two CRTCs.  Either you have fancy
> gen-locked hardware in which case it doesn't matter, or your CRTCs
> scan out at different refresh rates, in which case you can't win.  If
> the window is completely within one or the other CRTC, the X server
> can pick the right CRTC.

In the sense that you'd get tearing on at least one output that's true.  
However, in Michel's example, the user would probably want to sync to the 
beamer not the laptop display, if they were doing a multimedia presentation.  
So in some cases there definitely is a "right choice".  It may be sufficient 
to sync everything to one output though, rather than do things on a 
per-client basis; I'm not sure if one is easier than the other, design-wise.


More information about the xorg mailing list