On Wednesday, September 19, 2007 3:52 am Michel D=C3=A4nzer wrote:
> On Tue, 2007-09-18 at 14:54 -0700, Jesse Barnes wrote:
> > As it stands, DRM_IOCTL_WAIT_VBLANK is downright broken in the new
> > world of dyanmically controlled outputs and CRTCs (at least for
> > i915 and radeon): a client trying to sync against the second CRTC
> > that doesn't pass _DRM_VBLANK_SECONDARY will only work if one CRTC
> > is enabled, due to the way current interrupt handlers increment the
> > respective vblank counters (i.e. they increment the correct counter
> > if both CRTCs are generating events, but only the primary counter
> > if only one CRTC vblank interrupt is enabled).
> Yes, I made it that way to allow old Mesa drivers that don't know
> anything about secondary vblank to work. The trouble is that at least
> xf86-video-intel currently never enables vblank interrupts for pipe B
> only, which defeats that purpose. It's really too bad I screwed up
> trying to make all this backwards compatible, so I'm afraid it looks
> like we have to bite the bullet and make incompatible changes again
> to hopefully make things right finally.
Well I'm not sure you screwed it up, before we had randr1.2 enabled=20
drivers that scheme made a lot of sense. :)
> > The vblank-rework branch of the DRM tree tries to address (1) and
> > (2) by splitting the logic for handling CRTCs and their associated
> > vblank interrupts into discrete paths, but this defeats the
> > original purpose of the driver interrupt code that tries to fall
> > back to a single counter, which is due to limitations in (5),
> > namely that the glX*VideoSyncSGI APIs can only handle a single
> > pipe.
> Right, it would be nice if we could preserve the above with
> Or, I guess another option would be to stop caring about old Mesa
> drivers that don't know about secondary vblank and to just make sure
> things work as well as possible when vblank interrupts are enabled
> for both pipes. But note that 'old drivers' currently includes i965
> and all Radeon drivers.
Given that some of this will break no matter what, I like this option=20
> > One way of making the glX*VideoSyncSGI interfaces behave more or
> > less as expected would be to make them more like
> > DRM_I915_VBLANK_SWAP internally, i.e. using SAREA values to
> > determine which pipe needs to be sync'd against by passing in the
> > display plane the client is most tied to (this would imply making
> > the Intel specific SAREA plane info more generic),
> Not necessarily - the driver could provide its own versions of the
> GetMSC and WaitForMSC hooks, or we could make the generic ones use a
> new driver hook to determine whether to use secondary vblank.
Yeah, common code would be best.
- use the vblank-rework tree to make per-CRTC vblank counters (as you
say, this breaks some setups but will fix others)
- add code to Mesa so GetMSC/WaitForMSC set DRM_VBLANK_SECONDARY
That should make the current stack work fairly well. And when there's a=20
real need, we can look at adding multipipe aware extensions.
I can finish up the Intel bits, but the vblank-rework tree still needs=20
mach64, mga, r128 and via updated. And the Mesa parts of those drivers=20
need updating to handle multiple pipes. Anyone have time to tackle=20