Move protocol dependency information from a separate dict in
tests/meson.build into the main protocol dictionaries in meson.build.
Each protocol's value is now a dict mapping version to a list of
dependency file paths, making dependencies visible alongside the
protocol definitions.
Signed-off-by: Matt Turner <mattst88@gmail.com>
This protocol allows client and compositor to use a different coordinate space
for communicating surface coordinates. The goal is to allow using unscaled
pixels rather than the lossy integer logical coordinate space, so all sizes
and positions on the pixel grid can be expressed correctly.
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
Now that dependent protocol code is linked into test executables, all
cross-protocol symbols are properly resolved. The
--unresolved-symbols=ignore-all workaround is no longer needed and was
not effective with LLVM's LLD linker or on musl systems without lazy
binding.
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/48
Signed-off-by: Matt Turner <mattst88@gmail.com>
Some protocols reference interfaces defined in other protocols (e.g.,
xdg-decoration references xdg_toplevel from xdg-shell). When built in
isolation, these produce undefined symbols.
Define a dependency map and link the generated code from depended-on
protocols into each test executable, properly resolving all
cross-protocol symbol references.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Split the single foreach loop into two passes to allow test executables
to reference generated code from other protocols. The first pass
generates scanner outputs and records the custom_targets in
dictionaries. The second pass builds the test executables.
No functional change.
Signed-off-by: Matt Turner <mattst88@gmail.com>
There seems to be some demand from input methods to be able
to style different parts of the preedit string differently.
Since the reasons to do that are many, and vary between IMs
and languages.
But even though some IMs would much want to be able to specify
colors, they lack the context to know what choice of colors
provides enough contrast and legibility embedded on foreign
UIs (e.g. accounting things like themes, accessibility, ...).
There is a proposal for a semantic closed list of pre-edit
styling options at https://github.com/ibus/ibus/wiki/Wayland-Colors,
which this commit follows, so clients and UIs have more freedom
in displaying a suitable style to pre-edit strings.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
These requests allow clients to explicitly declare the desired
interaction pattern with input panels (e.g. the system OSK).
This allows clients to decide a fine grained pattern to show/hide
these panels that is decouple of enable/disable requests.
This may help them enhance the experience with e.g. selecting
text, or navigating around large bodies of text without an
intrusive OSK, or implementing other UI patterns like a "show OSK"
button.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Some input methods such as a virtual keyboard allow a user to switch
between different languages. This is important to clients as some
languages should be rendered as RTL or change font rendering.
Signed-off-by: David Edmundson <davidedmundson@kde.org>
In some environments it is desirable to show an input panel UI (e.g. OSK)
that is able to perform miscellaneous actions other than inserting text.
Add the framework for this, the available actions may be extended in later
versions of the protocol.
Signed-off-by: Tadeo Kondrak <me@tadeo.ca>
This change makes it clear that there's an extra buffer for the value.
This explains the purpose of the complicated design.
Signed-off-by: Dorota Czaplejewicz
Currently, the after-effects of the set_cursor_rectangle request on
the input method UI and the client-side redraws are not guaranteed
to be atomic.
Add the requirement for compositors handling the newer version of
the protocol to make the set_cursor_rectangle request visually
effective with the same wl_surface.commit.
Signed-off-by: Tadeo Kondrak <me@tadeo.ca>
Some clients don't show preedit text inline, so the compositor may
want to display the preedit text in a popup window instead.
Signed-off-by: Tadeo Kondrak <me@tadeo.ca>
Allow hinting input methods about if Emoji support is not useful
for special applications likes IDE, which manage or debug other
applications.
Fixes: #79
Signed-off-by: fujiwarat <takao.fujiwara1@gmail.com>
The new hint is meant to indicate that the text input already provides an
on-screen means to enter data, and that using the system provided input
method may not be needed.
It should be used when the client presents the user with a custom on-screen
input method, like an on-screen keyboard, or perhaps a dropdown list.
The new hint is meant to address the issue when the system input method is an
on-screen keyboard. Without the hint, the input method would not know that it's
not needed, unless the client refrained from using the input method protocol
at all.
With the hint, the input method can still be enabled, while not displaying a
second on-screen keyboard. This allows for the system input method to still
provide accessibility services, as well as text completion or prediction.
Based on discussion in https://gitlab.gnome.org/GNOME/gtk/merge_requests/978
Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
For a variety of cases it's desirable to have a method for negotiating
the restoration of previously-used states for a client's windows. This
helps for e.g., a compositor/client crashing (definitely not due to
bugs) or a backgrounded client deciding to temporarily destroy its
surfaces in order to conserve resources.
This protocol adds a method for managing such negotiation and is loosely
based on the Enlightenment "session recovery" protocol which has been
implemented and functional for roughly two years.
v2: Address review comments
v3: Add xdg_toplevel_session_v1.restore event. Move delete toplevel
request to xdg_toplevel_session_v1. Remove surface argument from
xdg_toplevel_session_v1.restored. Remove unused 'invalid_restore'
(same intent as 'already_mapped'). Add 'invalid_session_id' error.
Specify size limits and other documentation improvements.
Signed-off-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Synchronization is only needed for 3 things:
- to let the input method know when its update was applied not like it expected,
- especially when a byte index stopped being on bytes boundary due to extra change and a retry is needed,
- to break off events coming to an old text input after focusing a new one.
The one big change of this is relaxing the contract of the input method. The application now doesn't apply the changes exactly.
"delete_surrounding_text" is the only affected place so far, now it mentions the unexactness explicitly. The change is necessary because without strict sync, the input method can't know if it's sending messages aligned on code point boundaries.
This solves 90% of the retry problem.
Such problems all stem from text changing near the caret, where the user already has an expectation of weird interactions (multi-user typing over each other - IME garbage in, text garbage out), or the user expects something that the input method can't correct (text to emoji substitution should not result in a retry due to unexpected output, making this work with IME is the client's problem).
The other big change is keeping sync for the purpose of switching text fields.
Hopefully this is enough for everyone, and it stays more or less compatible.
Signed-off-by: Dorota Czaplejewicz <gilapfco.dcz@porcupinefactory.org>
This protocol provides a way for clients to create and add windows to
"zones".
A zone is a isolated environment with its own coordinate space where
clients can add and arrange toplevels that logically belong to each
other.
It provides means for, among other things, requesting that windows are
placed at specific coordinates within the zone coordinate space.
The protocol includes a request to retrieve the extents of the
server-side frame, so that it may be taken into consideration when
positioning server-decorated windows relative to one another.
Signed-off-by: Matthias Klumpp <matthias@tenstral.net>
When clients create an xdg_toplevel_decoration object, they opt-in for
being self-decorated by the compositor if it decides to. Clients have no
way to prevent the compositor from potentially decorating them, if they
don't want any decorations they should destroy the
xdg_toplevel_decoration object.
Some toolkits allow toggling toplevel decorations at runtime. In this
case they need a way to transition from having no decorations at all to
a state where they can be decorated.
Allow creating an xdg_toplevel_decoration object on an already-mapped
toplevel to accomodate for this use-case.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/issues/9
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>
