[PATCH] ugly patch for DRM based XSync VBLANK support
Michel Dänzer
michel at daenzer.net
Mon Mar 13 03:41:05 PST 2006
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
More information about the xorg
mailing list