This allows overlays to work on drivers that only have one usable
overlay plane and when we are using the primary plane (which often
must be exactly CRTC-sized) to overlay on top of a video underlay.
This is currently race-prone because nothing is synchronizing
between other Qt and SDL uses of DRM master, so it can cause
false negatives if we can't retake master ourselves.
For atomic drivers, use a test-only commit to fully exercise the
path that we will be using when rendering.
For legacy drivers, mask the variable portion of Broadcom modifiers
before matching with IN_FORMATS.
libdrm is inconsistent between returning -1 with an errno set
and just returning -errno as the return value. Figuring out which
behavior a given libdrm function has require reading the source :/
As it turns out, there *are* in fact hardware vendors dumb enough
to ship V4L2 decoders that output buffers which are unsupported by
any plane on their display hardware. By checking modifiers, we can
still fall back to GLES on GL_IS_SLOW=1 builds in this case.
It doesn't work well in practice for a few major reasons:
- It can result in the decoder writing on DMA-BUFs being used by the display
- It can generate page flip events that collide with Qt/SDL
- It can stall the decoder if the DMA-BUF has a fence on it from the display driver
The platforms that would most benefit (embedded V4L2 decoders)
either don't use frame pooling or don't synchronize with
modified DMA-BUFs unless eglCreateImage() is called each time.
Every renderer except SDL had opted-in for testing due to various
quirks discovered over the years, so just do away with this option
and test all renderers.
It's possible that modesetting will also change the resolution
not just the refresh rate. This can happen in cases where the
CRTC is currently set to 4K 30 Hz and we choose 1080p 60 Hz as
a better mode match for displaying a 1080p 60 FPS stream.
This case basically works like a degenerate case of a DRM hwaccel
without DRM master where we just provide EGL export functionality
except that we don't even need a DRM FD in this case.
There are patches floating around the FFmpeg list for this:
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=12604
