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/268Draft: stable/linux-dmabuf: allow compositors to advertise multiple devices2024-02-05T14:52:38ZXaver HuglDraft: stable/linux-dmabuf: allow compositors to advertise multiple devicesWith multi gpu systems, clients rendering on a GPU different to the main
device usually have to copy the buffer to the main device in order to ensure
the compositor can import it. In the case where the image is then presented
on the GPU ...With multi gpu systems, clients rendering on a GPU different to the main
device usually have to copy the buffer to the main device in order to ensure
the compositor can import it. In the case where the image is then presented
on the GPU that the client was initially rendering on, this causes two unnecessary
additional copies: One to the main device, and one back to the original
GPU.
With the changes in this commit, compositors can advertise that they're
able to import buffers for sampling on multiple GPUs. This way the compositor
becomes responsible for copying the buffer to the appropriate GPU(s) and
can skip the copies whenever feasible.
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
cc @Drakulix @emersion we talked about this at XDChttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/256fifo-v1: Add new protocol2024-03-28T21:00:53ZDerek 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/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/230xdg-shell: Add edge constraints2024-03-26T10:19:24ZJonas Ådahlxdg-shell: Add edge constraintsAn edge constraint is an complementery state to the tiled state, meaning
that it's not only tiled, but constrained in a way that it can't resize
in that direction.
This typically means that the constrained edge is tiled against a
monito...An edge constraint is an complementery state to the tiled state, meaning
that it's not only tiled, but constrained in a way that it can't resize
in that direction.
This typically means that the constrained edge is tiled against a
monitor edge. An example configuration is two windows tiled next to each
other on a single monitor. Together they cover the whole work area.
The left window would have the following tiled and edge constraint
state:
[ tiled_top, tiled_right, tiled_bottom, tiled_left,
constrained_top, constrained_bottom, constrained_left ]
while the right window would have the following:
[ tiled_top, tiled_right, tiled_bottom, tiled_left,
constrained_top, constrained_bottom, constrained_right ]
This aims to replace and deprecate the `gtk_surface1.configure_edges`
event and the `gtk_surface1.edge_constraint` enum.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
-----
- Review:
- [ ] N\A
- Acks:
- [x] GNOME (@jadahl)
- [ ] N\A
- [ ] N\A
- Implementations:
- [x] mutter (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3266)
- [x] gtk (https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6386)
- [ ] N\Ahttps://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/203staging/xdg-activation: add a request for choosing windows to activate2023-07-18T13:21:36ZXaver Huglstaging/xdg-activation: add a request for choosing windows to activateSome clients allow having multiple documents in a single window, while also
allowing multiple windows at the same time. When such a client is asked
to open a new document by another application, it needs to choose a window
to open it in,...Some clients allow having multiple documents in a single window, while also
allowing multiple windows at the same time. When such a client is asked
to open a new document by another application, it needs to choose a window
to open it in, but it doesn't have enough contextual information to do that
well in all cases. It can for example not know if a window is currently
on an inactive virtual desktop.
The added request and event solve this problem by having the client provide
an activation token and a list of windows, so that the compositor can choose
the best window for opening a new document for the application. It may also
not choose any window, in which case the application should create a new
window.
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
TODO:
- [ ] a better name than "window_hint"? I can't think of anything atm that's both generic and specific enough
- [ ] should this be a separate protocol? It sort of fits in with xdg activation but I'm not sure
- [x] should sending a `wl_surface` that isn't a "toplevel" be a protocol error, or should the compositor just ignore them? I'm not using xdg-shell toplevels to not unnecessarily restrict compatibility with future protocols, but allowing subsurfaces or popups is weird
WIP KWin implementation: https://invent.kde.org/plasma/kwin/-/tree/work/zamundaaa/window-activation-hint
Closes #137https://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/146Add a configure event to zwp_input_panel_v12022-08-03T12:49:50ZArjen HiemstraAdd a configure event to zwp_input_panel_v1When displaying an input panel, the compositor may sometimes want to
adjust the placement and size of the input panel, for example to account
for a task bar or other shell surface that the input panel may overlap.
While placement is alre...When displaying an input panel, the compositor may sometimes want to
adjust the placement and size of the input panel, for example to account
for a task bar or other shell surface that the input panel may overlap.
While placement is already done by the compositor, currently there is no
way to communicate a desired size to the input panel client, so sizing
is not possible.
This adds a configure event to `zwp_input_panel_v1`, allowing the
compositor to request a new panel size from the input panel client. A
corresdponding ack_configure request is also added so the client can let
the compositor know it processed the configure.https://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/72text-input: Synchronize set_cursor_rectangle with the wl_surface2024-02-20T13:47:01ZTadeo Kondrakme@tadeo.catext-input: Synchronize set_cursor_rectangle with the wl_surfaceThis is a possible fix for https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/43.This is a possible fix for https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/43.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/71text-input: Add preedit_commit_mode event for mouse click event2024-02-20T13:47:02ZPeng Wutext-input: Add preedit_commit_mode event for mouse click eventIBus update_preedit_string_with_mode feature send the preedit text and
the commit mode to the input method module, use preedit_commit_mode event
to send the commit mode together with the preeedit text.
IBusInputContext specify how input...IBus update_preedit_string_with_mode feature send the preedit text and
the commit mode to the input method module, use preedit_commit_mode event
to send the commit mode together with the preeedit text.
IBusInputContext specify how input context interact with the keyboard,
but sometimes mouse click also interacts with the input context, too.
For Firefox, if some preedit text is visible with ibus-hangul input method;
after mouse click, the preedit will be committed twice.
To fix this issue, ibus-hangul can send preedit text and commit mode
together; after mouse click, the preedit is handled directly in
input method module of Firefox, and the preedit is committed in
the current text widget.
For detailed analysis, please read the merge request comments.
URL: https://gitlab.freedesktop.org/wayland/wayland-protocols/merge_requests/30
Signed-off-by: Peng Wu <pwu@redhat.com>