DRI2 Protocol Spec Draft

[Michel Dänzer]

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.


On Wed, 2008-09-10 at 14:16 -0400, Kristian Høgsberg wrote:
> On Tue, Sep 9, 2008 at 1:34 PM, Michel Dänzer
> <michel at tungstengraphics.com> wrote:
> >
> > If the GLX implementation is to use DRI2CopyRegion for synchronization
> > purposes, then the interface of the latter needs to be at least as
> > expressive as the DRM synchronization interfaces currently used by the
> > former.
> 
> Could you give a quick summary of what those are and where you think
> DRI2CopyRegion falls short?

See e.g. intelScheduleSwap() in
mesa/src/mesa/drivers/dri/intel/intel_buffers.c:

      * For the case of missing the target, chooses to accept tearing or
        execute the swap during the next vblank period (based on driconf
        vblank_mode).
      * Chooses the primary or secondary CRTC.
      * Needs the returned effective/expected sequence number to know if
        the target was hit or missed and to calculate the next target
        sequence number.

The MSC related APIs as in mesa/src/mesa/drivers/dri/common/vblank.c
also need to be consistent with the DRI2CopyRegion sequence numbers. So
I think DRI2 would need to wrap the DRM_IOCTL_WAIT_VBLANK functionality
as well (or be DRM specific, which would be unfortunate - and could
still have issues like mapping the CRTC IDs between the DRM and DRI2
interfaces).


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