MetaWaylandInput is an object that will become in charge of handling
input events on their way to the Wayland socket. It keeps a stack
of event handlers, and propagates events and changes across them in
order to have them emit Wayland events, or change focus.
Each of these event handlers has a MetaWaylandEventInterface, this
is a vtable meant to replace MetaWaylandPointerGrabInterface and
MetaWaylandKeyboardGrabInterface in an unified manner, with the
following methods:
- get_focus_surface: to return the focus surface for a device/sequence.
Since several handlers will want to delegate logic on previous
handlers, it is optional to chain up with
meta_wayland_event_handler_chain_up_get_focus_surface().
- focus: To trigger a focus change for a device/sequence, since
event handlers are daisy chained by default, it is mandatory to
chain up with meta_wayland_event_handler_chain_up_focus(), either
with the given surface, or passing NULL to let later handlers
unset their state.
- press/motion/release: Unified handlers for pointer/touch/stylus
input, they chain up like event handlers do.
- key: Key event handler, propagates like event handlers do.
- other: Fallthrough for other events (pad, scroll, ...), propagates
like event handlers do.
Since there is a variety of expected behaviors, and the possibility
of stacking for some of the existing Wayland "grabs", this provides
the mechanism for that to happen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
That would be the surface under the tool that is being currently used
on the device. This will be used by MetaWaylandSeat to implement the
default MetaWaylandEventInterface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
The MetaWaylandPointer used to put this together through
MetaCursorTracker cursor visibility, and ClutterSeat-level
inhibition API, applying the pointer focus changes due to
visibility logically to Wayland clients.
In order to make this work over all Clutter widgetry
instead of just Wayland clients, make the ClutterSeat-level
inhibition API control this feature at the ClutterStage picking
level, and leave/enter the seat pointer as appropriate.
By default, the seat pointer has (un)focus inhibited. The
MetaCursorTracker has been made another player in unfocus
inhibition, simply asking for the pointer to get its focus
while the cursor is visible.
This in practice means that picking code may return a NULL
actor, some asserts and preconditions had to be changed to
handle this, plus some test code slightly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
Do not jump at MetaWaylandSeat across the MetaWaylandTabletSeat to
poke at the tablet tools, and chain up the checks through a
MetaWaylandTabletSeat method instead.
While at it, use g_autoptr to manage the tool list, and fix a leak.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
After negotiation of DMABUF transport mutter will silently allocate SHM
buffers if the allocation in the add_buffer callback fails. It's cleaner
to renegotiate the supported formats without announcing DMABUF
capabilities in this case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2557>
To fixate the format or renegotiate after a DMABUF allocation failed we
need to rebuild the EnumFormat params.
The function meta_screen_cast_query_modifiers will return false if no
modifiers are supported, thouse we can drop the check and remove the
macro guard.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2557>
This function contains a stub, which returns support for implicit
modifiers, if modifiers are supported preserving the current
capabilities. The stub has to be replaced with a query to the cogl
renderer to support explicit modifiers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2557>
This check was originally added because `window` was actually used.
While technically correct, there's no reason to keep it around.
Fixes: 4736f873f2 ("compositor/native: Add support for direct scanout per view")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177>
Until now we only supported direct scanout to the primary plane if the
buffer size perfectly matched the display size.
Since display controllers usually support scaling and cropping buffers
highly efficiently, try to let them do the job. This is usually helpful
if wp_viewporter is used by the client or Mutter uses fractional
scaling.
This has several advantages:
- Games (e.g. SDL2 based ones) can almost always hit direct scanout
paths in fullscreen mode. Notably when fractional scaling is used or
the game renders in a non-native resolution (or both).
- Video players using YUV buffer formats and wp_viewporter can easily
hit direct scanout paths, making displaying video very power
efficient as the 3D engine is not used at all.
Note that this still only uses the primary plane, no overlay or underlay
planes, making this change comparatively low risk.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177>
In a following commit we will start supporting scaled and croped
surfaces, thus, in preparation, update the logic to three common cases:
1. only one surface, fullscreen (most apps)
2. a content surface and a black background surface which the client
does not want to unmap, fullscreen
3. top-level subsurface covers the whole window and is opaque (Firefox)
The remaining currently supported cases should be fairly uncommen and
and harder to compute.
Note that we already check that the window cover the stage view in
MetaCompositorView.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177>
This allows us to pass on the related data from CoglScanouts.
If dst_rect does not match the mode, we assume that not covered areas
are opaque black - usually black bars around a centered surface.
While such driver behaviour does not appear to be documented (well) yet,
it seems to be followed by all known existing drivers and is used in a
similar way in ChromeOS.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177>
We need an object to hold additional scanout related information, such
as scaling and positioning data. Turn CoglScanout into such an object,
moving the interface into CoglScanoutBuffer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177>
Except meta_window_x11_get_group, which is still used by GNOME Shell
and we can't make it a private API for now.
Will need further investigation and could be done as a future
step
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3555>
The macro used to call into a bunch of other macros so let us turn it
into a single function.
This would simplify things for the next commit that puts the MetaGroup
usage behind a X11 ifdef
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3555>
If such a failure is followed by a successful frame then the Cogl frame
queue would have size 2, leading to an assertion failure in
`meta_onscreen_native_notify_frame_complete`:
```
g_assert (!cogl_onscreen_peek_head_frame_info (onscreen));
```
Notifying on the failure however keeps the Cogl frame queue limited to
a size of 1 and we recover gracefully with only a missed frame and a
warning message.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3278
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3565>
Popups were missing the "input focus" unification in the pointer
seat, triggering MetaWaylandKeyboard focus changes underneath. On
one hand this missed moving all associated focus with it, on the
other hand this made keyboard and global input focus get out of
sync, and bring funky behavior like keyboard focus loss after
dismissing popups.
Fixes: 7b232d9f65 ("wayland: Keep track of the "input focus" on MetaWaylandSeat")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3256
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3568>
In some circumstances, we may end up with outputs with the same
vendor/product/serial, in which case we have a hard time finding the
right one to map tablets to, since configuration only has these 3
pieces of data.
Add the handling of a 4th argument containing the output name
based on the connector (e.g. HDMI-1), so that it can be used to
disambiguate the output if necessary.
This only kicks in if there actually are multiple outputs with the
same EDID data. A goal of the configuration as it was stored was to
remain useful if the user changed how the device is physically
connected to the computer, this remains true for the vast majority
of users having a single thing of each.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3556>
Our hashtable stores tools by the serial but our stylus tool and eraser
tool share the same serial - they only differ by the tool type.
This results in only one tool being created and this tool re-used for
the other type tool. Fun side-effects of this are that the stylus ends
up using the eraser pressure curve (or vice versa).
Hack around this by bit-flipping the serial for the eraser to
make it distinct - this is the only place we need to wrorry .
Closes#1884
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3542>
For barrier validation, check_barrier() would start from the
(presumably) left-most monitor and walk the neighbor monitors to the
right.
This is assuming that there is always a monitor at (0.0), which is not
necessarily the case. If the first monitor on the left is not aligned at
the top, there is no logical monitor at (0.0) causing a NULL pointer
derefence.
Instead of starting from the monitor at (0,0), start from the primary
logical monitor, as there is necessarily one.
Fixes: 85885c6 - Check barriers don't extend into nonexisting monitors
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3272
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3562>
There doesn't seem to be a good reason to keep this code in
`MetaWaylandSurface`. Moving it to `MetaWaylandBuffer` cleans things
up and will allow us to tread buffers differently depending on their
type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3559>
For secondary GPU rendering contexts we currently might choose an EGL
config with a format which is not supported on all primary planes. The
renderer is created when a GPU is detected and lighting up outputs and
thus assigning CRTC and primary planes can happen at any point after
that. This means we have to make sure that all possible plane
assignments will work with the rendering context when we create it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3235
Fixes: cc7bca073 ("crtc/kms: Dynamically assign primary and cursor planes")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3512>
