[PATCH] ugly patch for DRM based XSync VBLANK support

Adam Jackson ajax at nwnk.net
Wed Mar 15 16:17:46 PST 2006


On Saturday 11 March 2006 18:20, Benjamin Herrenschmidt wrote:
> On Sat, 2006-03-11 at 14:11 -0800, Jesse Barnes wrote:
> > Here's an ugly patch that attempts to add an XSync system counter called
> > "VBLANK" to the server if the underlying drm driver that was just
> > opened supports vblank signals.  It doesn't work very well for a couple
> > of reasons:
> >   o drmOpen is working ok (I get back a real fd) but drmWaitVBlank gives
> >     me EPERM instead of EINVAL like it should (my test machine doesn't
> >     have a drm driver with vblank support yet), so VBLANK support is
> >     disabled (IOW I haven't actually tested it :)
> >   o it's totally multihead ignorant
> >
> > Hopefully someone can clue me in about the first problem, and the second
> > needs a bit more thought.  It seems like there should be an XSync
> > VBLANK counter per-screen, not per-drm and obviously not a single
> > global one.  It looks like the drm drivers could handle this, but it
> > would make things harder for the clients since they'd have to dig
> > through the system counters to find the VBLANK counter corresponding to
> > their head (I guess via strmp?) which means a well defined namespace
> > for the VBLANK XSync counters is necessary.  Thoughts?
> >
> > Also, I wasn't sure if this stuff belonged in xf86drm.c, I'm guessing
> > probably not.  Any ideas about a better place?
> >
> > Other comments and review appreciated.
>
> 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 ? :)

Essentially you need something like GLX_SGIX_hyperpipe for this to work 
completely right.  Sync to vblank can be tear-free within a single monitor, 
so for the lazy case of just doing tear-free rendering across multiple heads 
the compositing manager can do one thread per head and this will work "well 
enough".  As soon as you want to start syncing vblank among multiple screens 
to avoid the popping effect when updating a single frame of animation across 
multiple heads, you need physical cabling to tie the vblank signal together 
across each screen, and you need that cabling topology reflected back into X 
somehow, be that config file or hardware probing magic.

So for now I'd go for the ICCCM name of VBLANK_Sx for each screen, and name 
the counters something else when we grow vblank topology support.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060315/71c3562b/attachment-0001.pgp>


More information about the xorg mailing list