Certain clients require this property to be set for expected behavior.
Most notably, steam client CSD maximize button no longer worked
after unmaximizing once, unless the state was changed by another
method. The state is unset whenever another surface gains focus.
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 commit makes `get_current_time_msec` correctly return milliseconds
as opposed to microseconds. It also considers the value of `tv_sec`, so
we don't lose occasionally go back in time by one second. Finally, the
function is moved into `util/time.cc` so that it can be reused elsewhere
without having to consider these pitfalls.
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
Previously, we only had the pending state (crtc->pending, crtc->mode and
crtc->active). This causes issues when a commit fails: the pending state
is left as-is, and the next commit may read stale data from it.
This will also cause issues when implementing test-only commits: we need
to rollback the pending CRTC state after a test-only commit.
Introduce separate pending and current CRTC states. Properly update the
current state after a commit.
retry_pageflip is now dead code, since drm_connector_start_renderer
isn't called anymore. It was previously called when enabling an output.
The name "retry_pageflip" was a little confusing because the function
retried a modeset and the timer wasn't set up while performing a simple
page-flip.
Let's just remove this altogether for now. We can discuss whether it's
worth it to bring it back. Should we only do it on failed page-flips?
Should we only do it on EBUSY?
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.
