DRI2 Protocol Spec Draft

[Kristian Høgsberg]

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.

I'm changing the protocol for CopyRegion to be like
XChangeWindowAttributes, taking a value mask and a list of values as
determined by the mask.  This will let us bump the protocol version
and add more arguments to the CopyRegion request in a backwards
compatible manner.  We can then add the CRTC to sync to as an argument
later if we find a case where the client really can make a better
decision than the server.

> 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).

So we need to be able to specify whether to drop a frame or postpone
it when we miss the target.  I'm not happy about having to return the
effective swap sequence number... is there a way we can move the
computation of the next target to the server?  What is the heurstics
there anyway?  Hmm... I'll take a look a the code.

Kristian