Scott Long ([EMAIL PROTECTED]): > I'm not suggesting that XFree86 take on the responsibility for these > drivers! What I'm saying is it doesn't seem like such a big deal to > simply have *support* for a vblank mechanism. Leave the details of how > it occurs up to a particular set of drivers. If people need vblank > badly enough, the driver support will get written. You're right that > other platforms might not support this so easily -- but so what? If > people really need it, they'll write it. > > I guess I'm proposing some sort of X extension that allows a > particular X request to be tagged as "synced to vblank." For example a > XCopyArea request could be preceded by another request (call it > XRequestVerticalSync) that indicates to the server that the operation > shouldn't be performed until a vblank period.
We already have that in XSYNC, I thought. You can definitely define a counter for vsyncs and have requests scheduled for them, at least that was my impression. Some folks in the DRI world are doing a standard device API. There are also a million different kernel module hacks that export vsync interrupts existing now, look at any of the video applications right now: we have like 4 different mga kernel modules for hardware overlay surfaces with vsync interrupts, now svgalib has their own kernel callback driver, DRI has theirs presumably for page flipping at some point, etc. I think the main reason for the lack of a standard effort is the varying requirements of the projects proposing these solutions. The mplayer folks (and some xine/etc authors) want some kernel solution that's independent of X and DRI and fbcon, since they want to support different levels of exlusive or direct access. Some other projects, such as DirectFB, only care about this in the context of fbcon itself. And then the DRI folks only care about X, and so solutions from that arena may not work outside of a running X server. Resolving this is going to be difficult: X developers don't ever seem to want to consider compatibilty with driver layers that aren't X, for one. > This is a very simple change. If no driver support exists for vertical > sync, the server can just politely ignore the request, and do the > operation whenever it feels like it. This would at the very least > provide a framework for individual driver writers to start working on > a kernel interface. Getting back to this, I think we're getting there especially with the recent DRI work. It's not like _nobody_ is thinking about this issue, it is being dealt with. Join #dri-devel on freenode if you want to discuss it, that's where at least some conversation has occurred (but yeah, in the context of DRI/GL, not in the context of syncing generic X requests in the X server itself, afaik). -- Billy Biggs [EMAIL PROTECTED] _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
