DRI2 Protocol Spec Draft

[Michel Dänzer]

On Mon, 2008-09-15 at 12:11 -0400, Kristian Høgsberg wrote:
> On Fri, Sep 12, 2008 at 12:20 PM, Michel Dänzer
> <michel at tungstengraphics.com> wrote:
> > On Thu, 2008-09-11 at 16:02 -0400, Kristian Høgsberg wrote:
> >> On Thu, Sep 11, 2008 at 3:49 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> >> > 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.
> >>
> >> Ok, I guess what I want to say is: until we have a good story on how
> >> the app is going to figure out which display it wants to sync to, tell
> >> this to GLX, I'd like to hold off on putting it in the protocol.
> >
> > The app isn't required to be actively involved, e.g. there could be a
> > driconf option.
> 
> If the only way to control this policy is through config files, it
> might as well become an xorg.conf option.  Or a randr12 property on
> the CRTC.  Similarly for how to handle missed swap targets - that
> could be an xorg.conf option too.

The latter is already a driconf option (part of vblank_mode). The
advantage of driconf is that it allows per application (as well as per
screen or per driver) configuration.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer