GitLab

Fixes the following warning:

    NOTICE: Future-deprecated features used:
     * 0.55.0: {'ExternalProgram.path'}
     * 0.56.0: {'dependency.get_pkgconfig_variable'}
Signed-off-by: Simon Ser <contact@emersion.fr>

Alexandros Frantzis authored May 02, 2022 and Jonas Ådahl committed Jun 01, 2022

This mandate makes explicit a practice that's already established in
the writing of the protocol descriptions, and officially clarifies the
meaning of the keywords for readers.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>

This is already covered about three paragraphs above.
Signed-off-by: Daniel Stone <daniels@collabora.com>

Kenny Levinsen authored Apr 05, 2022 and Simon Ser committed Apr 11, 2022

This paragraph contains an incomplete definition of how
wl_surface.attach x/y arguments functions, and makes no reference to the
similar wl_surface.offset.

The paragraph states that there is no effect on the behavior of
wl_surface.attach. Rather than elaborating on its definition and adding
wl_surface.offset, remove the paragraph and let their definition be up
to wl_surface itself.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>

Kirill Primak authored Mar 04, 2022 and Simon Ser committed Apr 06, 2022

Signed-off-by: Kirill Primak <vyivel@eclair.cafe>

Simon Zeni has stepped up as a member for wlroots/Sway.
Signed-off-by: Simon Ser <contact@emersion.fr>

Carlos Garnacho authored Aug 09, 2021 and Jonas Ådahl committed Mar 29, 2022

Here's a long story. The serial is formerly described as:

  When the client receives a done event with a serial different than the
  number of past commit requests, it must proceed as normal, except it
  should not change the current state of the zwp_text_input_v3 object.

Upon first reading it might be obvious to interpret "proceed as normal"
as "apply the changes made by the done event" and "not change the current
state" as "do not make requests on it until serial matches with
expectations again". This would turn the serial into a flow control
mechanism to avoid pushing state changes that we know might be stale.

GTK however makes another outlandish interpretation, where "proceed as
normal" means "ignore the changes made by the done event" and "not change
state of the zwp_text_input_v3 object" is "not change client state". This
makes the serial a full synchronization mechanism where IM commands that
are deemed out of sync are symply ignored.

This would seem a misinterpretation of the protocol, and I proceeded to
change the behavior in GTK. Then some deja vu feeling struck me and I found
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/384#note_344864

, this
change was already done and discussed in the past. Not just that, it is
the right interpretation.

However, there's some notable disadvantages, there's 2 easy ways to
completely break the synchronization between compositor and client:
Having the IM push new state too often (i.e. multiple consecutive
.done events), or having the client .commit too often. If any of both
peers gets ahead of the other slightly, the end result is ignored input.
More specifically, IBus has no provision for this kind of transactional
behavior (probably other IMs too), so implementing "emit .done once after
a set of changes" is not quite possible.

Arguably, ignoring IM input is also a bad thing. IMs expect all commands
to be respected and applied in order and might even rely on that in
their own internal state. Since only state changes are flushed on .done
events, partially ignoring IM commands will end up with the client IM state
out of sync.

The usecase described at that GNOME gitlab comment (edited text changes
happening in parallel to IM interaction) trades the handling of an
inherently racy corner case with the worst kind of mishandling (ignoring
user input) if IM/client don't perfectly sync up.

On the other hand, the flow control approach is more lenient with IMs and
clients "getting a step ahead", and more importantly does not punish the
user whenever either IM/client happens to do that. Double down on this
(already intuitively correct) description, and specify further what it
implies.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>

Drew is no longer involved in Wayland development and has expressed
interest in being removed from the wayland-protocols project.

Thanks for all your contributions throughout the years, Drew!
Signed-off-by: Simon Ser <contact@emersion.fr>

Signed-off-by: Tadeo Kondrak <me@tadeo.ca>

Signed-off-by: Tadeo Kondrak <me@tadeo.ca>

Signed-off-by: Tadeo Kondrak <me@tadeo.ca>

Signed-off-by: Tadeo Kondrak <me@tadeo.ca>

Wayland 1.20.0 adds support for the type attribute to mark events as
destructors.
Signed-off-by: Tadeo Kondrak <me@tadeo.ca>

This will be useful to use features introduced in wayland 1.20,
e.g. event destructors.
Signed-off-by: Simon Ser <contact@emersion.fr>

Makes it easier to investigate CI failures.
Signed-off-by: Simon Ser <contact@emersion.fr>

Signed-off-by: Jonas Ådahl <jadahl@gmail.com>

Isaac Freund authored Oct 31, 2021 and Simon Ser committed Jan 19, 2022

The protocol states that the edges parameter of the resize request must
be one of the values of the resize_edge enum but does not provide a
protocol error value to handle the case where it is not. This commit
adds that error value.
Signed-off-by: Isaac Freund <mail@isaacfreund.com>

This aims to communicate the maximum size a surface should be created
with, and loosely corresponds to the concept of "work area" in the X11
world.

