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>
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
The strict "mailbox" model of wayland past is not how modern compositors
process commits, and many explanations of how double buffered state is
applied throughout wayland-protocols are no longer strictly accurate.
Instead of trying to define double-buffered state at every point of use,
just reference the evolving definition of wl_surface.commit.
This still leaves a few old definitions that weren't trivially updated.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This protocol extension has not changed in a long time, is
widely supported, and no upcoming breaking changes are planned.
The interface names are left unchanged, so that compositors and
clients don't need to be updated. In particular, the legacy "z"
prefix is still part of the interface name.
Signed-off-by: Simon Ser <contact@emersion.fr>
libinput may not always have a descriptive name for a tablet
device, in which case it's better to let the Wayland client
pick a fallback (potentially localized) than send a fake string.
Not all tablet devices are USB, so make it clear that the id
event may be skipped.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/180
"ask the client" isn't very clear. Let's use the word "configure"
which is more explicit: the client doesn't have a say in this.
(Note, wording in the following paragraphs is clearer and uses the
word "must".)
Signed-off-by: Simon Ser <contact@emersion.fr>
This was probably carried over from an early draft of the protocol.
This event is not a suggestion as the full description explains:
the client must ack it.
Signed-off-by: Simon Ser <contact@emersion.fr>
This protocol extension is ubiquitous. It's time to mark it as
stable.
The interface names are left unchanged, so that compositors and
clients don't need to be updated. In particular, the legacy "z"
prefix is still part of the interface name.
Signed-off-by: Simon Ser <contact@emersion.fr>
This interface has no "enter" event. This was likely copy-pasted
from wl_pointer.set_cursor.
The event which indicates focus is proximity_in.
Signed-off-by: Simon Ser <contact@emersion.fr>
Make it explicit in the protocol that [un]set_maximized and
the following configure event can't be reliably matched, and the
clients shouldn't try to do it.
Closes#106
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
The "logical size" as stated by the first paragraph corresponds to the
monitor size in the global compositor space.
To most clients, this is unnecessary information, and should be ignored,
but some used the listed examples to derive information that contradicts
the very definition of what this event communicates.
One example tried to add surface size assumptions, which was not
correct. Remove this part completely, clients should not try to
configure their surface sizes from the logical size of a monitor.
The other is the list of size examples; it tried to communicate that a
compositor sometimes may not scale the viewport of the monitor in its
global compositor coordinate space, in which case, the logical size
itself matches the actual resolution. Tweak this wording to make that
clear that it does not related to any surface size.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
In the past, xdg-output had only the logical_position and
logical_size events, then the name and description events were
added. Later on, they were moved inside wl_output since they aren't
desktop-specific. However the goals section of the protocol overview
hasn't been updated accordingly.
Make it clear that this protocol's name and description events should
not be preferred over wl_output.
Signed-off-by: Simon Ser <contact@emersion.fr>
These have been merged into wl_output. Clients should prefer
using wl_output events instead of relying on xdg-output.
Signed-off-by: Simon Ser <contact@emersion.fr>
Here's a long story. The serial is formerly described as:
When the client receives a done event with a serial different than the
number of past commit requests, it must proceed as normal, except it
should not change the current state of the zwp_text_input_v3 object.
Upon first reading it might be obvious to interpret "proceed as normal"
as "apply the changes made by the done event" and "not change the current
state" as "do not make requests on it until serial matches with
expectations again". This would turn the serial into a flow control
mechanism to avoid pushing state changes that we know might be stale.
GTK however makes another outlandish interpretation, where "proceed as
normal" means "ignore the changes made by the done event" and "not change
state of the zwp_text_input_v3 object" is "not change client state". This
makes the serial a full synchronization mechanism where IM commands that
are deemed out of sync are symply ignored.
This would seem a misinterpretation of the protocol, and I proceeded to
change the behavior in GTK. Then some deja vu feeling struck me and I found
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/384#note_344864, this
change was already done and discussed in the past. Not just that, it is
the right interpretation.
However, there's some notable disadvantages, there's 2 easy ways to
completely break the synchronization between compositor and client:
Having the IM push new state too often (i.e. multiple consecutive
.done events), or having the client .commit too often. If any of both
peers gets ahead of the other slightly, the end result is ignored input.
More specifically, IBus has no provision for this kind of transactional
behavior (probably other IMs too), so implementing "emit .done once after
a set of changes" is not quite possible.
Arguably, ignoring IM input is also a bad thing. IMs expect all commands
to be respected and applied in order and might even rely on that in
their own internal state. Since only state changes are flushed on .done
events, partially ignoring IM commands will end up with the client IM state
out of sync.
The usecase described at that GNOME gitlab comment (edited text changes
happening in parallel to IM interaction) trades the handling of an
inherently racy corner case with the worst kind of mishandling (ignoring
user input) if IM/client don't perfectly sync up.
On the other hand, the flow control approach is more lenient with IMs and
clients "getting a step ahead", and more importantly does not punish the
user whenever either IM/client happens to do that. Double down on this
(already intuitively correct) description, and specify further what it
implies.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Now that compositors must send INVALID to advertise support for
implicit modifiers, we can make it a protocol error to add a
DMA-BUF plane with an unsupported format + modifier pair.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
On multi-GPU setups, multiple devices can be used for rendering. Clients
need feedback about the device in use by the compositor. For instance,
if they render on another GPU, then they need to make sure the memory is
accessible between devices and that their buffers are not placed in
hidden memory.
This commit introduces a new wp_linux_dmabuf_feedback object. This
object advertises a preferred main device, a set of preferred
formats/modifiers and target devices.
Each object is bound to a wl_surface and can dynamically update its
feedback parameters. This enables fine-grained per-surface
optimizations. For instance, when a surface is scanned out on a GPU the
compositor isn't compositing with, the target device can be set to this
GPU to avoid unnecessary roundtrips.
A feedback object can also be standalone for clients that don't support
per-surface feedback.
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Closes: https://gitlab.freedesktop.org/wayland/wayland/issues/59
Add a note about pre-multiplied alpha for all DRM formats.
Include an escape hatch in the spec to allow other protocol
extensions to override this.
Essentially the same as [1].
[1]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/187
Signed-off-by: Simon Ser <contact@emersion.fr>
Hold gestures merely denote "there are fingers on the touchpad but they are
not moving". As touchpad touches are generally fully abstracted, a client
cannot currently know when a user is interacting with the touchpad without
moving - no motion events will be sent in this case.
The two use-cases here are:
- hold-to-interact: where a hold gesture is active for some time
a menu could pop up, or some object is selected, etc.
- hold-to-cancel: where e.g. kinetic scrolling is currently active, the start
of a hold gesture can be used to stop the scroll
Since hold gestures by definition do not have movement, there is no need for
an "update" stage in the gesture.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The protocol states that the client must provide xdg_toplevel surfaces,
but doesn't specify protocol error values that can be sent by the
compositor.
Signed-off-by: Simon Ser <contact@emersion.fr>
This is being picky, but "pinch/spread" is the physical gesture, zoom and
rotate is the effect that clients provide in response to that gesture.
Let's use pinch only here since spread is more ambiguous in english, as anyone
who's ever had butter on their bread would know.
Also, everything else is referring to it as pinch anyway, so zoom/rotate here
is the odd one out.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently, the spec doesn't say explicitly that present requests assign
a surface role. Given that, it can be viewed as the protocol modifies
an already assigned surface role, e.g. xdg-toplevel, and present requests
only act as hints.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
