The wlroots APIs currently don't allow importing/uploading a buffer
during rendering operations. Scene-graph buffer nodes need to turn
their wlr_buffer into a wlr_texture at some point. It's not always
possible to do so at wlr_scene_buffer creation time because the
scene-graph may have zero outputs at this point, thus no way to
grab a wlr_renderer.
Instead, add scene-graph buffers to a pending list and try to import
them in wlr_scene_output_commit.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3354
Commit 498f30aad1 changed the logic of
get_mapping() in types/wlr_cursor.c to use updated version of
wlr_output_layout_get_box(). However, the case where c_device isn't NULL
but doesn't have output or geometry mappings wasn't handled properly,
resulting in leaving the output value uninitialized. This commit fixes
`c_device != NULL` branch by returning from the function only when a
mapping is found.
Fixes https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3369
wl_subsurface::set_desync description states: "If cached state exists when
wl_surface.commit is called in desynchronized mode, the pending state is
added to the cached state, and applied as a whole."
This commit reintroduces an implementation of said behavior, previously
removed in 7daf6da9ac05be2cb74c0983e3caee0b21db75d4.
Strictly speaking, this logic isn't fully correct, as the cached state
and the pending state are applied individually instead, if the cached
state isn't locked by anything else. However, the end result is still
the same.
This commit fixes the issue with Firefox permission popups.
wp_viewporter protocol doesn't seem to say anything about damage, but
Firefox assumes that wp_viewport::set_source alone is enough to damage
the whole surface, and that assumption kinda makes sense, so let's do
that.
Currently the output enter event is never sent if the client has not
yet bound the output, which happens every time the compositor creates a
new output.
To fix this, listen for the output bind event and inform clients as
if needed.
wlroots has historically been started as a Sway project, but these
days many wlroots contributors are working on other compositors.
wlroots now also has its own namespace on gitlab.freedesktop.org.
Let's remove the mention about Sway in the README, to make it clearer
that Sway isn't treated in a special manner when it comes to wlroots
development.
This commit renames map/unmap listeners to clarify that they handle
subsurface events, and ensures the node is always destroyed before
the subsurface.
Without this patch, wl_list_remove() would operate on listener links in
already freed memory. glibc is usually lenient to bugs like this, but
musl isn't.
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")
The libinput backend is now optional. However, this means that a
user building wlroots without the correct libinput dependencies
will end up with a compositor which doesn't respond to input events.
wlr_backend_autocreate is supposed to return a sensible setup, so in
this case let's just error out and explain what happened. Users can
suppress the check by setting WLR_LIBINPUT_NO_DEVICES=1 (already used
to suppress the zero input device case inside the libinput backend).
Compositors which really want to create a bare DRM backend can easily
create it manually instead of using wlr_backend_autocreate.
This patch makes it so we bind to zwp_linux_dmabuf_v1 version 4 and
we use it to grab the main device. v4 sends supported formats via a
table so we need to handle this as well.
v4 allows wlroots to remove the requirement for Mesa's internal
wl_drm interface.
Allows the compositor to submit tokens to the pool of
currently active tokens. This can be useful when the
launcher doesn't use or support xdg-activation-v1 by
itself - e.g. when it is X11 based or use gtk_shell1.
This doesn't work if scene outputs are not used as the primary output of
scene surfaces will always be NULL.
Therefore, take a wlr_scene_output instead of separate wlr_scene and
wlr_output arguments and rename the function to
wlr_scene_output_send_frame_done().
The actual behavior of the function is unchanged.
This allows compositors to avoid sending multiple frame done events
to a surface that is rendered on multiple outputs at once. This may
also be used in the same way for presentation feedback.
