[PATCH] ugly patch for DRM based XSync VBLANK support

[Michel Dänzer]

On Sat, 2006-03-11 at 16:36 -0800, Jesse Barnes wrote:
> On Saturday, March 11, 2006 3:20 pm, Benjamin Herrenschmidt wrote:
> > Whith also leads to the question is does XSync make any sense in a
> > MergedFB environment and if not, should we maybe invent some
> > alternative and drop it in XFixes or other grabbag ? :)

I think it makes about as much or little sense as sync-to-vblank does
with MergedFB.

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


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.

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.

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


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer