This event contains a `committed` bitfield, which allows callers to know
which output fields changed during the commit.
This allows users to setup a single atomic commit listener, instead of
setting up one listener for each event (mode, scale, transform, and so
on).
References: https://github.com/swaywm/wlroots/issues/2098
These states are distinct in the time period between the ack_configure
and the next commit on the surface. Splitting these states avoids the
following race for example:
- client starts at 1000x1000
- wlr_xdg_toplevel_set_size 500x500
- size is different -> configure sent
- client acks the configure
- wlr_xdg_toplevel_set_size 1000x1000
- compare_xdg_toplevel_state returns true since there is no pending
configure and the currently committed size is still 1000x1000
- no new configure is sent
- client commits at the size it last acked, 500x500
The output backend API is now mostly state-less thanks to the atomic
hooks (commit and test). There is one exception though: attach_render.
This function makes the rendering context current. However sometimes the
compositor might decide not to render after attach_render (e.g. when
there's nothing new to render to the back buffer). Thus
wlr_output_rollback has been introduced to revert the pending state.
Because the output backend API is mostly state-less, the only thing
wlr_output_impl.rollback needs to do is revert the current rendering
context. Rename the function to rollback_render to make this clear. Add
a check in the common wlr_output code to only call rollback_render when
attach_buffer has been previously called.
On the long term, we'll be able to remove attach_render and
rollback_render together.
This is necessary for some grabs, which currently have no way of knowing
when the pointer/keyboard focus has left a surface. For example, without
this, a drag-and-drop grab can erroneously drop into a window that the
cursor is no longer over.
This is the plumbing needed to properly fix swaywm/sway#5220. The
existing fix, swaywm/sway#5222, relies on every grab's `enter()` hook
allowing a `NULL` surface. This is not guaranteed by the API and, in
fact, is not the case for the xdg-shell popup grab and results in a
crash when the cursor leaves a surface and does not immediately enter
another one while a popup is open (#2161).
This fix also adds an assertion to wlr_seat_pointer_notify_enter() that
ensures it's never called with a `NULL` surface. This will make Sway
crash much more until it fixes its usage of the API, so we should land
this at the same time as a fix in Sway (which I haven't posted yet).
I found the previous wording a bit confusing when I first read it.
Reword these comments to explicitly say that the grab-respecting
variants should be used in most cases.
This change has no functional effect.
These three APIs are very similar to one another, but they all had
slightly different function orderings. For consistency, always declare
the non_`notify` functions first, then the `notify` functions, then
`{start,end,has}_grab`.
This change has no functional effect.
This introduces the enter and leave events for wlr_keyboard_group.
The enter event is emitted when a keyboard is added to the group while a
key is pressed that is not pressed by any other keyboard in the group.
The data is a wl_array of the pressed key codes unique to the keyboard
that should now be considered pressed.
Similarly the leave event is emitted when a keyboard is removed from the
group while at least one key is pressed that is not pressed by any other
keyboard in the group. The data is a wl_array of the pressed key codes
unique to the keyboard that should now be considered released.
The purpose of these events are to allow the compositor to update its
state to avoid corruption. Additionally, for the leave event, the
focused surface may have been notified of a key press for some or all of
the key codes and needs to be notified of a key release to avoid state
corruption.
These were previously emitted as normal key events, but they are not
normal key events. There is no actual key press or release associated
with the events. It's purely for state keeping purposes. Emitting them
as separate events allows the compositor to handle them differently.
Since these are purely for state keeping purposes and are not associated
with an actual key being pressed or released, bindings should not be
triggered as a result of these events.
We should throw a protocol error if the relevant capability has never
existed when get_(pointer|keyboard|touch) is called. Otherwise, it
should succeed, even if the capability is not currently present.
This follows the spec, and avoids possible races with the client when
capabilities are lost.
Closes: https://github.com/swaywm/wlroots/issues/2227
This function can be called after wlr_egl_make_current to cleanup the
EGL context. This avoids having lingering EGL contexts that make things
work by chance.
Closes: https://github.com/swaywm/wlroots/issues/2197
This is currently inconsistent with the rest of the library and a bit of
a footgun for new compositors. However, this breaks the API in a very
unfortunate way for existing compositors.
This is necessary so that sway can determine when to start emulating
pointer events -- it shouldn't start doing so during an implicit grab,
even if the pen is over a surface that doesn't bind tablet input.
Refs swaywm/sway#5302.
This patch will make the EGL renderer work on any EGL/GLESv2 driver
providing the EGL_WL_bind_wayland_display extensions.
Mesa used to declare provisional EGL_WL_bind_wayland_display directly
in <EGL/eglext.h>. Then, all unofficial extensions were moved to
<EGL/eglmesaext.h>, to have a cleaner implementation. See:
ab7bb10a2a
The extension was then approved at Khronos Group, and reached the
official <EGL/eglext.h>. See:
https://www.khronos.org/registry/EGL/extensions/WL/EGL_WL_bind_wayland_display.txtaa9b63f3ab
In order to make sure the renderer will work on any version of any
implementation providing the extension, only include the mesa-specific
header if it's present.
Signed-off-by: Julien Olivain <juju@cotds.org>
Instead of requiring compositors to call wlr_texture_get_size each time
they want to access the texture's size, expose this information as
wlr_texture fields.
Most of the pending output state is not forwarded to the backend prior
to an output commit. For instance, wlr_output_set_mode just stashes the
mode without calling any wlr_output_impl function.
wlr_output_impl.commit is responsible for applying the pending mode.
However, there are exceptions to this rule. The first one is
wlr_output_attach_render. It won't go away before renderer v6 is
complete, because it needs to set the current EGL surface.
The second one is wlr_output_attach_buffer.
wlr_output_impl.attach_buffer is removed in [1].
When wlr_output_rollback is called, all pending state is supposed to be
cleared. This works for all the state except the two exceptions
mentionned above. To fix this, introduce wlr_output_impl.rollback.
Right now, the backend resets the current EGL surface. This prevents GL
commands from affecting the output after wlr_output_rollback.
This patch is required for FBO-based outputs to work properly. The
compositor might be using FBOs for its own purposes [2], having leftover
FBO state can have bad consequences.
[1]: https://github.com/swaywm/wlroots/pull/2097
[2]: https://github.com/swaywm/wlroots/pull/2063#issuecomment-597614312
Check that buffer can be scanned out in wlr_output_test instead of
wlr_output_attach_buffer. This allows the backend to have access to the
whole pending state when performing the check.
This brings the wlr_output API more in line with the KMS API.
This removes the need for wlr_output_attach_buffer to return a value,
and for wlr_output_impl.attach_buffer.
