This is the implementation of the internal text-input protocol that will
be used to communicate IMs (to be implemented by gnome-shell) with clients.
The text_input protocol has its own focus expressed through enter/leave
events, that will typically follow the keyboard's.
The client will be able to communicate its current status (eg. focus state,
cursor rectangle in surface coordinates, text surrounding the cursor
position, ...) and will receive commands from the compositor (eg. preedit
text, committing a string, ...).
Whenever there is an active input method, the compositor will route key
events directly through it. The client will not receive wl_keyboard
events if the event is consumed by the IM.
Window moving and resizing depends on the `meta_wayland_seat_get_grab_info`
function succeeding. At the moment, tablet tools do not generate implicit
grabs like the pointer and touch. This commit adds the necessary elements
to track implicit grabs and retrieve their information.
https://bugzilla.gnome.org/show_bug.cgi?id=777333
Add a new object class, MetaWaylandInputDevice, and make all device
classes (pointer, keyboard, touch) inherit it. In the future common
functionality may be placed there.
https://bugzilla.gnome.org/show_bug.cgi?id=771305
Meant to replace explicitly checking whether a
MetaWaylandPointer/MetaWaylandKeyboard/MetaWaylandTouch has a seat or
not to determine whether they are supposed to be active or not.
https://bugzilla.gnome.org/show_bug.cgi?id=771305
Leave these checks up to the callers, the only uses of this function
(indirect, through meta_wayland_seat_get_grab_info) are
[wl_shell|xdg]_surface.move/resize/show_window_menu.
In move/resize it makes sense to check for a button being pressed, because
we must expect a button release event. However for xdg_surface.show_window_menu
we 1) don't strictly need further events and 2) we must account for press+release
event pairs being processed at once in the compositor before the client sees
the former.
That is eg. the case of touchpad 2nd/3rd button tap emulation, multifinger
taps will emit the event pair at once, so when the client manages to request
xdg_surface.show_window_menu, it'll be too late in the compositor side, so the
request is ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=764519
Right now we just check the pointer serial, so the popup will be
immediately dismissed if the client passes a serial corresponding to
another input device.
Abstract this a bit further and add a meta_wayland_seat_can_popup() call
that will check the serial all input devices. This makes it possible to
trigger menus through touch or keyboard devices.
https://bugzilla.gnome.org/show_bug.cgi?id=756296
The grabbing state is now checked for both pointer/touch devices
within the seat, and the grab start coordinates returned by
meta_wayland_seat_get_grab_info().
https://bugzilla.gnome.org/show_bug.cgi?id=733631
The capability flags are determined from the device types of the slave devices
that are currently attached. This also happens whenever a device is added or
removed, so the capabilities are kept up to date, and clients know about these.
On VT switch, all slave devices are temporarily removed, so the cascade of
signals will make the seat end up with capabililities=0 while input is suspended.
https://bugzilla.gnome.org/show_bug.cgi?id=733563
Clutter touch events are translated into events being sent down
the interface resource, with the exception of FRAME/CANCEL events,
which are handled directly via an evdev event filter.
The seat now announces invariably the WL_SEAT_CAPABILITY_TOUCH
capability, this should be eventually updated as devices come and
go.
The creation of MetaWaylandTouchSurface structs is dynamic, attached
to the lifetime of first/last touch on the client surface, and only
if the surface requests the wl_touch interface. MetaWaylandTouchInfo
structs are created to track individual touches, and are locked to
a single MetaWaylandTouchSurface (the implicit grab surface) determined
on CLUTTER_TOUCH_BEGIN.
https://bugzilla.gnome.org/show_bug.cgi?id=724442
In particular we need to know about all key events to keep the xkb
state reliable even if the event is then consumed by a global shortcut
or grab and never reaches any wayland client.
We also need to keep track of all pressed keys at all times so that we
can send an updated set or pressed keys to the focused client when a
grab ends.
https://bugzilla.gnome.org/show_bug.cgi?id=722847
Grabs are now slice allocated structures that are handled by
whoever starts the grab. They contain a generic grab structure
with the interface and a backpointer to the MetaWaylandPointer.
The grab interface has been changed to pass full clutter events,
which allowed to remove the confusion between grab->focus and
pointer->focus. Invidual grabs are now required to keep their
focus, and choose whoever gets the events.
https://bugzilla.gnome.org/show_bug.cgi?id=707863
We can't rely on clutter's xkb_state, because that's updated
when events are pulled from the kernel, not when we see them.
Instead, use the new clutter API to get the full modifier state
from the event (which, as a side effect, also works when clutter
is using the X11 backend for running nested).
https://bugzilla.gnome.org/show_bug.cgi?id=706963
We need to track the full xkb_state to have the necessary information
to send to the clients, otherwise they may get confused and lock
or invert the modifiers. In the evdev backend, we just retrieve the
same state object that clutter is using, while in the other backends
we fake the state using what clutter is providing (which is a subset
of what X11 provides, which would be necessary to have full state)
https://bugzilla.gnome.org/show_bug.cgi?id=705862
We need to track the full xkb_state to have the necessary information
to send to the clients, otherwise they may get confused and lock
or invert the modifiers. In the evdev backend, we just retrieve the
same state object that clutter is using, while in the other backends
we fake the state using what clutter is providing (which is a subset
of what X11 provides, which would be necessary to have full state)
https://bugzilla.gnome.org/show_bug.cgi?id=705862
When running Mutter under Cogl's KMS backend no cursor will be
provided so instead this makes it so the cursor will be painted as a
CoglTexture that gets moved in response to mouse motion events. The
painting is done in a subclass of ClutterStage so that we can
guarantee that the cursor will be painted on top of everything else.
This patch adds support for the set_cursor method on the pointer
interface so that clients can change the cursor image.
The set_pointer method sets a surface and a hotspot position to use
for the cursor image. The surface's buffer is converted to a
CoglTexture and attached to a pipeline to paint directly via Cogl. If
a new buffer is attached to the surface the image will be updated. The
cursor reverts back to the default image whenever to the pointer focus
is moved off of any surface.
The image for the pointer is taken from X. It gets installed into
a fixed data location for mutter.
This copies the basic input support from the Clayland demo compositor.
It adds a basic wl_seat implementation which can convert Clutter mouse
events to Wayland events. For this to work all of the wayland surface
actors need to be made reactive.
The wayland keyboard input focus surface is updated whenever Mutter
sees a FocusIn event so that it will stay in synch with whatever
surface Mutter wants as the focus. Wayland surfaces don't get this
event so for now it will just give them focus whenever they are
clicked as a hack to test the code.
Authored-by: Neil Roberts <neil@linux.intel.com>
Authored-by: Giovanni Campagna <gcampagna@src.gnome.org>
