[RFC xserver v3 13/14] present: Send a PresentWindowCrtcNotify event appropriately

Louis-Francis Ratté-Boulianne lfrb at collabora.com
Mon Oct 16 05:45:38 UTC 2017


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


More information about the xorg-devel mailing list