Three recent blog postings on DRI3000

[Keith Packard]

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

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.

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.

> The idea is that
> the application is (falsely) told that vblanks occur at that rate,
> renders perfect frames at that rate without tearing, and then these
> perfect frames are buffered in order to be shown on each of the
> outputs during that output's vblank.

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

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20130726/b0355045/attachment.pgp>