The move cursor is ambiguous, since it is used in two context:
for DND, and for resizing. This commit adds a separate enum
value for a cursor that indicates something can be resized
in all directions. A suitable image for this value is a four-headed
arrow.

Signed-off-by: Matthias Clasen <mclasen@redhat.com>

This is the cursor shape that corresponds to the ASK drag action
in the core protocol. The expected semantics of ASK are that the
drop target presents the user with a choice of actions when the
drop happens. A typical image for this cursor is a default cursor
with a '?' emblem.

Signed-off-by: Matthias Clasen <mclasen@redhat.com>

Add some hints about related groups of cursor shapes and recommend
that they should use visually compatible images.

Signed-off-by: Matthias Clasen <mclasen@redhat.com>

We are going to add new values to the cursor shape enum,
so a new protocol version is needed.

Signed-off-by: Matthias Clasen <mclasen@redhat.com>

Nick Yamane authored 3 months ago and Daniel Stone committed 2 weeks ago

Signed-off-by: Nick Diego Yamane <nickdiego@igalia.com>

Xaver is a KWin maintainer.

Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>

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

Niels' efforts predate Sebastian's by another 5 years and they deserve
to be mentioned.

Sorry for missing them from the commit.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

Sebastian Wick authored 5 years ago and Pekka Paalanen committed 4 weeks ago

 # Wayland Color Management and HDR Design Goals

The goals of Wayland color management and *high dynamic range* (HDR) support
protocol extension are:

- Reliably maintain the display server color setup.
- Support professional color managed applications (presentation).
- Support displaying TV broadcasts and other high quality video content.
- Support a wide variety of monitors and application content,
  including wide gamut and/or HDR.
- Bring basic color management to applications that are not color-aware at all.
- Bring adequate color management to Wayland applications that are color-aware
  but not color managed.

Once a display system has been calibrated, measured and configured, it should
keep its settings until the user intentionally changes them. Achieving this
reliability requires protecting the system from accidental changes and avoiding
dependency on hardware default state as much as possible. The former is done by
not allowing arbitrary programs to change the settings. The latter is realized
by very careful Wayland compositor implementation that takes into account the
details of the underlying system API. For example, with DRM also unrecognized
KMS properties need to be saved and restored.

It should be reasonably possible to run existing color managed applications,
particularly X11 applications through Xwayland, without need for modification
and get at least the level of color managed presentation features they received
on Xorg. It is possible that this requires e.g. re-creating monitor color profiles,
recalibration, or other reconfiguring.

The use of `xrandr` and similar X11 tools and interfaces are intentionally
not supported as the Wayland desktop paradigm does not allow clients to force
effects on other clients. Those global properties, including video mode
and display color depth, are left to each Wayland compositor's own settings
management as they are end user preferences.

The protocol extension should be usable for professional broadcast display
usage, meaning that it is suitable for use inside a television for all of
aerial, cable, and internet delivered content. However, the extension might not
be completely sufficient, particularly where it would violate the Wayland
desktop paradigm (e.g. requests to change display video mode or calibration
shall not be included).

The support for a wide variety of monitors is achieved by communicating sufficient
information about the monitors to applications, so that applications can adapt
to the monitors if they choose to do so. The proper composition and handling of
a wide variety of application content is achieved by applications describing
the content in sufficient detail for a Wayland compositor to process it
correctly.

Applications that pay no mind whatsoever to color management are called
*color-unaware*. They have been written for an average system that more or less
resembles (or not) sRGB in its color output. This is the large majority of all
applications on X11 and Wayland. On a usual consumer monitor they look pretty
much ok, but on a color managed monitor with special features (wide gamut, HDR)
they might be an eye sore when displayed side by side with properly color
managed applications. A goal for Wayland color management is to make these
application look "pretty much ok" on such special monitors without
modifications to the applications or toolkits, while letting color managed
applications look their best simultaneously.

One step forward from color-unaware applications are *color-aware* applications
that also are not fully color managed applications. These applications are
fixed to one or few well-known color spaces, the traditional sRGB for instance.
They don't try to adapt to the monitor and they might not use any *color
management module* (CMM). These applications can still describe their content's
color space to a Wayland compositor, which will then take care of color managed
presentation of the content.

Finally, *color-managed* applications are fully prepared to do all of their own
color management, and may be using a CMM. They can also adapt their rendering
to different kinds of monitors, and prefer to know everything they can about a
monitor in order to do a perfect job. They expect the window system to not
tamper with the color values they produce.

The above goals imply that a Wayland compositor is an active participant in
color management, converting all application content into some common color
space for display on a monitor. As a compositor can do that separately for each
monitor, it is possible to present the same window adequately color managed on
multiple monitors simultaneously. It is also possible to keep a monitor in HDR
mode while showing both *standard dynamic range* (SDR) (traditional or
unmodified applications) and HDR content simultaneously. A practical use case
for that is a video player showing a HDR video on one Wayland surface and SDR
subtitles and user interface on another surface.

 History

Wayland color management has been planned and developed for many years.
This patch is the result of 141 development patches which are stored for
future reference in the wayland-protocols branch history/color-management:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commits/history/color-management


The development started some years even before this.

There have been many contributors over the years. The list below has
been collected from those 141 patches, and is surely incomplete.

