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
Previously, an error on the remote Wayland display would result in an
infinite loop priting:
2020-01-09 13:39:03 - [wayland] Source dispatch function returned negative value!
2020-01-09 13:39:03 - [wayland] This would previously accidentally suppress a follow-up dispatch
This happens when the remote compositor disconnects the client because
of a protocol error, for instance.
Handle wl_display_dispatch and wl_display_dispatch_pending returning -1
by terminating the local display and printing an error.
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.
wlr_output.description is a string containing a human-readable string
identifying the output. Compositors can customise it via
wlr_output_set_description, for instance to make the name more
user-friendly.
References: https://github.com/swaywm/wlroots/issues/1623
Bumps minimum version to 0.51.0
- Remove all intermediate static libraries.
They serve no purpose and are just add a bunch of boilerplate for
managing dependencies and options. It's now managed as a list of
files which are compiled into libwlroots directly.
- Use install_subdir instead of installing headers individually.
I've changed my mind since I did that. Listing them out is annoying as
hell, and it's easy to forget to do it.
- Add not_found_message for all of our optional dependencies that have a
meson option. It gives some hints about what option to pass and what
the optional dependency is for.
- Move all backend subdirectories into their own meson.build. This
keeps some of the backend-specific build logic (especially rdp and
session) more neatly separated off.
- Don't overlink example clients with code they're not using.
This was done by merging the protocol dictionaries and setting some
variables containing the code and client header file.
Example clients now explicitly mention what extension protocols they
want to link to.
- Split compositor example logic from client example logic.
- Minor formatting changes
This requires functions without a prototype definition to be static.
This allows to detect dead code, export less symbols and put shared
functions in headers.
Expose the remote wl_display, wl_surface and wl_seat used by the Wayland
backend.
This allows compositors to customize the Wayland backend and to have
more freedom. For instance a compositor might want to handle clipboard
and drag-and-drop from the remote Wayland compositor. Another compositor
might want to setup pointer constraints.
We just send relative motion events alongside absolute motion events.
Compositors can figure out how absolute and relative events are related
(e.g. whether they have been triggered by the same logical event) with
the frame event.
This allows wlroots based compositors to properly use graphic tablets
with the wayland backend.
This should be a decent quality of life improvement when working on
tablet related features.
This commit makes more output properties (mode, enabled, scale and transform)
atomic. This means that they are double-buffered and only applied on commit.
Compositors now need to call wlr_output_commit after setting any of those
properties.
Internally, backends still apply properties sequentially. The behaviour should
be exactly the same as before. Future commits will update some backends to take
advantage of the atomic interface. Some backends are non-atomic by design, e.g.
the X11 backend or the legacy DRM backend.
Updates: https://github.com/swaywm/wlroots/issues/1640
The documentation for wayland-server.h says:
> Use of this header file is discouraged. Prefer including
> wayland-server-core.h instead, which does not include the server protocol
> header and as such only defines the library PI, excluding the deprecated API
> below.
Replacing wayland-server.h with wayland-server-core.h allows us to drop the
WL_HIDE_DEPRECATED declaration.
The backend doesn't need to handle transform changes, since everything is done
in software. In fact, all of the implementations were all identical and just
set the transform.
We could add support for hardware transforms, but:
- This would require a different field (something like hardware_transform)
- Not all combinations are possible because there often are hardware
limitations
- The Wayland protocol isn't ready for this (in particular xdg-output, see [1])
This belongs to a different patch series anyway.
[1]: https://patchwork.freedesktop.org/series/52324/
This updates the backend part of the output API. This is mostly renaming:
make_current becomes attach_render and swap_buffers becomes commit.
This also fixes the RDP backend to support NULL damage.
The deleted includes are redundant, because other headers will include
the necessary files. Additionally, they cause build failures, because
including EGL/egl.h or EGL/eglext.h directly, instead of through
wlr/render/egl.h or wlr/render/interface.h, will mean that
MESA_EGL_NO_X11_HEADERS will not have been defined, and so the EGL
headers will attempt to pull in unnecessary X11 headers that may not
exist on the system.
For the headers produced by glgen.sh, the includes couldn't simply be
deleted, because no other header would include the EGL headers. Neither
wlr/render/egl.h or wlr/render/interface.h felt appropriate to include,
so I opted instead to copy the MESA_EGL_NO_X11_HEADERS definition before
the EGL includes.
backend/headless/output.c:132:3: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
++backend->last_output_num);
^~~~~~~~~~~~~~~~~~~~~~~~~~
backend/noop/output.c:72:3: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
++backend->last_output_num);
^~~~~~~~~~~~~~~~~~~~~~~~~~
backend/wayland/output.c:294:3: error: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
++backend->last_output_num);
^~~~~~~~~~~~~~~~~~~~~~~~~~
backend/x11/output.c:150:3: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
++x11->last_output_num);
^~~~~~~~~~~~~~~~~~~~~~
This improves the way the output numbers are handled for the wayland
backend. Instead of using the number of active outputs plus one, the
last used number is stored and new outputs will increment it. This
fixes the situation where you start with one output, create a second,
close the first, and create a third. Without this, both outputs will be
`WL-2`, which causes an issue since the identifier will also be
identical. With this, the last output is `WL-3` and the outputs can be
distinguished.
Frame events group logically connected pointer events. It makes sense to make
the backend responsible for sending frame events, since once the events are
split (ie. once the frame events are stripped) it's not easy to figure out
which events belongs to which frame again.
This is also how Weston handles frame events.
Fixes https://github.com/swaywm/wlroots/issues/1468
Set the default "wlroots - " title when the title argument to the
set_title functions is NULL. Otherwise, for at least the Wayland
backend, we'd crash because xdg_toplevel_set_title doesn't handle a NULL
pointer.
The renderer redesign is going to need the render fd before the backend
is fully started, so we have to move the wl registry code to when the
backend is created instead of when it is started.
We also need to stash the wl_keyboard and emit it to library users
later, once they've added their listeners and started the backend.
There was a missing copy_drm_surface_mgpu call in drm_connector_schedule_frame
so we asked for a pageflip with an unknown BO, resulting in ENOENT.
Additionally, this commit makes schedule_frame return a bool indicating
failures. This allows schedule_frame_handle_idle_timer to only set
frame_pending to true if a frame has been successfully scheduled. Thus, if a
pageflip fails, rendering won't be blocked forever anymore.
In case a pageflip is already pending, true is returned because a frame has
already been scheduled and will be sent sometime soon.
This desynchronizes our rendering loop with the vblank cycle.
In case a compositor doesn't swap buffers but schedules a frame,
emitting a frame event immediately enters a busy-loop.
Instead, ask the backend to send a frame when appropriate. On
Wayland we can just register a frame callback on our surface. On
DRM we can do a no-op pageflip.
Fixes#617Fixesswaywm/sway#2748