Instead of having an add_formats() function, make the get_downloader()
function add the formats.
This allows putting the actual downloader in a different place from the
initialization code.
This is done without testing, just doing my best to map all the DRM
formats to VkFormats.
Once people start using them, they'll figure it out when it's wrong.
(Somebody needs to write a testsuite.)
When we use the builtin downloads via mmap(), it's a special case where
we don't need to initialize subsystems and query them for support. We
know what we can and can't do.
Also, we want to use these formats with the lowest priority but pick the
downloader first for supported formats, and queueing it in the
downloaders list doesn't reflect that. So don't do it.
Track fallback formats to use in the memoryformat directly instead of
using in the GL uploading code.
First of all, this allows sharing the code and ensuring all our
renderers use the same fallback mechanism.
But also, this allows tracking fallbacks per-format which is useful
because the fallback formats aren't really a tree. We want to make
FLOAT16 fall back to FLOAT32 when not available, but we also want
FLOAT32 fall back to FLOAT16.
By tracking the fallbacks per-format, we can achieve that.
Add gdk_memory_format_get_premultiplied() and
gdk_memory_format_get_straight() which return the matching
premultiplied/straight format.
Use this to pick the premultiplied format when uploading GL textures.
And remove the duplication in the dmabuf code, where we can now use
these functions instead of tracking both the premultiplied and straight
alpha versions.
Add an "RGBA" format that just maps to the swizzled version of the
default format.
This way, BGR gets mapped to RGB + swizzling first before trying to map
it to the default format for the depth.
The benefit here is that this format has the same memory width, so
uploading/downloading code can treat it equivalent to the original
format and there's no conversion neccessary later.
Now that we have gdk_gl_context_get_memory_flags() and code can use that
function, make the code do that.
Remove support checks from gdk_memory_format_gl_format().
This is an initial naive port that doesn't try to make use of the finer-grained
flags yet.
Checks which features of a given memory format are supported by
the current GL implementation.
We check:
* usable: Can be used as a texture with NEAREST filter
* renderable: Can be used as a render target
* filterable: Can be used with GL_LINEAR
In normal GL, all formats are all of these things, but GLES is a lot
more picky.
So far nobody uses this.
If a subsurface is not below, it is visible no matter what the opaque
region is.
Also, we don't need to care about transparency in the subsurface if we
ignore it anyway. So this is a win-win.
We accept transparent subsurfaces for passthrough now, when they are
above the surface.
But we did not unset the opaque region to empty when the texture is
transprent.
That way, we can work with older libdrm versions.
The list was generated via a bit of sed and grep from the current
dmabuf-fourcc.h, which is why I put it into its own file and included
all the formats, no matter how old they are.
Add the matching GdkMemoryFormat for all dmabuf formats.
This way, we don't fall back to RGBA8 for 10- and 16-bit formats that we
don't support natively when EGL or Vulkan use them.
Also includes corrections for a few mixups.
Make this event behave like the other regular events, and emit
coordinates based on native surfaces. Fixes DnD over popovers
finding the correct coordinates.
This function takes an event, so the place(s) that do
not have one readily available can only pass NULL, so
the serial lookup will only work for the pointer.
Pass a device (plus optional sequence) to this function,
as these places do at least have the corresponding
GdkDevice at hand.
Fixes serial lookups for DnD, for other devices than
pointers (e.g. tablets, or touch).
Sadly, subsurface positioning is undefined in this case. We'll
trust the compositor to not mess up if the device coordinates
after applying the scale are integral, but otherwise, we'll
decline.
