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
Every host seat with pointer capability propagates events to one of
sub-pointer depending which output window we entered.
active_pointer tracks reference to sub-pointer on enter/leave events to
avoid lookup for it on every move events.
Fixesswaywm/wlroots#1499
We were previously exporting DMA-BUFs when receiving the capture_output
request, and sending a done event on wlr_output.events.precommit. Instead,
export and send done on wlr_output.events.commit.
The resource field of wlr_xdg_positioner is never initialized or
accessed within wlroots. The wl_resource for this interface is stored
in the wlr_xdg_positioner_resource struct.
This brings the layer-shell api in line with that of xdg-shell and
avoids reimplementing this function in every compositor in order to
render layer shell popups correctly.
This type is meant to be 4 bytes large as seen in _XcursorReadUInt which
always reads 4 bytes. An unsigned int is often 4 bytes large but this
isnt' guaranteed so it is cleaner to use the exact type we want.
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
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.
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>
We don't need a per-CRTC atomic request anymore. Let's make the request
per-commit so that it's easier to debug.
This is also groundwork for supporting wlr_output_test properly.
GAMMA_LUT_SIZE isn't an atomic property. It can be used with the legacy
interface too. So we can unify both codepaths and remove
wlr_drm_interface.crtc_get_gamma_size.
It's no guaranteed to exist though, so we still need to keep the
fallback.
When the headless backend uses an already-existing renderer, it doesn't
have ownership over the renderer. When the renderer is destroyed, the
headless backend needs to destroy itself.
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.
This is a type which manages gbm_surfaces and imported dmabufs in the
same place, and makes the lifetime management between the two shared. It
should lead to easier to understand code, and fewer special cases.
This also contains a fair bit of refactoring to start using this new
type.
Co-authored-by: Simon Ser <contact@emersion.fr>
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.
Consumers call wlr_buffer_lock. Once all consumers are done with the
buffer, only the producer should have a reference to the buffer. In this
case, we can release the buffer (and let the producer re-use it).
This makes it easier for the user of this library to properly handle
failure of this function.
The signature of wlr_renderer_impl.init_wl_display was also modified to
allow for proper error propagation.
This patch disambiguates the needs_frame event by uncoupling it from
damage. A new separate damage event is emitted when the backend damages
the output (this happens e.g. VT is changed or software cursors are
used). The event specifies the damaged region.
The wlr_output.damage field is removed. wlr_output is no longer
responsible for tracking its own damage, this is wlr_output_damage's
job.
This is a breaking change, but wlr_output_damage users shouldn't need an
update.
Bugs fixed:
- Screen flashes on VT switch
- Cursor damage issues on the X11 and headless backends
Closes: https://github.com/swaywm/sway/issues/5086
Previously, some atoms had a leading underscore, others didn't. Be more
consistent and never use a leading underscore (symbols with a leading
underscore followed by an upper-case letter are reserved).
Split out the client/resource handling out of wlr_buffer by introducing
wlr_client_buffer. Make wlr_buffer an interface so that compositors can
create their own wlr_buffers (e.g. backed by GBM, like glider [1]).
[1]: c66847dd1c/include/gbm_allocator.h (L7)
This function allowed backends to provide a custom function for frame
scheduling. Before resuming the rendering loop, the DRM and Wayland
backends would wait for vsync.
There isn't a clear benefit of doing this. The only upside is that we
get more stable timings: the delay between two repaints doesn't change too
much and is close to a mutliple of the refresh rate.
However this introduces latency, especially when a client misses a
frame. For instance a fullscreen game missing vblank will need to wait
more than a whole frame before being able to display new content. This
worst case scenario happens as follows:
- Client is still rendering its frame and cannot submit it in time
- Deadline is reached
- Compositor decides to stop the rendering loop since nothing changed on
screen
- Client finally manages to render its frame, submits it
- Compositor calls wlr_output_schedule_frame
- DRM backend waits for next vblank
- The wlr_output frame event is fired, compositor draws new content on screen
- On the second next vblank, the new content reaches the screen
With this patch, the wlr_output frame event is fired immediately when
the client submits its late frame.
This change also makes it easier to support variable refresh rate, since
VRR is all about being able to present too-late frames earlier.
References: https://github.com/swaywm/wlroots/issues/1925
The keyboard shortcuts inhibitor protocol is useful for remote desktop
and virtualization software in order to request all keyboard events to
be passed to it and (almost) none being resonded to by the compositor.
This allows the session at the other end of the remote desktop
connection or inside the virtual machine to be interacted with as usual
(e.g. Alt+Tab to switch windows on the remote system instead of
locally).
Add the wayland protocol to the meson build files.
Copy'n'search'n'replace the very similar idle inhibit protocol
implementation. This already provides all the basic functionality:
- creating and destroying inhibitors upon request by a client,
- destruction in reaction to destruction of surfaces or displays,
- a list of inhibitors to search through for existing ones as well as
- a signal to be sent to the compositor upon registration of a new
inhibitor.
Beyond that we add the active and inactive events to be sent to the
client and wire those to activate and deactivate functions for the
compositor to call in confirmation of activation of a new inhibitor or
(un-)suspending of an existing inhibitor e.g. in response to a special
key combination entered by the user as suggested by the protocol.
As mandated by the protocol, we check the existance of an inhibitor for
a given surface and seat upon creation and return the error provided by
the protocol for that purpose.
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Closes: https://github.com/swaywm/wlroots/issues/1817
Previously, if the current configuration contains an output X which is
destroyed, its head is automatically removed. If the compositor submits
the new configuration after X was removed, the current output
configuration is incorrectly detected to be the same as the previous
one, and no done event is sent. To prevent this, we can just keep track
of whether the current configuration is dirty, i.e whether we have sent
a done event for it.
Previously, we just assumed submitting a new frame would make the
compositor release the current one. This isn't always the case, for
instance Sway retains old buffers when a transaction is pending. This
resulted in synchronization issues with clients writing in
front-buffers.
Fix this by un-referencing a wlr_buffer when the parent compositor sends
wl_buffer.release.
Tested by running a fullscreen mpv instance in Sway with the Wayland
backend.
