Instead of letting the wayland bits maintain an always-software
cursor renderer, let the cursor renderer be managed by the backend,
and only hook to it (as we do for pointer cursor) in the wayland
bits.
ATM, make the cursor renderer still always-software, although
ideally we should allow moving the HW cursor management between
renderers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Different devices may get standalone cursor renderers, add this API
to adapt slowly to this. The meta_backend_get_cursor_renderer() call
still exists, but shortcuts to the mouse pointer's renderer (as it
actually did before).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Use a new set in MetaInputDeviceNative, this coexists with
ClutterInputDevice coords for the time being. This API will
eventually be only accessed from the input thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
While multiple built-in panels isn't actually supported in any
meaningful manner, if we would ever end up with such a situation, e.g.
due to kernel bugs[0], we shouldn't crash when trying to set an
'external only' without any external monitors.
While we could handle this with more degraded functionality (e.g. don't
support the 'switch' method of monitor configuration at all), handle it
by simply not trying to switch to external-only when there are no,
according to the kernel, external monitors available. This would e.g.
still allow betwene 'mirror-all', and 'linear' switches.
The crash itself was disguised as an arbitrary X11 BadValue error, due
to mutter trying to resize the root window to 0x0, as the monitor
configuration that was applied consisted of zero logical monitors, thus
was effectively empty.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1896904
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1899260
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1607>
xkb recently gained support for user-specified keymaps, which means we
can no longer assume that the configuration data is necessarily fully
complete or correct; and the configuration language is quite a labyrinth,
so it's easy to get wrong. If setting the keymap fails, leave it in
whatever state it previously had, since that seems preferable to crashing
with a NULL pointer dereference.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/1555
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1605>
Sometimes the automatically selected primary GPU isn't suitable with no
way to make an well educated guess to do it better. To make it possible
for the user to override the automatically calculated default, make it
possible to override it using a udev rule.
E.g. to select /dev/dri/card1 as the primary GPU, add a file e.g.
/usr/lib/udev/rules.d/61-mutter-primary-gpu.rules (path my vary
depending on distribution) containing the fellowing line:
ENV{DEVNAME}=="/dev/dri/card1", TAG+="mutter-device-preferred-primary"
Reboot or manual triggering of udev rules to make it take effect may be
required.
Related: https://gitlab.gnome.org/GNOME/mutter/merge_requests/1057https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562>
Instead of aborting with an error, display a half transparent gray
square instead of cursors and log a warning in the journal, allowing the
user to fix their system withotu having to rely on switching to a TTY.
It will be immediately obvious the cursor is silly looking, which will
be a better hint than just aborting.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1428
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1563>
Monitor tile info is possible to fetch when RANDR version 15 is exposed
by the X11 server. We had inverted the check meaning that only if older
versions were advertised would we attempt to init the tile information.
Fix this guard, thus fix monitor tiling on X11.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1524
Not calling libinput dispatch in the backend constructor defeats the
logic in post init as the device added events have not been processed
yet.
So instead of trying to guess the cursor initial visibility, simply
update it along when devices get added.
Additional benefit, we do not need to walk the all device list looking
for touchscreens anymore, we just need to check the device being added
since the current logic is to hide the cursor as soon as a touchscreen
is found.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1534
At startup, libinput dispatch is called from the MetaSeatNative
constructed callback.
That means that we may get libinput events even before the default seat
is set.
In turn, processing those events may trigger the use the default seat
while it's still not set yet, and cause a crash of gnome-shell/mutter
at startup.
A simple reproducer for this is to start gnome-shell/mutter with a
tablet connected and the stylus in proximity, the proximity event will
cause gnome-shell/mutter to crash at startup.
To avoid that issue, avoid dispatching libinput events early from the
MetaSeatNative constructed callback, those events will eventually get
processed when the seat and the backend are all setup.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1501https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1534
Otherwise we might run into a use-after-free and crash on (virtual)
device removal:
Invalid read of size 8
at clutter_input_device_get_device_type (clutter-input-device.c:811)
by update_last_device (meta-backend.c:1282)
by g_main_dispatch (gmain.c:3325)
by g_main_context_dispatch (gmain.c:4016)
by g_main_context_iterate.constprop.0 (gmain.c:4092)
by g_main_loop_run (gmain.c:4290)
by meta_run_main_loop (main.c:708)
by meta_run (main.c:723)
by main (main.c:550)
Address is 32 bytes inside a block of size 504 free'd
at free (vg_replace_malloc.c:538)
by g_type_free_instance (gtype.c:1939)
by clutter_event_free (clutter-event.c:1420)
by _clutter_stage_process_queued_events (clutter-stage.c:830)
by handle_frame_clock_before_frame (clutter-stage-view.c:1064)
by clutter_frame_clock_dispatch (clutter-frame-clock.c:405)
by frame_clock_source_dispatch (clutter-frame-clock.c:456)
by g_main_dispatch (gmain.c:3325)
by g_main_context_dispatch (gmain.c:4016)
by g_main_context_iterate.constprop.0 (gmain.c:4092)
by g_main_loop_run (gmain.c:4290)
by meta_run_main_loop (main.c:708)
by meta_run (main.c:723)
Block was alloc'd at
at malloc (vg_replace_malloc.c:307)
by g_malloc (gmem.c:106)
by g_slice_alloc (gslice.c:1025)
by g_slice_alloc0 (gslice.c:1051)
by g_type_create_instance (gtype.c:1839)
by g_object_new_internal (gobject.c:1939)
by g_object_new_valist (gobject.c:2264)
by g_object_new (gobject.c:1782)
by meta_input_device_native_new_virtual (meta-input-device-native.c:1365)
by meta_virtual_input_device_native_constructed (meta-virtual-input-device-native.c:705)
by g_object_new_internal (gobject.c:1979)
by g_object_new_valist (gobject.c:2264)
Suggested-by: Carlos Garnacho <carlosg@gnome.org>
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1529
Rely on the seat stage, or other ways to fetch it. Also rely that
there is actually a single stage, so that we assign the right stage
to all events going out of the seat, in a single place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
This is a bit scattered around, with the setter/getter in Clutter, and
it only being only directly honored in Wayland (it goes straight through
device properties in X11).
Make this private native API, and out of public ClutterInputDevice API.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
Make the upper part agnostic about the device being relative in order
to avoid applying keep-aspect. The X11 bits already are, so make it
sure it's also the case for the native backend.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
As it does seem from a read to libinput code, TOUCH_CANCEL events
actually do contain slot information, and are emitted per-slot.
This means we can avoid iterating over the slots ourselves, they
are still expected to be sent altogether.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
When malformed modes are provided and no valid mode spec is found, mutter
will eventually try to access the last element of an empty list. Warn about
this and exit properly.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1481
Many tablets have a native portrait mode panel, yet come with a keyboard dock,
where the device gets docked in landscape mode. To avoid the display being
on its side when mutter starts while the tablet is docked, we need to take
the accelerometer reported orientation into account even if there is a
tablet-mode-switch which indicates that the device is NOT in tablet-mode
(because it is docked).
Add special handling for the first time the "orientation-changed"
signal gets signalled by the orientation-manager, which happens after it
has successfully claimed the accelerometer with iio-sensor-proxy.
The added special handling of the initial "orientation-changed" signal
does a number of checks:
1. panel_orientation_managed is false because of the tablet-mode-switch and not
because of other reasons.
2. The device has a native portrait mode panel (and thus likely needs rotation
to display the image the right way up when docked).
If all these checks succeed then it continues with creating a new
monitors-config based on the orientation ignoring the panel_orientation_managed
value (for the initial/first "orientation-changed" signal only).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
The orientation reported by the orientation_manager may have changed while
panel_orientation_managed was false. So when panel_orientation_managed
changes to true we should re-check the orientation.
This fixes the orientation not being correct when e.g. taking a 360 degree
hinges 2-in-1 in clamshell mode (so landscape orientation) and then folding
it into tablet mode while holding it in portrait orientation.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
Add support for the (mostly theoretical) case of an input-device
offering tablet-mode-switch functionality being unplugged.
This makes the has_tablet_switch handling identical to the has_touchscreen
handling, leading to more consistent code.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
Detect if a tablet-mode-switch device is already present when mutter
starts by checking for this from meta_seat_native_constructed. This
mirrors how we also set has_touchscreen from meta_seat_native_constructed.
This fixes tablet-mode-switches only being recognized when they are added
at runtime.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
Unconditionally setting has_touchscreen to check_touch_mode
when a new device gets added leads to has_touchscreen becoming
false when during runtime e.g. an USB keyboard gets plugged in.
Fix this by setting has_touchscreen to TRUE when check_touch_mode
is TRUE and leaving it alone otherwise.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
A first step towards abandoning the CoglObject type system: convert
CoglFramebuffer, CoglOffscreen and CoglOnscreen into GObjects.
CoglFramebuffer is turned into an abstract GObject, while the two others
are currently final. The "winsys" and "platform" are still sprinkled
'void *' in the the non-abstract type instances however.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1496
Mutter still relies heavily on singletons such as its MetaBackend.
For that, the backend implementation has a meta_init_backend() function
which is called at startup from meta_init(), which creates the desired
backend and sets the singleton which is returned by meta_get_backend().
Unfortunately, that means that the backend is never actually freed, and
all the code from the backend finalize function never actually get
called.
Add a meta_release_backend() to free the backend singleton.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1438
The input settings constructor installs callback functions on device
added/remove and tool-changed.
However, on dispose, those signals are not disconnected, meaning that on
teardown, once the devices get removed eventually, the callback will
still fire and call the callback with freed data, causing a crash.
Make sure we clear the signals on devices on dispose, to avoid the crash
on teardown.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1438
CoglMatrix already is a typedef to graphene_matrix_t. This commit
simply drops the CoglMatrix type, and align parameters. There is
no functional change here, it's simply a find-and-replace commit.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
During seat initialization, we process early libinput events (adding all known
devices) before the seat gets a stage assigned. This causes warnings when trying
to handle the corresponding CLUTTER_DEVICE_ADDED events, as they are sent
stageless.
As it is definitely too soon to have those events sent meaningfully, filter
those events out and instead handle the CLUTTER_DEVICE_ADDED emission for all
known devices after the seat receives an stage. This makes the events guaranteed
to be emitted early in initialization, but not so soon that they can't be
handled yet.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1472
Like it's done for the pointer in other places. Without a stage assigned,
some bits (like IM handling) may end up with events ignored, and misbehave.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1413
When a MetaBarrier is first created it allocates a backend
impl object which does the actual heavy lifting.
Unfortunately, that backend object is never freed.
This commit ensures the implementation gets freed when
the barrier object is freed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1451
meta_barrier_destroy is responsible for removing the extra
reference added in meta_barrier_constructed.
Unfortunately, it fails to do this because of a misplaced early
return statement.
This commit removes the spurious return.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1449
In X, buttons 1, 2, 3 are left, middle, right. In evdev, the order is
BTN_LEFT, BTN_RIGHT, BTN_MIDDLE. So setting a scroll button to 2 gave us a
middle button in the X session and a right button in a wayland session.
Fix that by hard-coding the LMR buttons handling.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1433
Even when a direct client buffer has a compatible format, stride and
modifier for direct scanout, drmModePageFlip() may still fail sometimes.
From testing, it has been observed that it may seemingly randomly fail
with ENOSPC, where all subsequent attempts later on the same CRTC
failing with EBUSY.
Handle this by falling back to flipping after having composited a full
frame again.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1410
If there is no laptop panel (for example on a desktop PC or a virtual
machine), attempting to put a NULL monitor in the list of matches
will just make mapping_helper_apply() crash.
Mitigates: https://gitlab.gnome.org/GNOME/mutter/-/issues/1414
Signed-off-by: Simon McVittie <smcv@debian.org>
It's enabled by default when using the i915 driver, but disabled
everywhere else until it can be made reliably an improvement. Until
then, for anyone want to force-enable it, add the string
'dma-buf-screen-sharing' to the experimental features list in GSettings.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1442
Seems DMA buffer based interprocess buffer sharing is more broken than
not, so for now only enable it when using the i915 driver.
For example vmwgfx, qxl and radeon, it results in mmap() failing to mmap the
memory region. Other drivers, e.g. amdgpu will function, but may hit
very slow memory download paths, resulting in worse performance.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1442
We only want the panel autorotation to happen if the laptop has an
accelerometer, and is in tablet mode. Regular laptop mode should
lock the orientation, and let it be configured manually.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
So far, we've expected this signal to not happen whenever autorotation
shouldn't apply (no accelerometer is a strong reason). In future commits
we'll add further checks to this policy, so prevent autorotation to
change the display configuration if the MetaOrientationManager signal
happens but it should be ignored.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
Instead of having everyone check net.hadess.SensorProxy themselves, have
this all controlled by the MetaOrientationManager, and proxied everywhere
else via a readonly property in org.gnome.Mutter.DisplayConfig.
We want to attach more complex policies here, and it seems better to
centralize the handling of the autorotation feature rather than
implementing policy changes all over the place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
We used to pick the "best" output for each builtin/size/edid categories,
and then pick the "best" (in that order) of those for each input device.
This is most often enough, but is prone to wrong results in some corner
cases (eg. 2 outputs with the exact same dimensions).
Change this to a score mechanism that doesn't leave outputs out. The
weights are the same, but the score is accumulated if an output matches
multiple categories. All outputs are evaluated and sorted by score, and
input devices with the best matches are applied first (as they already
did).
This should break the tie if eg. there's 2 outputs with similar dimensions,
but one of them has some EDID match in addition. The output with multiple
matches will score higher up, while it might have been entirely discarded
with the previous implementation.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1175https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1202
The work at https://gitlab.gnome.org/GNOME/gnome-control-center/issues/239
intended to make integrated devices optionally mappable to other outputs
(in order to allow fix mishandling from our heuristics, or to quickly reach
things in other monitor without changing devices).
This was missed in that plan, we do allow cycling outputs, but we still did
prevent it from doing anything for integrated devices. Fix that, and change
output cycling so we don't allow a "NULL" EDID for integrated devices, this
makes those go through the MetaInputMapper (resulting in one output listed
twice), instead of mapping to the full stage.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1186https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1201
