References to H.273 are confusing people:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/442#note_3079717
The confusion arises from H.273 usually referring to encoding standards
which only indirectly define a reference display. Wayland
color-management is only interested in the displays.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The BT.1886 recommendation is impossible to implement precisely if
min_lum includes other sources than the display emission. BT.1886
transfer function requires L_W and L_B to determine the function
parameters black level lift and gain. The black level lift changes the
non-linearity, and cannot be implemented as an optical addition.
I believe the inclusion of optical additives, particularly the ambient
flare, came from sRGB specification. I do not recall seeing it anywhere
else.
Drop the optical additives from the definitions of the luminances. It
was probably incorrect for everything but sRGB, if they even had it
specified at all. This allows implementing BT.1886 as specified.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Before the dependency is usable, enum headers need to be built.
Fixes missing header files when wayland-protocols is used as a
subproject.
Signed-off-by: Simon Ser <contact@emersion.fr>
When wayland-protocols is installed to a custom prefix, we need to
point dependencies to that prefix' include dir.
Signed-off-by: Simon Ser <contact@emersion.fr>
Some of these used wl_tablet or the outdated wp_tablet.
No functional changes, only descriptions are affected.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There should only be decoration outside of it, no functional UI elements. This
is especially important on some compositors that clip windows to their window
geometry in some situations (like when it's in a tile).
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
Clients are allowed to send any value from the enum (unlike other
requests where only supported values are allowed), however clients
are not allowed to send out-of-enum values.
Signed-off-by: Simon Ser <contact@emersion.fr>
The original MR did not copy the popup interface because it's been limited and inadequate for actual use.
This introduces a version heavily based on xdg-popup.
Signed-off-by: Dorota Czaplejewicz
The value was zero because the enum was not a bitfield at some point when the protocol was
developed and I forgot to change the value to one when making it a bitfield.
This is technically a breaking change, but as the client could never receive the blur
capability before this commit, it won't actually break anything - it was already broken.
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
This global interface allows applications to request the pointer
to be moved to a position relative to a wl_surface.
Co-authored-by: Xaver Hugl <xaver.hugl@kde.org>
Co-authored-by: Matthias Klumpp <matthias@tenstral.net>
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Signed-off-by: Neal Gompa <neal@gompa.dev>
Reviewed-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/wayland_qa.md#q-should-srgb-content-be-decoded-with-the-piecewise-srgb-transfer-function
I found it unfortunate that we left in a TF code that will intuitively
be used incorrectly. It is as if we designed the protocol so that
compositors will need to fix up client image descriptions.
I am not aware of any use case that would want to target a display with
the sRGB piece-wise transfer function, that would be a non-standard
display.
This patch does not help compositors avoid needing to second-guess
client image descriptions using srgb TF, but it at least documents the
situation. We could choose to out-law srgb TF in a minor version bump,
or drop it completely in the next major version. Compositors can also
not advertise support for srgb TF.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This protocol allows the client to specify a region behind the surface that should
be blurred, with the intention to improve the visuals of for example panels or
terminals.
This protocol is roughly based on the org_kde_kwin_blur protocol, which has been
in use since 2015. The protocol is made more generically though, so that other
related effects can be added in the future, like for example contrast improvements.
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
This change strips down the protocol to functionality that corresponds
to text-input-v3, is already useful, typically implemented in the wild
(squeekboard), and well-understood.
Dificult to implement well functionality like keyboard grabs is removed
to find a better solution without stopping the development of the basic
functionality.
Signed-off-by: Dorota Czaplejewicz
This is a separate commit so that it's clear the base for this protocol
was just a copy with no changes.
It also includes the protocol in the build system.
Signed-off-by: Dorota Czaplejewicz
This commit introduces an experimental input-method protocol as an exact
copy of the fle describing the unofficial zwp_input_method_v2 from
squeekboard.
It's also supported by wlroots and smithay.
This protocol is the counterpart to text-input-v3. It gives the
compositor a standard way to outsource the handling of the input method.
Signed-off-by: Dorota Czaplejewicz
These protocols are not installed; users need to access these files via
methods other than released tarballs, for example via a meson subproject.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
This new protocol aims to let clients define the remaining bits of the color
encoding they are using in their buffers.
In particular, this lets clients define the how the alpha has been encoded and
how conversions from YCbCr to RGB take place.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Co-authored-by: Robert Mader <robert.mader@collabora.com>
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Co-authored-by: Simon Ser <contact@emersion.fr>
Co-authored-by: Xaver Hugl <xaver.hugl@kde.org>
The window id protocol allows clients to set a tag for toplevels, which
the compositor can use to identify them even after the application
has been restarted. This persistent identification can be used by the
compositor to restore properties like position, size, "always on top",
and it can also be used for allowing users to create rules that change
compositor behavior for specific windows.
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
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>
Some tablets provide one or more rotary controls (see e.g. the Huion
Inspiroy Dial 2) that provide delta information effectively equivalent
to a mouse wheel. Expose those in the same way as the strip or ring
controls, with the event matching the wl_pointer.axis_v120 approach.
Like a typical mouse wheel we do not expect there to be a source
information, so this is left out of the interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Just VID/PID is not enough, we need the bustype too. And since we now
have that event remove the mention of USB from zwp_tablet_v2.id.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unfortunately all the objects depend on each other so any change in any
requires bumping all versions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
# 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>
