INVALID means that the modifier is implicit. However dumb buffers
are guaranteed to be LINEAR, so let's just advertise this. Fixes
cursors with the DRM backend: cursor planes usually only support
LINEAR.
When running with the DRM backend, the Pixman renderer needs to
render the cursor buffer. However, DRM drivers only support linear
buffers for these in general, they don't support implicit modifiers
(aka. INVALID).
Advertise support for LINEAR in the Pixman renderer to fix this.
If we have a render node, it means there is a GPU which could be
used. We probably failed GL because of a kernel or Mesa issue.
Instead of automatically falling back to Pixman, error out.
This makes it more obvious to users when something goes wrong,
instead of silently exposing a slow unaccelerated desktop.
References: https://github.com/swaywm/sway/issues/7194
The Vulkan renderer is still experimental. If GL fails, we don't
want to automatically fall back to it by default.
Fixes: 8bd7170fd9 ("Use env helpers")
See the spec at [1]. tl;dr EGL has terrible defaults: eglTerminate()
may have side-effects on completely unrelated EGLDisplay objects.
This extension allows us to opt-in to get the sane behavior:
eglTerminate() only free's our own EGLDisplay without affecting
others.
[1]: https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_display_reference.txt
We were checking whether any of the features was supported. We need
to check if all of them are.
This makes the check consistent with query_modifier_support() above.
I think the second parameter of the function should be void* instead of
void **, because we use it as a right value in the function.
Signed-off-by: fakechen <chenzigui@kylinos.cn>
Signed-off-by: sunzg <sunzhigang1@kylinos.cn>
From a comment by emersion:
> There is a logic error here: we pass 0xFFFFFFFF to vulkan_find_mem_type, which
> returns an index, and then we logical-and that with mem_reqs.memoryTypeBits.
> Instead we should pass mem_reqs.memoryTypeBits to vulkan_find_mem_type and use
> the result for the memoryTypeIndex field directly. Ideally checking for errors
> (-1 return value) in case no memory type is suitable.
Closes: #3470
This lets the renderer handle the wlr_buffer directly, just like it
does in texture_from_buffer. This also allows the renderer to batch
the rectangle updates, and update more than the damage region if
desirable (e.g. too many rects), so can be more efficient.
GL_ALPHA_BITS is the number of bits of the alpha channel of the
currently bound frame buffer's color buffer -- which is precisely
renderer->current_buffer->rbo . Thus, instead of binding the color
buffer and checking its properties, we can query the already bound
frame buffer.
Note that GL_IMPLEMENTATION_COLOR_READ_{FORMAT,TYPE} are also
properties of frame buffer's color buffer.
Instead of checking whether the wlr_egl dependencies are available
in the GLES2 code, introduce internal_features['egl'] and check
that field.
When updating the EGL dependency list, we no longer need to update
the GLES2 logic.
Whether a texture is opaque or not doesn't depend on the renderer
at all, it just depends on the source buffer. Instead of forcing
all renderers to implement wlr_texture_impl.is_opaque, let's move
this in common code and use the wlr_buffer format to know whether
a texture will be opaque.
`vulkan_format_props_query` calls `query_modifier_support` which
initializes fields of `props` with allocated memory. this memory is
leaked if `query_modifier_support` does not find a supported format
and shmtex is not supported, as in this case `add_fmt_props` ends
up being false and the allocated fields of `props` are never freed.
Replace them with wlr_signal_emit_safe, which correctly handles
cases where a listener removes another listener.
Reported-by: Isaac Freund <ifreund@ifreund.xyz>
Now that the DRM backend no longer depends on GBM, we can make it
optional. The GLES2 renderer still depends on it because of our EGL
device selection.
This is useful for compositors with their own renderers, and for
compositors using the Vulkan renderer.
These formats require EXT_texture_norm16, which in turn needs OpenGL
ES 3.1. The EXT_texture_norm16 extension does not support passing
gl_internalformat = GL_RGBA to glTexImage2D, as can be done for
formats available in OpenGL ES 2.0, so this commit adds a field to
wlr_gles2_pixel_format to provide a more specific internalformat
parameter to glTexImage2D.
This removes an artificial limitation in form of an assert that disallowed the
creation of textures while the renderer is rendering.
A consumer might run its own rendering pipeline and after start of the renderer
still want to create textures for internal usage.
commit 44e8451cd9 ("render/gles2: hide shm formats without GL
support") added the is_gles2_pixel_format_supported() function to
render/gles2/pixel_format.c, whose stated purpose is to "check whether
the renderer has the needed GL extensions to read a given pixel format."
It then used that function to filter the pixel formats returned by
get_gles2_shm_formats().
The result of this change is that RGB formats are no longer reported for
GL drivers that don't implement EXT_read_format_bgra, even when those
formats are supported for rendering (which they have to be for
wlr_gles2_renderer_create() to succeed). This is a pretty clear
regression, since wlr_renderer_init_wl_shm() fails when either of
WL_SHM_FORMAT_ARGB8888 or WL_SHM_FORMAT_XRGB8888 are missing.
To fix the regression, change is_gles2_pixel_format_supported() to
accept all pixel formats that support rendering, regardless of whether
we can read them or not, and move the check for EXT_read_format_bgra
back into gles2_read_pixels(). (There's already a check for this
extension in gles2_preferred_read_format(), so we're not breaking any
abstraction that wasn't already broken.)
Tested on the NVIDIA 495.46 proprietary driver, which doesn't support
EXT_read_format_bgra.
Fixes: 44e8451cd9 ("render/gles2: hide shm formats without GL support")
This intersects two DRM format sets. This is useful for implementing
DMA-BUF feedback in compositors, see e.g. the Sway PR [1].
[1]: https://github.com/swaywm/sway/pull/6313
