This is worth doing despite wl_client_get_destroy_listener() incorrectly
accepting a mutable wl_client pointer since this lookup_client()
function will primarily be used with a wl_display_global_filter_func_t
which only provides a const wl_client pointer.
Work around this libwayland API wart in wlroots so compositors don't
have to.
I wish to use a allowlist of globals for my security context
implementation rather than a blocklist, which means I need access to
the wp_single_pixel_buffer_manager_v1 global in order to allowlist it.
I think using a allowlist will make it harder for me to accidentally
expose globals to a security context that were meant to be restricted.
I wish to use a allowlist of globals for my security context
implementation rather than a blocklist, which means I need access to
the ext_idle_notifier_v1 global in order to allowlist it.
I think using a allowlist will make it harder for me to accidentally
expose globals to a security context that were meant to be restricted.
I wish to use a allowlist of globals for my security context
implementation rather than a blocklist, which means I need access to
the wl_shm global in order to allowlist it.
I think using a allowlist will make it harder for me to accidentally
expose globals to a security context that were meant to be restricted.
This new helper assists compositors in allocating buffers for
modesets. It degrades to different allocation parameters as
needed, and should help with screens not turning on when multiple
outputs are connected on some hardware (e.g. Intel).
For simplicity, the old logic to try allocating with explicit
modifiers first and then fallback to implicit modifiers later is
left as-is. We'll probably want to have more complicated logic
instead in the future: try the fallback on one output at a time,
and try dropping modifiers one by one instead of using implicit
modifiers (at the cost of some combinatorial explosion).
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1873
Co-authored-by: Kenny Levinsen <kl@kl.wtf>
When a compositors submits a wlr_output_state with
WLR_OUTPUT_STATE_ADAPTIVE_SYNC_ENABLED set and
adaptive_sync_enabled = false on an output which doesn't support
adaptive sync, we'd fail the commit. Fix this.
This bug was previously hidden because wlr_output_commit() drops
no-op changes from wlr_output_state.committed.
After disabling a connector, we need to cleanup the connector to
teardown the surfaces and unlock the FBs.
Move this logic into drm_connector_apply_commit() so that it's
applied when drm_commit() is called from somewhere else than
drm_connector_commit_state().
There is some duplicated logic between these two functions.
The commit codepath was calling the test function before doing the
real commit, so this also saves an unnecessary test-only commit
when performing a real commit.
This centralizes logic common for both the atomic and libliftoff
backends. Additionally, a struct will make it easier to implement
multi-connector commits (since it can be stored in an array).
This allows us to remove the renderer destroy listener. The
listener was buggy: compositors can't destroy surface resources on
their own.
The wlr_compositor will always outlive the wlr_surface, so no need
for a destroy listener.
If we hit this case, we effectively failed to render something, this might
be because a texture failed to upload or the texture is momentarily
unavailable after a GPU reset. If we fail to render, we have to continue
to track damage for the next frame in hopes that the texture becomes
available then.
An alternative approach would be to fail the commit completely if we
find this case, but in the case of gpu resets, clients may not commit
a new buffer for a while, and a frozen display does not help.
This fixes damage tracking issues after a gpu reset.
The spec for GL_EXT_disjoint_timer_query says
> The GetInteger64vEXT command is required only if OpenGL ES 3.0 or later
> is not supported.
Some GLES 3.2 implementations like the proprietary mali driver on the
rk3566 based OrangePi advertise GL_EXT_disjoint_timer_query but lack
glGetInteger64vEXT. Use glGetInteger64v instead.
We will soon support custom swapchains. In order to track output damage
we should instead use the damage_ring which will hold all the buffers
we are currently tracking anyway across an arbitrary amount of swapchains.
We would fail to call scene_node_update() which would then call output
events for us. We need to make sure to update the node when we first map
a buffer, as the comment explained.
