Introduced in libinput 1.26 this feature allows restricting the
tablet tool pressure range to a subset of its physical range. The
use-case is either to require some higher-than-usual minimum pressure
before the pen reacts, or lower-than-usual pressure to reach the maximum
logical pressure.
libinput takes a [0.0, 1.0] normalized range which we expose as percent
in the gsettings. The wacom driver doesn't have an exact equivalent but
it has a Threshold setting (range [1, 2048]) that defines when a button
is generated for tip down.
See gsettings-desktop-schemas!84
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3794>
Unlike most other schemas the path for a tool requires a bit of
processing (serial number or tablet vid/pid if there's no serial number).
Let's make the tool settings available through the MetaInputSettings
instead of having to duplicate that path composition in the caller.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
Stylus actions that don't map into LMR or back/forward are now created
as a clutter button event with a button number of zero. Nothing is
actually done with those events for now, they're just discarded later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
For stylus buttons we apply a button mapping, e.g. secondary button ->
right. This mapping was previously applied to the clutter event's evdev
code only, not the actual clutter button. As a result, gnome-shell would
always treat the BTN_STYLUS as middle and BTN_STYLUS2 as right,
regardless of the mapping.
Move the mapping up so we first adjust our evcode, then proceed with
the usual mappings.
Note that this temporary breaks the stylus mapping to Back/Forward which
will be fixed in a follow-up commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
Use the helper function for mapping a stylus tool evdev code to a
clutter button code. This fixes a (theoretical) issue - if a tool were
to send any button other than the one we handled those would likely be
BTN_SIDE and friends and we'd likely end up with negative button
numbers. The BTN_TOOL_PEN range is not predicable enough to do any sort
of calculation conversion because things like BTN_TOOL_DOUBLETAP have
specific meanings that aren't actually buttons.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
This complements the existing clutter->evdev and evdev->clutter helpers,
but this time for buttons we expect from a stylus tool. We also need to
convert left/middle/right for the Wacom puck/lens cursor tools but that
particular conversion is lossy.
Note that these are more restrictive than the normal codes - if we
get "other" buttons from a stylus we don't really know what they could
possibly map to. So we safely map what looks like buttons from a mouse
but otherwise complain and return zero.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
Instead of using cairo for scaling and rotating cursors before putting
them on a plane, use Cogl. For now still download them back to the CPU
so we can place them on a dumb buffer, but can explore rendering to a
DMA buffer directly as a future improvement.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
Allow compositing in a linear color space and do so either when forcing
it via the debug controls D-Bus API, or when the experimental HDR mode
is enabled.
This relies on paint nodes etc to actually transform everything into the
linear target color space, which isn't done yet, so enabling it right
now will cause a broken result. Yet, introduce this now, so that
painting can be fixed piece by piece.
Linear blending is automatically enabled on monitors where HDR is
enabled, as this makes it possible to use an linear color space when
blending content from different color spaces with different transfer
functions.
Linear blending requires extra precision, i.e. 16 bit per channel
in the intermediate buffer due how the values are distributed,
so only enable the experimental HDR mode if the Cogl context supports
half float formats.
By default, no intermadiate linear offscreen framebuffer is used.
To test, do e.g.
./tools/debug-control.py --toggle ForceLinearBlending
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
g_unix_fd_list_append() duplicates the provided fd. If that fails, it
returns -1 as fd index and sets - if provided - the passed GError
accordingly.
However, currently, mutter does not check the return value (the fd index
of the appended fd) and thus passes an invalid fd list via dbus to the
remote desktop session user.
Fix this error by also checking the fd index. If the fd index is invalid
(< 0), simply pass the error message of the g_unix_fd_list_append() call
to the caller.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3871>
This reverts commit a3082b8eb35fffbb4c23f7794414a58c14708177.
We don't find the VKMS device with this commit because it is on seat0
and not on META_BACKEND_TEST_INPUT_SEAT.
The other way around, i.e. returning seat0 in all cases also doesn't
work because *something* hangs if the default seat referrs to the real
seat0 instead of the nonesense META_BACKEND_TEST_INPUT_SEAT.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3869>
Fixes error building against libdrm >= 2.4.122:
../src/backends/native/meta-kms-plane.c:67:8: error: redefinition of ‘struct drm_plane_size_hint’
67 | struct drm_plane_size_hint {
| ^~~~~~~~~~~~~~~~~~~
In file included from /usr/local/include/libdrm/drm.h:1025,
from /usr/local/include/xf86drm.h:40,
from ../src/backends/native/meta-kms-plane-private.h:20,
from ../src/backends/native/meta-kms-plane.c:21:
/usr/local/include/libdrm/drm_mode.h:866:8: note: originally defined here
866 | struct drm_plane_size_hint {
| ^~~~~~~~~~~~~~~~~~~
Suggested by Jonas Ådahl.
v2:
* Use has_type. (Sebastian Wick)
v3: (jadahl)
* Bump meson requirement to 1.3.0 for compiler.has_type()
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3556
Fixes: 0ca933baecf0 ("backend/native: Adds support for SIZE_HINTS Cursor Plane Property")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3848>
In these checks, it's an important detail to preserve subpixel information
in order to correctly determine whether the coordinates are inside or
outside a view.
Otherwise, small enough motion towards the left/top might get rounded
to 0, be seen as "inside the view", and the pointer coordinates be allowed
to escape the viewport constraints.
This was figured out by Pascal Nowack before me, with a difference of
minutes. Credit where credit is due.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3530
Fixes: 6c972546f1 ("mtk: Add Rectangle.contains_point")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3820>
In meta_seat_impl_remove_virtual_input_device(), the 'device'
variable is first removed from MetaSeatImpl, then a "device
removed" event is generated with it.
The problem here is that, if this is the last reference of
'device', the removal from MetaSeatImpl will destroy it. Then
the freed variable will be used to create the "device removed"
event, which is a use-after-free situation.
Fix that by owning an extra ref to 'device' as long as the
function is executing. Do this by declaring a g_autoptr
variable with the extra ref. This g_autoptr variable is cleaned
up by the end of the function, which achieves the desired effect.
Spotted by Coverity.
CID: #1594046
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3835>
Instead of having get_seat_id() handle most cases, and then special
casing another case outside of it, let it handle them all, making all
users just able to call get_seat_id().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3812>
It's constructed as a native backend headless backend, but uses a custom
monitor manager (based on MetaMonitorManagerNative) that creates a fake
monitor. Rendering is unconditionally done with the surfaceless
renderer.
The test devices used now use virtual devices, meaning some changes to
the tests to e.g. not set names, and not dealing with input devices
directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3812>
This is where the viewports are updated, and so lets move connecting the
signal together with it. It also helps a future change to the test
backend where it creates a custom monitor manager.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3812>
`update_secondary_gpu_state_post_swap_buffers` decides what our front
buffer object will be. There is only one answer. So return it as the
function result instead of making the caller figure it out.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3830>
It's always equal to `onscreen_native->next_frame` and we can't eliminate
that copy so easily. Removing the parameter removes all ambiguity about
where the next frame will come from.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3829>
Add meta_kms_impl_device_open_non_privileged_fd() that returns a
non-master file descriptor for a MetaKmsImplDevice.
It'll be required to implement wp_drm_lease_device_v1_send_drm_fd() in a
future commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
The manager keeps track of which connectors are leasable in general,
which connectors and resources are already part of a lease, and keeps
track of when leases get revoked.
When leasing out connectors, the required drm resources to drive the
connectors are included in the lease as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
When a plane is leased, it is assigned to a CRTC which is leased. When
trying to find a primary plane for a modeset, skip the assigned planes
on leased CRTCs to avoid sharing the resources with the leased process.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
This allows us to keep track when primary and cursor plane assignments
on a CRTC are unassigned. With this commit, all planes which are
assigned are actually in use and can't be assigned to anything else.
We'll make use of that fact when we search for a leasable primary plane.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
The lease_objects function takes connectors, CRTCs and planes which are
turned into a drm lease. The resulting lease can be revoked with
revoke_lease. With list_lessees the currently active leases can be
queried.
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
With leasing, we will give another client control over connectors but
they also need a CRTC to drive them. Those CRTCs won't be available to
the desktop/monitor-manager.
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
Add an environment variable (MUTTER_DEBUG_LEASE_CONNECTORS) that allows
set a ":" separated list of connector names as available for lease.
The names of the connectors can be found in "/sys/class/drm".
To illustrate it with an example, the names of the connectors and its
status can be fetched with this command:
$ for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done
DP-1: disconnected
DP-2: disconnected
DP-3: disconnected
DP-4: disconnected
DP-5: connected
DP-6: connected
DP-7: disconnected
eDP-1: connected
HDMI-A-1: disconnected
And, to set "DP-5" and "DP-6" available for lease, the environment
variable can be set like:
MUTTER_DEBUG_LEASE_CONNECTORS=DP-5:DP-6
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
This is intended to be used to filter out what connectors will be
available for lease, i.e. non-desktop ones.
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
