On Mon, Jul 22, 2013 at 03:08:02PM +1000, [email protected] wrote: > From: Christopher James Halse Rogers <[email protected]> > > This is missing too much functionality to be usefully appiled, but the > skeleton is here and the APIs it relies on are sufficiently stable. Sending > to the list for extra visibility and for preliminary comments.
So one comment that came up, that could do with a few wiser heads, was the rationale for the buffer_available callback. This callback is sent to the driver from inside a socket handler after XMir receives notification from the mir-system-compositor thread that the fd is available for redrawing. The intent is that this provides a hook for the driver to submit fresh rendering as early as possible in order for the display to continue to update (in its psuedo-frontbuffer fashion) without waiting upon clients to become idle. The flaw in this argument, is that the buffer_available socket is only checked for readibility when the server finishes processing all client requests, i.e. at the same time as the normal blockhandler would run. The current solution to this problem on the input side is to use signals. Another would be to use threads (and then make the rendering code threadsafe, which is quite unpalatable). However, it also looks like we can use "dispatchException |= DE_PRIORITYCHANGE;" to interrupt dispatch processing and service the render request. That would then require making dispatchException threadsafe (using atomic bit operations should suffice). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