Closes: #17

Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>

Simon Ser authored Dec 08, 2021 and Daniel Stone committed Jan 17, 2022

dev_t is not a struct, it's a typedef.
Signed-off-by: Simon Ser <contact@emersion.fr>

This protocol allows for a privileged Wayland client to lock the
session and display arbitrary graphics while the session is locked.

The client is responsible for performing authentication and informing
the compositor when the session should be unlocked. If the client
dies while the session is locked the session remains locked, possibly
permanently depending on compositor policy.
Signed-off-by: Isaac Freund <mail@isaacfreund.com>
Reviewed-by: Simon Ser <contact@emersion.fr>

Signed-off-by: Max Ihlenfeldt <mihlenfeldt@igalia.com>

Signed-off-by: Jonas Ådahl <jadahl@gmail.com>

Now that compositors must send INVALID to advertise support for
implicit modifiers, we can make it a protocol error to add a
DMA-BUF plane with an unsupported format + modifier pair.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>

On multi-GPU setups, multiple devices can be used for rendering. Clients
need feedback about the device in use by the compositor. For instance,
if they render on another GPU, then they need to make sure the memory is
accessible between devices and that their buffers are not placed in
hidden memory.

This commit introduces a new wp_linux_dmabuf_feedback object. This
object advertises a preferred main device, a set of preferred
formats/modifiers and target devices.

Each object is bound to a wl_surface and can dynamically update its
feedback parameters. This enables fine-grained per-surface
optimizations. For instance, when a surface is scanned out on a GPU the
compositor isn't compositing with, the target device can be set to this
GPU to avoid unnecessary roundtrips.

A feedback object can also be standalone for clients that don't support
per-surface feedback.
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Closes: wayland#59

No change in behavior, just a doc fix.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

Add a note about pre-multiplied alpha for all DRM formats.
Include an escape hatch in the spec to allow other protocol
extensions to override this.

Essentially the same as [1].

[1]: wayland!187

Signed-off-by: Simon Ser <contact@emersion.fr>

It's been a few releases that we ship Meson support, we should be
able to drop the old autotools build system now.
Signed-off-by: Simon Ser <contact@emersion.fr>

On Genode, graphics drivers run in user space.  It is also theoretically
possible for a Wayland compositor to run in kernel space.  Therefore,
the phrase “user space” should be avoided in a Wayland protocol
specification.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

When linking for macOS, this linker flag is rejected. Instead of
always passing it, we can check whether it is supported first.
Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
Reviewed-by: Simon Ser <contact@emersion.fr>

I am trying to cross-compile from macOS for FreeBSD and this is currently
failing since the tests attempt to build a native binary that links
against the wayland-client and wayland-server libraries for the FreeBSD
system. I believe we should be building them for the target system and
not the current host (especially since there is no way to build
wayland-client and wayland-server for macOS, but I do want to check that
the files build correctly for FreeBSD).
Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
Reviewed-by: Simon Ser <contact@emersion.fr>

wayland-scanner is only needed for tests so don't require it if tests
are disabled
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

Signed-off-by: Jonas Ådahl <jadahl@gmail.com>

Peter Hutterer authored Apr 13, 2021 and Simon Ser committed Sep 13, 2021

Hold gestures merely denote "there are fingers on the touchpad but they are
not moving". As touchpad touches are generally fully abstracted, a client
cannot currently know when a user is interacting with the touchpad without
moving - no motion events will be sent in this case.

The two use-cases here are:
- hold-to-interact: where a hold gesture is active for some time
  a menu could pop up, or some object is 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

Since hold gestures by definition do not have movement, there is no need for
an "update" stage in the gesture.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: David Edmundson <davidedmundson@kde.org>
Signed-off by: Eike Hein <hein@kde.org>

Signed-off-by: Jonas Ådahl <jadahl@gmail.com>

We use the no-op executables in test() directives, so these will be
run on the host. This fixes the following warning:

    tests/meson.build:23: WARNING: add_languages is missing native:, assuming
    languages are wanted for both host and build.
Signed-off-by: Simon Ser <contact@emersion.fr>

Simon Ser authored Apr 15, 2021 and Jonas Ådahl committed Sep 01, 2021

The rest of the file uses tabs, not spaces.
Signed-off-by: Simon Ser <contact@emersion.fr>

Simon Ser authored Apr 15, 2021 and Jonas Ådahl committed Sep 01, 2021

This allows clients and compositors to easily use wayland-protocols
as a Meson subproject.
Signed-off-by: Simon Ser <contact@emersion.fr>

When we're building C++ test executables, make sure we pull in the
correct libwayland headers, to avoid trying to compile against a version
different from the scanner we built it against.
Signed-off-by: Daniel Stone <daniels@collabora.com>

The newlines prevent the labels from being properly formatted.
Additionally, the second label reference has a typo (extra "s").
Signed-off-by: Simon Ser <contact@emersion.fr>