DRI2 Protocol Spec Draft

[Michel Dänzer]

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.

The second draft says about DRI2AbsoluteSync:

        The client is expected to query the kernel rendering manager for
        the current frame count in order to compute the desired target
        frame.

But that isn't possible with the proposed interface and the DRM
interfaces, which expose independent per CRTC sequence numbers.
(Ignoring that the target sequence number needs to be calculated from
the effective sequence number of the previous swap, not from whatever
sequence number happens to be current when calling DRI2CopyRegion)

> We can extend the CopyRegion request easily, so lets add the pipe
> attribute when we have a way of getting that info from the app.

Given issues like the above, it may indeed be better to only add any
vsync functionality once the relevant use cases have at least been
prototyped throughout the stack.

Will it be possible to add reply values to DRI2CopyRegion though?


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