Hi, I thought I'd chime in on this because we've discussed the issues within the GGI/KGI group a lot. Our conclusions were as follows:
A) Relying on any type of signal/process wakeup from the kernel introduces unwanted latency. B) Not using a signal results in not being able to guarantee that the process is running when the desired ray position is found. C) Most of the people wanting to use this capability want to do one of a small list of things -- flip buffers, change splitline/origin, load palette etc. D) In many cases it is the vblank, not vsync, which is the desirable condition to trigger the action, as this gives a lot more time for actions to complete before the beginning of the next frame. So we decided that although we'd support a generic wakeup-based method, the kernel side must be able to perform the most commonly used functions in C), and accept and queue a request queued to do so. So we will be adding an API to our projects for queueing such requests. Regardless of what the kernel back-end is, though, an API like XSync is needed for X. XSync is actually pretty well done. I read the XSync and the DBE extension documentation some time ago when trying to figure out if they could help implement syncronisation for the GGI X target. I seem to recall the API was there to do it but there were few if any implementations. I'd urge the X11 project to review the APIs and to also consider them from the perpective of virtual drivers (that is, X running on top of some software API) in addition to merely from a hardware level. I hope this helps firm up the resolve here to do the implementation. -- Brian _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
