Giuseppe Bilotta <giuseppe.bilo...@gmail.com> writes: > Ok, I'm convinced. Just as a curiosity though, are there any plans (or > anything special that needs planning) to support things such as > adaptive sync?
Adaptive sync has a bunch of additional work required: 1) Model the display time to provide estimates for when redisplay could occur. 2) Create a way to send the planned frame time to all applications so they can draw the correct image for each frame 3) Adapt the kernel interface to use time rather than frame count for page flipping. I don't have any particular plans for this; I suspect it will be easiest to make this work for direct display Vulkan first, then figure out how to plumb it through X. > Why would there be a need for the server to send an event to the CM? My thinking is that the X server would lock the window system from changes and then deliver an event to the Compositing Manager. Otherwise, the CM would have to wake up and do a round trip to grab the server and flush any pending events. > I was actually more worried about potential dangers of deadlocks, > actually, or something like that. Like, a client sending multiple > events, some affecting windows on a blocked CRTC, others affecting > windows on a non-blocked CRTC, and there being some kind of implicit > assumption somewhere that the events would be processed in order, > whereas during lockdown the server might end up serving them in a > different order. Oh, if the client does something that is blocked, the whole client gets blocked. Otherwise, as you say, we violate the requirement for sequential execution of X requests. The server is permitted to suspend clients for arbitrary amounts of time, but not to perform operations out of order. > Sorry, I meant for the Compositing Manager to send a specific message. > As in, instead of doing an actual grab/ungrab, have something like a > PreparePresentNotify that the Compositing Manager sends to the server, > with the information about the AutoList for the (upcoming) > PresentPixmap and the CRTC to lock down. Yeah, the problem is that the Compositing Manager can't send the Auto List until after it has locked the server down and fetched all of the pending updates, in case one of those changes invalidates the assumptions built into the Auto List. It still looks like the problem of making Composite reliably generate correct and complete frames is separate from the goal of automatically compositing some portion of the frame inside the X server. I think I'm pretty much ready to go prototype the Auto List bits and see how that goes. -- -keith
signature.asc
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel