Hi, On Fri, 2017-09-29 at 18:45 +0200, Michel Dänzer wrote: > On 27/09/17 07:19 AM, Louis-Francis Ratté-Boulianne wrote: > > When the window has changed CRTC, send the event. > > This doesn't make sense to me I'm afraid. > With the current present implementation, which CRTC is used for > synchronization shouldn't have any cottelation with which modifiers > are > optimal for the pixmap being presented. (The window may still be > visible > on the same set of CRTCs as before we switched the CRTC for > synchronization)
You were totally right, I tried to go for the simple solution and totally misunderstood that part of CRTCs in the process. I was also not returning the right set of modifiers (it needs to be the intersection of modifiers for all enabled CRTCs). Both problems should be fixed in my new submission (RFC v4), I would appreciate your opinion. > > What does matter for the modifiers is whether or not page flipping > can [...] > Or maybe it would be sufficient for clients to simply re-query the > modifiers in response to PresentConfigureNotify events? I'm using a different solution now. PresentCompleteNotify is reponsible to tell the client whether it could do better. If mode is SuboptimalCopy (instead of e.g. Flip or Copy), it means the Present operation has been executed using a copy, but the pixmap could have been flipped if it was allocated using a different format/modifier (all other conditions are/should be fulfilled). It does mean there always a frame needed before the client knows it should re-fetch the modifiers and re-allocate buffers. I think that small cost is acceptable. Also, when going back from flipping to copying (e.g. unmaximizing a window), my mesa implementation currently doesn't try to find the optimal format/modifier and just keep the scanout optimized one (All formats/modifiers returned by the xserver absolutely need to support GPU copying anyway). That mean be improved later, but shouldn't really be a problem for now. Thank you, -- Louis-Francis Ratté-Boulianne Collabora _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
