For tablet device, the tool was created when the "Wacom Serial IDs" prop
changed values. This property does not exist on the xf86-input-libinput
driver but v1.5.0 of that driver has a different property for the serial.
The serial is constant (the driver creates one X device per serial), so
we can fetch it after device creation and set it then. For earlier
versions of the driver we assign the random serial 0xffffffaa - good
enough to have at least a tool.
This fixes the crash in #3120 - clutter_event_motion_new()
overrides event->device to the tool's device (if any). Without a tool
motion events use the Virtual Core Pointer instead and our source device
is never added to the stage's priv->pointer_devices.
When we generate an crossing event (which uses the source device) we
fall afoul of an assert in clutter_stage_update_device() that expects
our source device to be in priv->pointer_devices.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/3120
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3383>
DRM's kms atomic code was updated to include an API to set the mouse
cursor hotspot. This has historically been missing in the atomic kms
which meant that the virtualized drivers which require mouse cursor
hotspot info to properly render had to be put on a deny list and
had to fallback to the legacy DRM kms code.
Implement the new hotspot API by checking whether the device supports
hotspot properties and if it does set them on the cursor plane. This
enables atomic kms on all virtualized drivers for kernels where
mouse cursor hotspots are in drm core.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3337>
Add META_KMS_PLANE_PROP_HOTSPOT_[X,Y] properties
to the MetaKmsPlaneProp enumeration, and
properly initialise them.
Also, add a convenience method in meta-kms-plane
(i.e., `meta_kms_plane_supports_cursor_hotspot`)
to check whether a plane supports hotspot
property setting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3337>
Based on the pressure curve control points sample a bezier curve and
then look up the pressure at that point of the curve.
We sample 256 points and do linear interpolation in between, this
strikes a balance between having to calculate the point for all
8K pressure points a modern pen supports while still giving us
reasonable detailed curves.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3158
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3399>
This keeps the existing ClutterBezier implementation but changes
the visible API to match the needs of the tablet tool pressure curve:
a bezier defined within a [0.0/0.0, 1.0/1.0] box,(sampled
into a set of x->y mappings for each possible pressure input x, and
a lookup function to get those values out of the curve.
This patch moves the internally-only functions to be statics and changes
meta_bezier_init() to take only the second and third control point, as
normalized doubles. Because internally we still work with integers, the
bezier curve now has an integer "precision" that defines how many points
between 0.0 and 1.0 we can sample.
The meta_bezier_rasterize() function calculates the x->y mapping for
each point on the bezier curve given the initial scale of the curve.
That value is then available to the caller via meta_bezier_lookup().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3399>
The ClutterBezier code was removed in
580d62b9b clutter: Remove unused Path related types
because it wasn't used anywhere. We do need a bezier curve for the
tablet tool pressure curve calculation though so let's move it
to the native backend and rename it to MetaBezier in the process.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3399>
This addresses the following race condition:
1. Window+MetaFrame are created non-fullscreen, _MUTTER_FRAME_EXTENTS
is initialized through widget measuring, accounting for frame.
2. Window and MetaFrame become fullscreen.
3. MetaFrameContent gets first size allocation, already fullscreen.
4. Borders were initialized to 0,0,0,0, become set to 0,0,0,0 correctly
reflecting fullscreen, however notify::borders is not emitted.
5. _MUTTER_FRAME_EXTENTS stays accounting for the frame extents.
It sounds sensible to have the borders initialized to a meaningful value,
so account for the first time the border would be set due to the content
being (re)sized, and let this first value trigger notify::borders resulting
in _MUTTER_FRAME_EXTENTS updates.
Since all later _MUTTER_FRAME_EXTENTS changes happen through content
resizes, we only have to cater for this initial handover between the
frame/content initialization paths done through widget measuring and
the later paths done through MetaFrameContent resizes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2937
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3476>
The test makes sure the YCbCr formats create the expected image and we
don't accidentally break it.
Like all wayland tests, this is now part of mutter/wayland, mutter/tty,
and mutter/kvm and will use either shm or dma-buf depending on which
suite is chosen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3371>
Finding the shm offset and shm stride for each plane is the main issue.
The rest is just creating multiple textures for each plane.
One assumption is that shm planes are always contiguous in memory so the
next plane comes directly after the size of the current plane.
The size of a plane is determined by the height and stride. There is
only a single stride parameter for shm buffers but we assume that the
first plane is always non-subsampled which gives us a number of "logical
elements" on one line (stride / bpp of the first plane). The stride of
the other planes is then the number of logical elements devided by the
subsampling factor and multiplied by the bpp of the plane.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3371>
The assumption is that all planes are always contiguous, and we don't
have any multi-plane formats where the first plane is subsampled.
The stride of the entire buffer is then just the stride of the first
plane and the stride of the other planes is derived from that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3371>
