Synchronization with CRT refresh

[Jim Gettys]

On Tue, 2005-05-03 at 16:17 -0400, Michel Dänzer wrote:
> On Tue, 2005-05-03 at 14:40 -0400, Adam Jackson wrote:
> > On Tuesday 03 May 2005 14:32, Michel Dänzer wrote:
> > > Ahem. I implemented this in the DRM years ago. I even extended the
> > > interface to optionally generate a signal instead of blocking in the
> > > ioctl on request by yours truly and Keith Packard, but I'm still not
> > > aware of anything using that. Oh well.
> > 
> > Excellent!  I anticipated needing a DRM driver for this anyway.  Is this the 
> > same mechanism as handles vsync in the r200 DRM?
> 
> Yes. It's a driver-independent ioctl, i.e. the ioctl number and
> interface is the same for all drivers.
> 
> One thing that's still missing is the ability to select the display
> controller that should be waited for on cards with multiple controllers,
> but the interface should be extensible enough that this could be added
> in a backwards compatible way.
> 

Vertical retrace is clearly a property of the monitor, rather than the
graphics card itself...

I've recently become aware of another issue that can come up.

I've been playing with a system that has both flatpanel and projector.

On the flatpanel, I get nice DVD playback, with no tearing.

When I move the window to the projector on the second video output (in
this case, it happens to be an nvidia running TwinView), I start getting
video tearing, as the second RAMDAC does not run at exactly the same
frequency as the primary (Andy Ritger says that the card I'm using only
synchronizes the ramdac if you use the identical modelines, which is
unfortunate, as I'm mixing a 1280x768 flatpanel with a 1024x768
projector.


There are several possible solutions here:

1) say "it isn't our fault", and punt to the card to "do the right
thing" with no additional information.

2) Somehow request genlock between video outputs, on the same or various
monitors, with X (and/or the mode selection system we've been talking
about) requesting this behavior.

I'm not enough of a video weenie to know what is likely best here, or
what the hardware will let us do over the next few years.

I predict, though, that this kind of configuration is going to become
common as projectors have become so cheap, and wobulated projectors/TV
sets hit the markets this year (which take their resolution up to
1920x1024 class resolution at little additional cost over conventional
DLP's; what we'll sell them for, is, of course, a different question
than what the cost is).  (Yes, Virginia, google wobulation: it is a real
term... ;-)).

> 
> On Tue, 2005-05-03 at 14:53 -0400, Jim Gettys wrote: 
> > 
> > It would be good to publish the interface: we need to get the same
> > interface implemented in other drivers than the DRM as well.
> 
> What would be the preferred form of publishing it? FWIW, the interface
> is defined in drm.h, look for drm_wait_vblank_t.
> 
> 

Well, John Smirl is hacking on the Linux fb driver.  Coordination there
is probably the place to go...
				- Jim