This is simply a false sense of security, and is worse than just using
setuid. CAP_SYS_ADMIN is an extremely serious capability that is
effectively as powerful as root.
It also required users to be in the input group, which allows any
process to keylog the entire system.
Some primary planes don't support ARGB8888, they only support XRGB8888
(for instance on older Intel hardware). The DRM backend would fail to
initialize.
When that's the case, try to allocate buffers without an alpha channel.
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>
This commit doesn't fix any issue that I'm aware of, since sway
incidentally does not use these fields. Still, they exist, so they
should probably be filled in to prevent fun surprises in the future.
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).
The logind provider defaulted to systemd and in order to use elogind,
-Dlogin-provider=elogind was required. This adds 'auto' as a choice
for the login-provider option and sets it as default. Using 'auto',
the build will check for systemd first and if it's not found, try
to find and use elogind automatically.
Previously, each time a wl_seat.capabilities event was received the
Wayland backend created new input devices. It now only does so the first
time.
Input devices are now destroyed when the cap is removed.
Closes: https://github.com/swaywm/sway/issues/5055
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 previous PR was overzealous in adding a finish_drm_surface call
which was also done by the caller. Remove the call and also move the
comment to the correct code location.
In some cases modesets fail if the planes are initialized with
modifiers. Since in this case possibly all planes need to reinitialized,
which is not possible in the current wlroots design, add an environment
variable for affected users.
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.
This fixes a segfault in drm_connector_set_mode (mode = NULL).
This happens because we set wlr_output.enabled to true if the connector
is attached to the CRTC. When the user disables an output in the
wlroots-based compositor, switches to another VT (enabling the output),
then switches back, wlroots sets wlr_output.enabled to true but
wlr_output.current_mode is NULL.
We should consider not reading properties from KMS after a TTY switch,
disabling all connectors. However this may result in flickering (outputs
being disabled then re-enabled).
Closes: https://github.com/swaywm/wlroots/issues/1874
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
Previously, the path of TTY is generated using snprintf with %d format.
It works with TTY 1 to 10, but fails with TTY with greater number
because the number used in the name is in base 32 instead of base 10.
Since there is no standard function to convert a number to a string with
a custom base, this commit adds a function to do it.
Fixes: https://github.com/swaywm/wlroots/issues/1854
Remove glapi.sh code generation, replace it with hand-written loading
code that checks extension strings before calling eglGetProcAddress.
The GLES2 renderer still uses global state because of:
- {PUSH,POP}_GLES2_DEBUG macros
- wlr_gles2_texture_from_* taking a wlr_egl instead of the renderer
