This protocol allows compositors to send information about cut out
display areas to clients. This way compositors can describe display
notches, waterfalls and low resolution areas to clients so that these
can avoid placing important information there.
This is a copy of
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/372
adjusted for the experimental namespace.
Helps: #87
Signed-off-by: Guido Günther <agx@sigxcpu.org>
The interface description says the target_primaries event is mandatory,
but event documentation disagreed. Fix the disagreement by requiring the
event always.
This saves the compositor from figuring out whether to send the event or
not. I do not know what compositors do today, but sending the event is
definitely safe. Compositors that do not always send the event are
retroactively deemed buggy.
Fixes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/305
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Protocols in all stages have the same rules for compatibility, just
different expectations of how often breaking changes, and thus major
protocol versions, get introduced.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
Instead of documenting parts of each phase in different chapters,
document all the details about a specific phase in one chapter.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
We now have a bunch of protocol phases which we can refer to. Mentioning
protocols by the implementation detail of in which directory they are is
a bit roundabout.
This change makes sure that protocol phases are used when possible and
mentions the directory structure exhaustively in a single place.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
We used to call extensions to core wayland `protocol extensions`. This
terminology has been dying out and we simply refer to those things as
`protocols`. In fact, the README already uses `protocol extension`,
`extension` and `protocol` interchangeably, so let's just stick to the
modern `protocol` terminology.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
There is no need for two names to refer to the same thing. Let's rename
the `testing` phase to the `staging` phase.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
This update solves the mobile problem of the "enter" key.
It also makes precise cursor placement possible from the IME.
Signed-off-by: Dorota Czaplejewicz
Note that wp_image_description_v1 is not a frozen interface. Therefore
it must always be a descendant of wp_color_manager_v1.
In order to allow other protocols, such as ext-image-capture-source-v1,
to define the equivalent of
wp_color_management_output_v1.get_image_description, we must therefore
create an indirection between the new protocol and
wp_image_description_v1 that is resolved through wp_color_manager_v1
itself.
This is a prerequisite for adding color management support to the
ext-image-copy-capture-v1 protocol.
Signed-off-by: Julian Orth <ju.orth@gmail.com>
ICC-based calibrated print workflows have generally used the sRGB
two-piece transfer characteristic. The CRT era monitors were exclusively
power curve, but print workflows used software calibration to meet the
two-piece curve. Everyone else used the monitor native transfer
characteristic.
Acknowledge that both ways exist, and allow describing both as what they
are.
Mesa is already using "srgb" if it is available, for programs that
actually expect gamma22. Exposing "srgb" with its literal definition
would make a compositor (KWin has been named) appear regressing in
picture quality. The same with "ext_srgb" as Mesa used to map
VK_COLOR_SPACE_EXTENDED_SRGB_NONLINEAR_EXT to it, probably incorrectly.
sRGB is specified to use a power-law 2.2 display, and reality is not
consistent. Some compositors take srgb to mean gamma22 already, so there
is practical ambiguity. There are also endless discussions about which
one sRGB actually is and when: power-law 2.2 or the piece-wise function.
Monitors are manufactured both ways and they are often even switchable
between the two. Therefore deprecate the "srgb" value, it is too easy to
pick and assume one behavior while someone else assumes the other
behavior.
Additionally, extending the range beyond 1.0 would significantly diverge
between srgb and gamma22 because of the different exponent. Assuming
that ext_srgb is identical to srgb for [0.0, 1.0] would conflict with a
compositor that takes srgb as gamma22 but implements ext_srgb by the
piece-wise function.
Given that monitors with the piece-wise function exist or are calibrated
to it, and materials are prepared on them, add a new value explicitly
for the sRGB piece-wise function. Its name deliberately does not include
"srgb".
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This rendering intent is a modified absolute rendering intent that
assumes the viewer is not adapted to the display white point, so no
white point adaptation between surface and display is done.
This can be useful for color proofing applications.
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
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>
