wayland-protocols merge requestshttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests2024-03-20T10:39:30Zhttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/287staging: add alpha-modifier protocol2024-03-20T10:39:30ZXaver Huglstaging: add alpha-modifier protocolThis protocol allows clients to set an alpha multiplier for the whole surface,
which allows it to offload alpha changes for the whole surface to the compositor,
which in turn can offload them to KMS.
Signed-off-by: Xaver Hugl <xaver.hug...This protocol allows clients to set an alpha multiplier for the whole surface,
which allows it to offload alpha changes for the whole surface to the compositor,
which in turn can offload them to KMS.
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
TODO:
- [x] Review (@emersion)
- [ ] 3 ACKs
- wlroots (@emersion)
- KDE (@zzag)
- TBD
- [x] 3 implementations
- KWin: https://invent.kde.org/plasma/kwin/-/merge_requests/5462
- wlroots: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4616
- gamescope client: https://github.com/ValveSoftware/gamescope/tree/alpha-modifierhttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/256fifo-v1: Add new protocol2024-03-29T10:39:32ZDerek Foremanfifo-v1: Add new protocolIn order to implement advanced presentation modes, such as FIFO under Vulkan, the compositor needs to maintain a queue of state. This is an attempt to expose such a queue to clients.
~~To be useful, timestamp information must also be pr...In order to implement advanced presentation modes, such as FIFO under Vulkan, the compositor needs to maintain a queue of state. This is an attempt to expose such a queue to clients.
~~To be useful, timestamp information must also be present (such as that provided by a protocol like !248)~~https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/248commit-timing-v1: Add new protocol2024-03-18T21:01:56ZDerek Foremancommit-timing-v1: Add new protocolAnother attempt at a protocol for adding presentation time information at commit time.
Previous work exists at !45 and !103 and perhaps elsewhere, but progress on those has been stalled for months to years.
I'm hoping we can move forwa...Another attempt at a protocol for adding presentation time information at commit time.
Previous work exists at !45 and !103 and perhaps elsewhere, but progress on those has been stalled for months to years.
I'm hoping we can move forward with a much smaller protocol (no feedback here, I'm hoping that can be added to the existing presentation feedback protocol, perhaps with the work in !199)
I'm also hoping things like "slop" or "duration" which exist in other proposals could be added to this protocol eventually, but really want to start this as just a simple "trigger this commit no sooner than" request - which I think is useful on its own.
(in that regard, is adding "vsync hints" a step too far?)Derek ForemanDerek Foremanhttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/244game-controller-v1: new protocol2024-03-20T08:25:24ZSimon Zenisimon@bl4ckb0ne.cagame-controller-v1: new protocolThis protocol is inspited by OpenXR input device API [1]. It defines a new input device, representing a game controller, that sends events to a client and takes request to apply a haptic vibration.
[1]: https://registry.khronos.org/Open...This protocol is inspited by OpenXR input device API [1]. It defines a new input device, representing a game controller, that sends events to a client and takes request to apply a haptic vibration.
[1]: https://registry.khronos.org/OpenXR/specs/1.0/html/xrspec.html#input
#### Requirements for merging
- [ ] Review
- [ ] 3 ACKs from members
- [ ] 3 Implementationshttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/231Add staging system bell protocol2024-03-28T14:48:29ZJonas ÅdahlAdd staging system bell protocolThis is meant to let applications ring the system bell. It needs to be a
Wayland protocol because a system bell is not necessarily audiable; for
for example accessibility reasons, it might need be a visual feedback,
which may be tied to ...This is meant to let applications ring the system bell. It needs to be a
Wayland protocol because a system bell is not necessarily audiable; for
for example accessibility reasons, it might need be a visual feedback,
which may be tied to a specific window. Accessibility features are
usually configured globally, and one likely wants identical visual
feedback for all system bell ringings, so it doesn't fit as a client
side only feature.
This aims to replaced and deprecate the `gtk_shell1.system_bell`
request.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
-----
Copyright starts at 2016 because I'm found a draft from back then.
- Review:
- [ ] N\A
- Acks:
- [ ] N\A
- [ ] N\A
- [ ] N\A
- Implementations:
- [x] Qt: https://codereview.qt-project.org/c/qt/qtwayland/+/489843
- [x] GTK: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7080
- [x] Mutter: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3675https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/229staging/wm-gestures: Add WM "gestures" protocol2024-02-02T16:35:12ZCarlos Garnachostaging/wm-gestures: Add WM "gestures" protocolThis is a high-level protocol to let compositors attach window
management logic to certain gestures or actions happening on a
toplevel.
#### Requirements for merging
- [ ] Review
- [ ] Implementations
- https://gitlab.gnome.org/GNOME...This is a high-level protocol to let compositors attach window
management logic to certain gestures or actions happening on a
toplevel.
#### Requirements for merging
- [ ] Review
- [ ] Implementations
- https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3558
- https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6838
- [ ] ACKs from membershttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/211ext-virtual-keyboard: new protocol2023-05-10T12:38:31ZSimon Sercontact@emersion.frext-virtual-keyboard: new protocolThis protocol can be used by remote desktop and on-screen keyboard
clients to trigger synthetic keyboard events. A very similar version
of this protocol is widely used by wlroots compositors.
Supersedes https://gitlab.freedesktop.org/wa...This protocol can be used by remote desktop and on-screen keyboard
clients to trigger synthetic keyboard events. A very similar version
of this protocol is widely used by wlroots compositors.
Supersedes https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/11
#### Requirements for merging
- [ ] Review
- [ ] 2 implementations
- [ ] 2 ACKs from membershttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/199Draft: staging: add refresh cycle protocol2024-01-22T19:32:45ZSebastian WickDraft: staging: add refresh cycle protocolFiguring out when to start producing new frames and when those frames become visible with the current framework is impossible:
The frame callback mechanism is not suitable because
* can occur at arbitrary times in the refresh cycle
* ca...Figuring out when to start producing new frames and when those frames become visible with the current framework is impossible:
The frame callback mechanism is not suitable because
* can occur at arbitrary times in the refresh cycle
* can be moved around in response to client timings to try to minimze latency
* can not be send at all
The presentation time mechanism is not suitable because
* it is only send in response to a commit and not for every refresh cycle
* it is send some time after the latching event
Using the frame callback mechanism together with presentation time also doesn't work reliably. The variable nature of the frame callback might increase the number of refresh cycles to present arbitrarily. Any increase or decrease in the work a client does might result in missing the latching deadline and increase the number of refresh cycles to present. There is no indication this happened and no measurement can be taken to prevent it.
This protocol tries to solve those issues by explicitly communicating the refresh cycles, the latching event, fixed and variable refresh rates and the absence of refresh cycles.
It also allows improvements to the Vulkan WSI such as a proper implementation of `VK_KHR_present_wait`, partial implementation of `VK_EXT_present_timing` and suspending swapchains (!99).
The throttle hint and the VRR parts are not thought out very well.
The implementation in compositors should be rather easy because all information should already exist in some form.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/193Add blender protocol2024-03-06T12:22:35ZSimon Sercontact@emersion.frAdd blender protocolThis protocol specifies a set of interfaces used to control the alpha
compositing and blending of surface contents, based on a Chromium
Wayland protocol [1]. A previous attempt is available at [2]. The blend
equations have been reduced t...This protocol specifies a set of interfaces used to control the alpha
compositing and blending of surface contents, based on a Chromium
Wayland protocol [1]. A previous attempt is available at [2]. The blend
equations have been reduced to KMS' "pixel blend mode" property [3], and
compositors exposing this protocol are required to support all of them
for simplicity.
[1]: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
[2]: https://lists.freedesktop.org/archives/wayland-devel/2018-November/039671.html
[3]: https://drmdb.emersion.fr/properties/4008636142/pixel%20blend%20mode
#### Requirements for merging
- [ ] Review
- [ ] Implementations
- [ ] ACKs from membershttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183color-representation: alternative protocol2024-03-05T12:34:56ZSebastian Wickcolor-representation: alternative protocolSame idea as https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/153 but...
* based on Rec ITU-T H.273 aka CICP code points
* compositor can announce support for various features
(previous discussions here https:/...Same idea as https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/153 but...
* based on Rec ITU-T H.273 aka CICP code points
* compositor can announce support for various features
(previous discussions here https://gitlab.freedesktop.org/emersion/wayland-protocols/-/merge_requests/3)
#### Requirements for merging
- [ ] Review
- [ ] Implementations
- [ ] ACKs from membershttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/180surface-invalidation-v1: new protocol2024-02-25T12:13:14ZSimon Sercontact@emersion.frsurface-invalidation-v1: new protocolSee https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/112
- [ ] Review
- [x] 3 implementations
- [x] foot: https://codeberg.org/dnkl/foot/pulls/1234
- [x] wlroots: https://gitlab.freedesktop.org/wlroots/wlroots/-/mer...See https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/112
- [ ] Review
- [x] 3 implementations
- [x] foot: https://codeberg.org/dnkl/foot/pulls/1234
- [x] wlroots: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3921 and https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3910
- [x] mako: https://github.com/emersion/mako/pull/449
- [x] swaybg: https://github.com/swaywm/swaybg/pull/51
- [ ] 3 ACKshttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/140Draft: Add xdg-splash protocol2022-08-04T21:55:45ZMark Bolhuismark@bolhuis.devDraft: Add xdg-splash protocolThis protocol adds support for splash surfaces with a new xdg_surface
role. A client can use this protocol during application startup to
show a simple graphic and/or to show loading progress.
Signed-off-by: Mark Bolhuis <mark@bolhuis.de...This protocol adds support for splash surfaces with a new xdg_surface
role. A client can use this protocol during application startup to
show a simple graphic and/or to show loading progress.
Signed-off-by: Mark Bolhuis <mark@bolhuis.dev>
-----
Previously there was some limited discussion on splash surfaces #67. This MR follows up with a draft.
Some rationale for some of the decisions:
- This is a surface role: A client should not be permitted to self-center, which leaves the compositor free to display it any way it wants.
- Do not use xdg_toplevel as a fallback: Toplevel is simply not a suitable role. Splashes cannot be maximized, fullscreened, etc... Tiling compositors will tile them which is undesirable behavior.
An open question:
- [ ] What policy should we take on input events? Typically splash surfaces have little if any interactive controls. Does it make sense to allow clients to use a splash surface for user interaction?
I'm currently working on a set of weston patches that add splash functionality.
This is my first time drafting a protocol so please bear with me if I've missing anything obvious.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/134WIP: ext-sensitive-context-v1: new protocol2022-04-11T07:48:00ZLeon Henrik Plickatleonhenrik.plickat@stud.uni-goettingen.deWIP: ext-sensitive-context-v1: new protocolThe motivation for this protocol is to provide a unified way for clients
to request surfaces to be shown in sensitive context, such as a locked
session as recently introduced by the `new ext-session-lock-v1` protocol (!131).
That protoco...The motivation for this protocol is to provide a unified way for clients
to request surfaces to be shown in sensitive context, such as a locked
session as recently introduced by the `new ext-session-lock-v1` protocol (!131).
That protocol states that surfaces by clients other than the session-locker may
be shown at the compositors discretion. This makes sense for certain desktop widgets,
such as notifications or perhaps status panels for example. I believe an
additional protocol for clients to request this for their surfaces is needed,
as otherwise the compositor would either have to "guess" based on heuristics
or not allow this at all. Additionally this protocol allows clients to know
when their surface is to be displayed during a sensitive context, so that they can
update the contents accordingly, for example to hide private information.
* [ ] needs review
* [ ] needs compositor implementation
* [X] [Client Implementation](https://git.sr.ht/~leon_plickat/wlclock/commit/sensitive-context)https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/132xdg-pip: Add new protocol2024-03-06T16:18:51ZVlad Zahorodniixdg-pip: Add new protocolThis protocol allows applications that display media contents create
picture-in-picture windows.
xdg_toplevel surfaces are not suitable for picture-in-picture windows
because they need to be excluded from listing in the taskbar or docks...This protocol allows applications that display media contents create
picture-in-picture windows.
xdg_toplevel surfaces are not suitable for picture-in-picture windows
because they need to be excluded from listing in the taskbar or docks
and be placed above all other windows. Besides that, the compositor may
need to apply a different placement policy for pip windows, for example
placing them in the bottom right screen corner, etc.
xdg_pip is built on top of xdg_surface because it gives us support for
client-side drop shadows out of the box.
Similar to ordinary toplevels, picture-in-picture windows can be moved
and resized.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Closes wayland/wayland-protocols#44
Open questions:
- [x] Should it be part of the xdg-shell protocol?\
No. Having the picture-in-picture surface role defined in a separate protocol is a more flexible design, for example it allows us to supersede the pip protocol with something else if needed without affecting the xdg-shell protocol.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124Create ext-screencopy-v1 and ext-image-source-v12024-03-25T12:31:27ZAndri YngvasonCreate ext-screencopy-v1 and ext-image-source-v1This is a new screencopy protocol which improves upon `wlr-screencopy-unstable-v1`.
Supersedes: !39
- [ ] Review
- [ ] 2 ACKs
- [x] wlroots (@emersion)
- [x] COSMIC (@Drakulix)
- [ ] 2 implementations
- [ ] wlroots: https://gitl...This is a new screencopy protocol which improves upon `wlr-screencopy-unstable-v1`.
Supersedes: !39
- [ ] Review
- [ ] 2 ACKs
- [x] wlroots (@emersion)
- [x] COSMIC (@Drakulix)
- [ ] 2 implementations
- [ ] wlroots: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3457
- [ ] wayvnc: https://github.com/any1/wayvnc/tree/ext-screencopy-v1https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/52dbus_annotation: new protocol2024-03-26T11:06:43ZJanet Blackquilldbus_annotation: new protocolThe protocol allows clients or surfaces to be associated
with DBus objects and interfaces.
This formalizes the ad-hoc extensions made to X
and similar compositor-specific Wayland protocols
for assorted tasks that boil down to associatin...The protocol allows clients or surfaces to be associated
with DBus objects and interfaces.
This formalizes the ad-hoc extensions made to X
and similar compositor-specific Wayland protocols
for assorted tasks that boil down to associating
DBus objects with windows/surfaces.
In user-facing terms, this would allow Unity-style application
menus to be implemented in a cross-compositor manner
on Wayland and provides a standard mechanism for applications
such as Firefox and Google Chrome to program against.
Signed-off-by: Janet Blackquill <uhhadd@gmail.com>https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/46Introduce extended-drag protocol2023-06-12T14:41:59ZNick Yamanenickdiego@igalia.comIntroduce extended-drag protocol##### Context and Motivation:
Native Wayland support is being implemented in Chromium browser and one
of the last major missing features is tab/window dragging. After some
research and experimentation, the conclusion is that Wayland pro...##### Context and Motivation:
Native Wayland support is being implemented in Chromium browser and one
of the last major missing features is tab/window dragging. After some
research and experimentation, the conclusion is that Wayland protocol
needs to be extended to enable Chromium's full tab dragging experience
to be properly implemented. Further details on such study can be found
in design document [1].
The proposed protocol extension aims to provide a set of features
unsupported by the current Wayland core DND protocol and extensions,
such as:
1. The ability to make toplevel shell surfaces "draggable" during DND
sessions;
2. Snapping toplevel shell surfaces in and out of a the currently focused
surface and make it possible to smoothly dropped into an arbitrary
location of the screen (without necessarily having another client
accepting such drop, as required in regular DND);
3. Configurable options which make it possible to support a variety of
use cases, including multi-client ones.
4. The ability to detect session cancellation at client side when shell
surfaces are dragged.
The protocol currently has a working implementation that should be
landing soon in ChromeOS' Exo Wayland compositor [2] (the first patches
already landed and others are under review) and a client using it,
Chromium browser [3] and we plan to get it implemented in another major
open source compositor soon (not yet decided which one exactly). There
are also a few demo videos where this WIP impl can be seen in action
at [4].
The motivation for this standardization effort is, besides enabling
Chromium to provide its complete UX in Linux desktop environments
supporting Wayland, to make it usable by other potential use cases
in the community aiming to support such rich UI features.
Further explanation about the protocol and its operation in a typical
use case is available in the protocol descriptor XML file.
[1] https://docs.google.com/document/d/1s6OwTi_WC-pS21WLGQYI39yw2m42ZlVolUXBclljXB4/edit?usp=sharing
[2] https://source.chromium.org/chromium/chromium/src/+/master:components/exo/?q=exo
[3] https://chromium-review.googlesource.com/c/chromium/src/+/2401319
[4] https://www.youtube.com/playlist?list=PLAkw6mvtzrGWJOhDXc6AS2ozuJ73yrnIphttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/45WIP: RFC: present-timing: Enhanced presentation timing requests and events2024-02-05T16:43:26ZAlexandros FrantzisWIP: RFC: present-timing: Enhanced presentation timing requests and eventsThis a protocol extension that offers enhanced presentation timing requests and
events, in order to help clients minimize visual anomalies.
It is modeled after the VK_KHR_present_timing extension, which was recently
[published for comme...This a protocol extension that offers enhanced presentation timing requests and
events, in order to help clients minimize visual anomalies.
It is modeled after the VK_KHR_present_timing extension, which was recently
[published for comments](https://github.com/KhronosGroup/Vulkan-Docs/pull/1364).
Since the Vulkan extension is still largely WIP, changes to that extension which
can affect this protocol are quite likely.
There are a few parts of the protocol, copied from the vulkan extension, the
utility of which is currently under discussion (e.g., present slop). I have left
them in for completeness and the sake of discussion.
The goal of this proposal at this phase is to start an early discussion about the
overall approach, and possibly help inform decisions at the Vulkan level, too.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/44RFC: Add zwp_vrr_v12024-02-16T10:01:38ZAlexandros FrantzisRFC: Add zwp_vrr_v1This protocol allows client surfaces to provide a hint to the compositor
to employ Variable Refresh Rate (VRR) mechanisms to optimize their
frame presentations.
VRR mechanisms allow outputs to vary their frame timings in order to
optima...This protocol allows client surfaces to provide a hint to the compositor
to employ Variable Refresh Rate (VRR) mechanisms to optimize their
frame presentations.
VRR mechanisms allow outputs to vary their frame timings in order to
optimally accommodate frame submissions that occur at irregular rates,
or rates that don't match the configured rate of the these outputs. Such
irregular submissions often occur in video games, whereas in video
playback.
Frame timings have been historically regular and some clients have come
to implicitly or explicitly depend on this regularity. The benefit of
having a client opt-in mechanism for VRR, compared to the compositor
employing it at will without client agreement, is that it provides
additional assurance that clients are properly equipped to deal with the
irregularity in frame timings.
This protocol provides a simple version of VRR where the client implicitly
drives presentation based on submission timings. Depending on the scenario, the
timing accuracy of this mechanism may not be sufficient and some other more
complex mechanism (e.g., in the form of a target presentation timestamps)
may be required.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/43ext-blur: New protocol2024-01-12T00:35:53ZVlad Zahorodniiext-blur: New protocolThis patch introduces a protocol that provides a way to specify the area
of a surface that needs to have its background blurred by the compositor.
An intended use case is to improve visuals of translucent surfaces such
as panels or dock...This patch introduces a protocol that provides a way to specify the area
of a surface that needs to have its background blurred by the compositor.
An intended use case is to improve visuals of translucent surfaces such
as panels or docks by blurring background behind them.
This protocol is based on the org_kde_kwin_blur protocol, which has been
in use since 2015.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>