[PATCH] ugly patch for DRM based XSync VBLANK support

[Jesse Barnes]

On Monday, March 13, 2006 3:41 am, Michel Dänzer wrote:
> > I hadn't even considered that... yeah it seems like a problem.  We
> > could just disable it in a MergedFB environment and hope people use
> > something else (maybe that will become possible with a proper memory
> > manager?), or somehow provide per-head stuff anyway?
>
> Or maybe we could just make this Xinerama aware somehow. No idea if
> that's even possible with the driver-specific Xinerama implementations
> though.

I'll have to look around to see if that's doable.  I don't know much 
about Xinerama or its implementation.

> Anyway, thanks for finally attempting to put the DRM vblank signal
> interface to good use! I wonder if there wouldn't be a better way than
> the BlockHandler to 'get the word out' that the counter has increased,
> but maybe there is none without a poll/select interface from the DRM.

Well, right now it's in the Wakeup handler, but I agree that it's not 
ideal.  The Wakeup handler could be called a long time after the actual 
signal was received, making it vulnerable to scheduling.

> You may want to determine the current vblank count by calling
> drmWaitVBlank() with vbl.request.type=DRM_VBLANK_RELATIVE and
> vbl.request.sequence=0 instead of just increasing it monotonically on
> each signal to avoid missing vblanks, e.g. due to scheduling latency.

Good point, I'll fix that.  Scheduling latency is definitely a problem.

> Also, you don't seem to initialize the requested signal number. I
> wonder if that could be why you get EPERM instead of EINVAL.

Oops!  That's definitely a bug, I'll fix it and see if anything changes 
(though I won't be able to get to it until this weekend at the 
earliest).

Jesse