DRI2 Protocol Spec Draft

[Kristian Høgsberg]

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

Kristian.