| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3183
|
|
This will allow the DRM backend to reload its lessee list.
|
|
This change introduces new double buffered state to the wlr_output,
corresponding to the buffer format to render to.
The format being rendered to does not control the bit depth of colors
being sent to the display; it does generally determine the format with
which screenshot data is provided. The DRM backend _may_ sent higher
bit depths if the render format depth is increased, but hardware and
other limitations may apply.
|
|
|
|
|
|
Co-authored-by: Simon Zeni <simon@bl4ckb0ne.ca>
|
|
A wlroots user can easily get confused and think that `cap` refers to
wlroots buffer capabilities, not array capacity.
|
|
They are never used in practice, which makes all of our flag
handling effectively dead code. Also, APIs such as KMS don't
provide a good way to deal with the flags. Let's just fail the
DMA-BUF import when clients provide flags.
|
|
|
|
The protocol uses a signed integer here, which is also what the
wlr_input_method_v2_preedit_string struct provides to compositors from
the input method protocol. Sway currently just passes those int32_t
values directly to this function leading to an implicit conversion.
|
|
Callers can access output->front_buffer instead.
|
|
This struct contains additional information for session device
change events, such as the DRM connector ID that has changed.
|
|
This allows compositors to handle touch pointer emulation manually,
instead of having Xwayland do it [1].
[1]: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/691
|
|
The data field is useful to track metadata about a token. The destroy
events are useful for compositors that track application startup to
let them know they can stop doing that.
|
|
These new functions allow a compositor to request new managed tokens
without participating in the xdg-activation procedure as a wayland
client.
This enables the compositor itself to behave as a launcher
application.
|
|
Check if only a single node intersects with the output viewport
and all of its properties match. In this case, attempt direct
scan-out.
|
|
This allows compositors to more easily implement sending
wl_surface.frame callback done events.
|
|
|
|
|
|
This new renderer is implemented with the existing wlr_renderer API
(which is known to be sub-optimal for some operations). It's not
used by default, but users can opt-in by setting WLR_RENDERER=vulkan.
The renderer depends on VK_EXT_image_drm_format_modifier and
VK_EXT_physical_device_drm.
Co-authored-by: Simon Ser <contact@emersion.fr>
Co-authored-by: Jan Beich <jbeich@FreeBSD.org>
|
|
|
|
These are very common operations for compositors (including tinywl)
to perform.
|
|
Currently these functions remove the node from the scene if the sibling
argument is the same node as the node. To prevent confusion when
misusing this API, assert that the nodes are distinct and document this.
|
|
The same logic/motivation as xdg-toplevel.
|
|
|
|
These functions are used mostly for rendering, where including unmapped
surfaces is undesired.
This is a breaking change. However, few to no usages will have to be
updated.
|
|
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
|
|
Rename it to scheduled_serial for consistency with the rest of
wlroots.
|
|
This holds the current state, and avoids having ad-hoc fields in
wlr_xdg_surface.
|
|
struct wlr_xdg_surface_state is introduced to hold the geometry
and configure serial to be applied on next wl_surface.commit.
This commit fixes our handling for ack_configure: instead of making
the request mutate our current state, it mutates the pending state
only.
Co-authored-by: Simon Ser <contact@emersion.fr>
|
|
Update the pointer gestures protocol to version 3 allowing to send hold
gestures to clients.
|
|
Recevie the hold gesture events from the libinput or Wayland backends,
abstracted as pointer signals, and re-emit them from the cursor
interface.
|
|
As touchpad touches are generally fully abstracted, a client cannot
currently know when a user is interacting with the touchpad without
moving. This is solved by hold gestures.
Hold gestures are notifications about one or more fingers being held
down on the touchpad without significant movement.
Hold gestures are primarily designed for two interactions:
- Hold to interact: where a hold gesture is active for some time a
menu could pop up, some object could be selected, etc.
- Hold to cancel: where e.g. kinetic scrolling is currently active,
the start of a hold gesture can be used to stop the scroll.
Unlike swipe and pinch, hold gestures, by definition, do not have
movement, so there is no need for an "update" stage in the gesture.
Create two structs, wlr_event_pointer_hold_begin and
wlr_event_pointer_hold_end, to represent hold gesture events and the
signals to emit them: wlr_pointer->pointer.hold_begin/hold_end.
|
|
|
|
Same logic as xdg-toplevel.
|
|
|
|
|
|
|
|
Same as wlr_box_empty, but for wlr_fbox.
|
|
This new scene-graph node displays a wlr_buffer.
Closes: https://github.com/swaywm/wlroots/issues/3161
|
|
|
|
Expose the panel orientation with wlr_drm_connector_get_panel_orientation.
Leave it to the compositor to consume this information and configure the
output accordingly.
Closes: https://github.com/swaywm/wlroots/issues/1581
|
|
|
|
|
|
|
|
Previously, `wlr_xdg_toplevel` didn't follow the usual "current state +
pending state" pattern and instead had confusingly named
`client_pending` and `server_pending`. This commit removes them, and
instead introduces `wlr_xdg_toplevel.scheduled` to store the properties
that are yet to be sent to a client, and `wlr_xdg_toplevel.requested`
to store the properties that a client has requested. They have different
types to emphasize that they aren't actual states.
|
|
|
|
A launchee notifies with a "remove"¹ message when done starting up.
Catch these and forward to the compositor. This allows the compositor to
end the startup sequence that might have been started by another
protocol like xdg-activation.
We don't handle other messages since we expect the launcher to use a
wayland protocol like xdg-activation.
While `_NET_STARTUP_ID` helps to associate toplevels with startup-ids
this signals the end of the startup sequence.
1) https://specifications.freedesktop.org/startup-notification-spec/startup-notification-latest.txt
|
|
This allows callers to specify the operations they'll perform on
the returned data pointer. The motivations for this are:
- The upcoming Linux MAP_NOSIGBUS flag may only be usable on
read-only mappings.
- gbm_bo_map with GBM_BO_TRANSFER_READ hurts performance.
|
