Three recent blog postings on DRI3000

[Alexander E. Patrakov]

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.

> Showing frames at the wrong time is just another form of distortion; in
> this case, motion will not be smooth on monitors not correctly
> synchronized with the application update. Pick one monitor, make that
> one look good, then make the other monitors suffer some kind of
> distortion. In the current (admittedly simplistic) Present code, you
> either get tearing at the right time (on copy-based updates) or no
> tearing at the wrong time (on flip based updates).

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.

> For copying updates, there's no choice here -- we've only got one frame
> buffer in X, so you can only synchronize the blt with one of the two
> refresh intervals.

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

> For swap updates, you'll actually get things swapped without tearing on
> both monitors (unless you ask for async swapping), but one monitor will
> be correctly synchronized and the other one will probably get a bunch of
> judder as updates happen with random amounts of delay.

Also true.

-- 
Alexander E. Patrakov