If the BUFFER flag is not set in a commit, it means
the buffer is inherited on the surface.
As this is equivalent to a commit with same buffer,
ensure forward progress is made on frame callbacks.
This behavior also matches Mutter and Weston based on tests.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
This avoids a problem where frame callback is reported before we have
actually committed to display a surface. This could lead to skipping
where application commits a new surface before the current surface will
be queued up for display. This breaks FIFO rules in e.g. Vulkan.
A scenario where this matters is when GPU is rendering slower than
refresh rate.
Also avoids a problem where the commit queue can grow large since
frame callbacks will be pumped faster than the GPU is able to process
the frames.
At least Mutter behavior is similar here, so I think this is the correct
interpretation.
Also fixes KHR_present_wait in Xwayland. Xwayland uses frame callback to
signal PRESENT_COMPLETE and this fixes that.
1. Many game engines automatically render to 10-bit formats such as UE4 which means
that when we have to composite, we can keep the same HW dithering that we would get if
we just scanned them out directly.
2. When compositing HDR content as a fallback when we undock, it avoids introducing
a bunch of horrible banding when going to G2.2 curve.
It ensures that we can dither that.
Makes more sense instead of sending done after we commit for page flip, otherwise the cadence can be slightly too ahead.
(Accounts for the bubble of time after latch -> commit being included in the time when we want to submit)
This also ensures that in the case where QueuePresent can stall on Wayland WSI (ew, gross!) that that stall will be finished before the next acquire.
This is essentially a fix for src/rendervulkan.cpp:3075 (before this commit).
Instead of first selecting a queue and later failing, if the selected
queue can't be used for presenting, this patch considers the fact, *when*
selecting a queue.
As a result quite a bit of code had to be re-ordered to make sure the
surface already exists, when selecting the queue.
On certain configurations the EDID retrieval and parsing seems to fail,
leading to create_patched_edid accessing out of bounds indexes on a zero
length vector.
