Make it clear GLES2 is being used. Before this commit, various
GL-related information was printed, but not an easy-to-find line
about which renderer is being picked up.
This env var forces the creation of a specific renderer. If no renderer
is specified, the function will try to create all of the renderers one
by one until one is created successfuly.
It allocates in local main memory via shm_open, and provides a FD
to allow sharing with other processes.
This is suitable for software rendering under the Wayland and X11
backends.
The compositor shouldn't write to client buffers if the client
attaches a DMA-BUF to a wl_surface, then attaches a shm buffer.
Make gles2_texture_write_pixels return an error to prevent this
from happening.
The get_drm_fd was made available in an internal header with a53ab146f. Move it
now to the public header so consumers opting in to the unstable interfaces can
make use of it.
PRIME support for buffer sharing has become mandatory since the renderer
rewrite. Make sure we check for the appropriate capabilities in backend,
allocator and renderer.
See also #2819.
All backends use the GBM platform. We can't use it to figure out
whether the DRM backend is used anymore.
Let's just try to always request a high-priority EGL context. Failing
to do so is not fatal.
Split render/display setups have two separate devices: one display-only
with a primary node, and one render-only with a render node. However
in these cases the EGL implementation and the Wayland compositor will
advertise the display device instead of the render device [1]. The EGL
implementation will magically open the render device when the display
device is passed in.
So just pass the display device as if it were a render device. Maybe in
the future Mesa will advertise the render device instead and we'll be
able to remove this workaround.
[1]: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4178
Compute only the transform matrix in the output. The projection matrix
will be calculated inside the gles2 renderer when we start rendering.
The goal is to help the pixman rendering process.
Mesa provides YUV shaders, and can import multi-planar YUV DMA-BUFs
as a single EGLImage. Remove the arbitrary limitation.
If the driver doesn't support importing YUV as a single EGLImage,
the import will fail and the result will be the same anyways.
Clamping texture coordinates prevents OpenGL from blending the left and
right edge (or top and bottom edge) when scaling textures with GL_LINEAR
filtering. This prevents visual artifacts like swaywm/sway#5809.
Per discussion on IRC, this behaviour is made default. Compositors that want
the wrapping behaviour (e.g. for tiled patterns) can override this by doing:
struct wlr_gles2_texture_attribs attribs;
wlr_gles2_texture_get_attribs(texture, &attribs);
glBindTexture(attribs.target, attribs.tex);
glTexParameteri(attribs.target, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(attribs.target, GL_TEXTURE_WRAP_T, GL_REPEAT);
glBindTexture(attribs.target, 0);
As surfaces are no longer going to be used for wlr_egl, I may as well just go and add this check as it is needed for safety whenever surface-less rendering is being used.
The creation of `wlr_egl` will fail is the device extension
EGL_MESA_device_software is defined. The creation process is allowed to
continue only if the environment variable `WLR_RENDERER_ALLOW_SOFTWARE`
is defined to the value 1.
When gbm_bo_create is used and the GBM implementation does support
modifiers, gbm_bo_get_modifier may return something other than
DRM_FORMAT_MOD_INVALID. This can cause issues with the rest of the
stack (e.g. EGL or KMS) in case these don't support modifiers.
Instead, force the modifier to INVALID, to make sure no one uses
modifiers.
Instead of lazily exporting BOs to DMA-BUFs, do it on init. This is
the only way to use the buffer, so there's no point in deferring
that work.
This is preparatory work for the next commit.
The GBM device needs to be destroyed after the EGL display.
==50931==ERROR: AddressSanitizer: SEGV on unknown address 0x7fe40a000049 (pc 0x7fe446121d30 bp 0x60400001bbd0 sp 0x7ffc99c774d0 T0)
==50931==The signal is caused by a READ memory access.
#0 0x7fe446121d30 (/usr/lib/dri/radeonsi_dri.so+0x5f0d30)
#1 0x7fe4474717bd (/usr/lib/../lib/libEGL_mesa.so.0+0x177bd)
#2 0x7fe4474677d9 (/usr/lib/../lib/libEGL_mesa.so.0+0xd7d9)
#3 0x7fe44cca7b6f in wlr_egl_destroy ../subprojects/wlroots/render/egl.c:379
#4 0x7fe44ccc2626 in gles2_destroy ../subprojects/wlroots/render/gles2/renderer.c:705
#5 0x7fe44ccb5041 in wlr_renderer_destroy ../subprojects/wlroots/render/wlr_renderer.c:37
#6 0x7fe44cd17850 in backend_destroy ../subprojects/wlroots/backend/wayland/backend.c:296
#7 0x7fe44ccca4de in wlr_backend_destroy ../subprojects/wlroots/backend/backend.c:48
#8 0x7fe44cd11b21 in multi_backend_destroy ../subprojects/wlroots/backend/multi/backend.c:58
#9 0x7fe44cd125b0 in handle_display_destroy ../subprojects/wlroots/backend/multi/backend.c:125
#10 0x7fe44c315e0e (/usr/lib/libwayland-server.so.0+0x8e0e)
#11 0x7fe44c3165a6 in wl_display_destroy (/usr/lib/libwayland-server.so.0+0x95a6)
#12 0x55a2c8870683 in server_fini ../sway/server.c:203
#13 0x55a2c886cbf2 in main ../sway/main.c:436
#14 0x7fe44b77c151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
#15 0x55a2c883172d in _start (/home/simon/src/sway/build/sway/sway+0x33472d)
Instead of requiring callers to manually make the EGL context current
before binding a buffer and unsetting it after unbinding a buffer, do
it inside wlr_renderer_bind_buffer.
This hides renderer-specific implementation details inside the
wlr_renderer interface. Non-GLES2 renderers may not use EGL.
This removes all EGL dependencies from the backends.
References: https://github.com/swaywm/wlroots/issues/2618
References: https://github.com/swaywm/wlroots/pull/2615#issuecomment-756687006
It can be surprising and unexpected that texture operations (such as
texture upload and import) change the current EGL context, especially
when it's done under-the-hood by wlroots in response to wl_surface
requests.
To prevent surprises, save and restore the previous EGL context.
It can be surprising that destroying a buffer changes the EGL context,
especially since this can be triggered from anywhere wlr_buffer_unlock
is called.
Prevent this from happening by saving and restoring the EGL context.
Our wlr_format_set structs don't hold GBM usage flags. Instead, users
who want to get a LINEAR buffer can use the DRM_FORMAT_MOD_LINEAR
modifier even if the kernel driver doesn't support modifiers.
Add a special case to wlr_drm_format_intersect to properly handle this
situation.
In wlr_drm_format_dup, allocate the new wlr_drm_format using cap instead
of len. This makes it so the cap field is up-to-date and the chunk of
memory isn't too small if we append new modifiers (we don't allow this
yet but might in the future).
Rename wlr_renderer_get_dmabuf_formats to
wlr_renderer_get_dmabuf_texture_formats. This makes it clear the formats
are only suitable for creating wlr_textures.
On some setups (e.g. remote access via SSH) the current user won't have
the permission to open the primary node at all. It's still possible to
use drmGetDevices to match the primary node name returned by EGL.
Closes: https://github.com/swaywm/wlroots/issues/2488
The swapchain maximum capacity is set to 4, so that we have enough room
for:
- A buffer currently displayed on screen
- A buffer queued for display (e.g. to KMS)
- A pending buffer that'll be queued next commit
- An additional pending buffer in case we want to invalidate the
currently pending one
Don't force compositors to check when an empty shape is being renderered.
References #2282. This was motivated by dwl crashing when setting window
borders to 0 (djpohly/dwl#51).
Simon Ser
Simon Zeni
nyorain
ayaka
Roman Gilg
Stephan Hilb
zccrs
Quantum
Brandon Dowdy
Ilia Bozhinov
Ronan Pigott
Isaac Freund
Guido Cella