Co-authored-by: Benjamin Otte <otte@redhat.com>
Co-authored-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Co-authored-by: Colin Marc <hi@colinmarc.com>
Co-authored-by: Dudemanguy <random342@airmail.cc>
Co-authored-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Co-authored-by: Matthias Clasen <mclasen@redhat.com>
Co-authored-by: Naveen Kumar <naveen1.kumar@intel.com>
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Co-authored-by: Timo Witte <timo.witte@gmail.com>
Co-authored-by: Victoria Brekenfeld <victoria@system76.com>
Co-authored-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Co-authored-by: Xaver Hugl <xaver.hugl@kde.org>

Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

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

Xaver Hugl authored 2 months ago and Daniel Stone committed 1 month ago

Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>

Replace the EGL links and AddFb2 reference with a link to the
kernel docs. The kernel docs explain all the subtleties of dmabuf
exchange, and already link to EGL (and more).

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

Signed-off-by: James Ramsey <james.jehiel.ramsey@gmail.com>

YaoBing Xiao authored 4 months ago and Jonas Ådahl committed 2 months ago

Signed-off-by: YaoBing Xiao <xiaoyaobing@uniontech.com>

Signed-off-by: YaoBing Xiao <xiaoyaobing@uniontech.com>

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

Signed-off-by: Victoria Brekenfeld <github@drakulix.de>

Signed-off-by: Nick Diego Yamane <nickdiego@igalia.com>

It's needed for the deprecated-since attribute [1] introduced with [2],
at least when building the tests, which pass the '--strict' parameter to
wayland-scanner.

[1] wayland@ee12e69b


[2] 6c214e6d

Signed-off-by: Heiko Becker <mail@heiko-becker.de>

Mike Blumenkrantz authored 5 months ago and Daniel Stone committed 4 months ago

with great NACKs come great responsibility:
* if you abuse this power, you should be held accountable
* if you should not be using this power, you should be held accountable

Signed-off-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>

Mike Blumenkrantz authored 5 months ago and Daniel Stone committed 4 months ago

lots of small issues to resolve

Signed-off-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>

Mike Blumenkrantz authored 5 months ago and Jonas Ådahl committed 4 months ago

these have a lower bar to clear for inclusion and are intended to
promote rapid development with greater community involvement

Signed-off-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>

Daniel Stone authored 5 months ago and Simon Ser committed 4 months ago

No-one really uses the list anymore; issues are better.

Signed-off-by: Daniel Stone <daniels@collabora.com>

Daniel Stone authored 5 months ago and Simon Ser committed 4 months ago

It was implicitly understood to be the same mechanism as projects, so
codify that.

Signed-off-by: Daniel Stone <daniels@collabora.com>

Daniel Stone authored 5 months ago and Simon Ser committed 4 months ago

We were using 'member' to generally mean 'member project', but this
wasn't super clear, and sometimes it also meant an individual person.

Clarify it such that project vs. individual is clear where it's
relevant, leaving 'member' only for when it's not relevant.

Signed-off-by: Daniel Stone <daniels@collabora.com>

Drew is no longer active in the Wayland community. Simon Zeni is
the wlroots point-of-contact and is very familiar with DRM leasing.

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

Neal Gompa (ニール・ゴンパ) authored 4 months ago and Vlad Zahorodnii committed 4 months ago

This protocol allows a privileged client to control data devices. In
particular, the client will be able to manage the current selection and take
the role of a clipboard manager.

This is a straight port from wlr-data-control-unstable-v1 to ext-, as it
has not changed in five years and has near-universal compositor adoption.

Signed-off-by: Neal Gompa <neal@gompa.dev>

Signed-off-by: YaoBing Xiao <xiaoyaobing@uniontech.com>

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

Daniel Stone authored 8 months ago and Mike Blumenkrantz committed 5 months ago

When this extension was developed, we did not yet know how VRR hardware
would behave in practice as it was not standardised, and the KMS
interface was equally unstandardised.

Now things have shaken out to an acceptable level, we have a good idea
of what we need, which is simply to include a base refresh rate - the
rate the compositor would drive the display for non-VRR clients.

Bump the protocol to version 2 and require the compositor to provide
a rate.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>

Add a new protocol for adding timestamps to wayland surface state to
allow deferring processing until later.

Signed-off-by: Derek Foreman <derek.foreman@collabora.com>

Add a new protocol to allow a content update to require a
display refresh pass before it is ready to present.

Signed-off-by: Derek Foreman <derek.foreman@collabora.com>

Originally we wanted to have an official website to document
adoption. However this never materialized.

I don't think the governance document is the right place for this
anyways.

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

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>

Mesa is represented by Daniel Stone and Mike Blumenkrantz.

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

Daniel Stone will move to represent mesa, and Derek Foreman is taking
his place.

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

Simon Ser authored 5 months ago and Simon Zeni committed 5 months ago

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

Daniel Stone authored 5 months ago and Simon Ser committed 5 months ago

These are usually the best people to review the changes.

Signed-off-by: Daniel Stone <daniels@collabora.com>

Daniel Stone authored 5 months ago and Simon Ser committed 5 months ago

This is useful to know who to ping when you want to change something.

Signed-off-by: Daniel Stone <daniels@collabora.com>

itycodes authored 5 months ago and Simon Ser committed 5 months ago

Signed-off-by: Tranquil Ity <tranquillitycodes@proton.me>
Closes: #217