A 32-bit image description identity number could theoretically wrap
around in 1.4 years if a new one is allocated 100 times per second.
Compositors that avoid 32-bit wrap-around are allowed to aggressively
recycle numbers, which poses a requirement on clients to hold on to the
image description object in order to keep its number live. Clients might
not do so regardless of documentation, and on compositors that recycle
only after wrap-around clients would not see any problems. This could
cause strange issues in clients on former kind of compositors.
In order to avoid all that, introduce a new 64-bit image description
identity number which has no fear of wrap-around, and require such
numbers to be never recycled. This makes the compositor number allocator
trivial, and clients are more likely to handle it correctly by accident.
Fixes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/246
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
ANSI/CTA-861-H does not require that maxCLL or maxFALL be within the
Mastering Display Luminance range, and it is common for movies to have a
maxCLL greater than the Mastering Display Luminance. Additionally,
Microsoft's own documentation* contains an example that does not pass
the restriction in the protocol. These values are valid, used in the
real world, and clients should not need to discard them. We keep the
requirement that maxFALL <= maxCLL since that is required, but these
values have no relation to the Mastering Display Luminance.
See #263 for further details on why the restriction on maxCLL and
maxFALL is not desirable. Fixes#263.
*: https://learn.microsoft.com/en-us/windows/win32/api/dxgi1_5/ns-dxgi1_5-dxgi_hdr_metadata_hdr10
Signed-off-by: Dudemanguy <random342@airmail.cc>
In an attempt to specify clipping behavior[1] it was found that it would
lead to predictable behavior turning into undefined behavior when a
compositor gains support for extended_color_volume. That would be
awkward.
Instead of specifying clipping to the primary color volume bounds (which
may then disappear), let's leave it undefined, and emphasize the
undefined-ness of exceeding the target color volume instead.
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/453
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Make the connection between parametric image descriptions and Display
class ICC profiles, for clarity.
Suggested-by: Dmitry Kazakov (@dimula73)
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The adaptation state of the viewer is required for interpreting colors, and
specifically for adapting them to a different white point. This commit defines
it to match existing implementations and display class ICC profiles:
The viewer is assumed to be fully adapted to the primary color volume's white
point.
The mastering display white point is not used for this, as it is both somewhat
unlikely to be relevant for the adaptation state of the content creator, and
also relatively likely to be incorrect in existing images, videos and games.
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
This commit introduces an experimental text-input protocol as a functionally exact copy of text-input-v3.
The goal of this is to arrive at an improved text-input-next protocol, without committing to backwards-compatible changes beforehand.
Signed-off-by: Dorota Czaplejewicz <gilapfco.dcz@porcupinefactory.org>
It is not possible to write equations nicely in the XML, so we need an
appendix.
First, the appendix explicitly defines the transfer functions that the
protocol enumeration refers to. Leaving them to be inferred from the
ITU-R and other specifications was too confusing.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
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>
