Three recent blog postings on DRI3000

[Alexander E. Patrakov]

2013/7/27 Keith Packard <keithp at keithp.com>:
> "Alexander E. Patrakov" <patrakov at gmail.com> writes:
>
>> 2013/7/26 Keith Packard <keithp at keithp.com>:
>>> "Alexander E. Patrakov" <patrakov at gmail.com> writes:
>>>
>>>> Which frame?
>>>>
>>>> Suppose that there are two overlapping outputs with vastly different
>>>> refresh rates (say, an old 100 Hz CRT and a modern 60 Hz LCD).
>>>
>>> I'm afraid I just don't care very much about getting this case
>>> 'right'. What Present (and DRI2 before it) does is to have the driver
>>> just pick one of the outputs and use that as the MSC source.
>>
>> OK, let's try to get this case handled later (maybe in wayland), then.
>> I am sure someone else will complain about the same thing, too,
>> because even 59.93 Hz vs 60 Hz matters here.
>
>
>> You are completely right here. The problem is that there is no way to
>> influence the choice which monitor (especially in a cloned
>> configuration) looks good. I.e., on my laptop (which I intend to bring
>> to GUADEC), the Intel driver always seems to favor the internal panel
>> if it is cloned to the Intel HDMI output. And in some cases (e.g. PAL
>> movie playback) the judder is unavoidable on a typical 60-Hz-only
>> monitor, so what one cares about is tearing.
>
> I'm adding an explicit CRTC to the PresentRegion request (None == X
> server picks). This will allow applications to select which monitor to
> synchronize with.

>From the protocol viewpoint - OK. However, I think that at some point
some configuration request (similar to setting the xrandr primary
output? or even reusing that information, if it works) should be added
in order to make the "X server picks" case more predictable.
Otherwise, we'll end up duplicating the disambiguation-preference
logic in all applications. I.e., I should be able to tell the X
server: if in doubt (e.g. with complete clones and the application
saying "None"), pick the HDMI monitor.

>> True. However, in theory, in the future, it should be possible to have
>> two framebuffers, one for each output, displaying "the same thing" but
>> updating independently (thus two blts, each synchronized to the
>> correct refresh interval, thus achieving the same as below).
>
> If they're not overlapping, you can just create two windows and update
> them separately.

For the non-overlapping case - OK. But I specifically have the
overlapping case in mind.

> In any case, it looks like Present may make per-CRTC pixmaps pretty easy
> to manage; just Present a pixmap in a full-monitor window and have the X
> server flip to that just on that monitor. This seems like it should be a
> pretty simple change at this point; right now, the flip is 'global', but
> there's no particular reason to make it be that way.

Yes, I think that it should work for my use case. However, I have some
doubts related to other use cases. If I understand you correctly, you
are going to allow an application to present a full-screen pixmap to
just one monitor of two, and forget about the second one. After that,
an implicit invariant "two monitors show the same" set up by "xrandr
--output XXX --same-as YYY" breaks for an undefined amount of time
(but on the other hand, I do want to break it after the first
monitor's refresh, but before the second one's). Please think about
this, as I don't have a good idea what to do. The easiest (but ugly)
solution would be to completely ban xrandr configurations with
overlapping outputs and let the compositing manager emulate that, as
described below. Surely there must exist a better (less intrusive)
solution.

I think that one could have a compositing window manager that
configures two non-overlapping (independent) outputs, composites the
final picture into an output-sized pixmap and flips each CRTC to the
resulting pixmap, carefully avoiding any blt-based presentation. This
way we get a pseudo-clone (each monitor showing "the same" composited
picture from a user viewpoint), without tearing on either monitor (but
with judder on all but one of them), even if the refresh rates are
different. If I understand the proposal correctly, this can even work
with a "global" flip.

-- 
Alexander E. Patrakov