For now, this function only enables the deadline timer in case it was
inhibited. This would result in an attempt to use the deadline timer
again after a device is resumed.
If the conditions that resulted in the timer becoming inhibited
remain, it is expected to return to this state after the next frame
and before being armed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3534>
The "disabled" state indicates that the deadline timer is disabled
for the lifetime of the device, while the "inhibited" state indicates
that it is disabled temporarily for the device.
This distinction is needed to handle each state differently in a
following commit. For now, only "disabled" is used.
No change in behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3534>
This allows GNOME Shell to communicate the user desired XKB model
to the compositor instead of sticking with the pc105 default.
Particularly useful for those with a custom keyboard layout/irregular
keyboards.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2760>
Some panels only support fixed resolutions and fixed refresh rate with reduced blanking:
Established Timings I & II: none
Standard Timings: none
Detailed Timing Descriptors:
DTD 1: 2560x1600 120.001823 Hz 8:5 203.283 kHz 552.930000 MHz (345 mm x 215 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 6 Vback 85 Vpol N
DTD 2: 2560x1600 48.000295 Hz 8:5 81.312 kHz 221.170000 MHz (345 mm x 215 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 6 Vback 85 Vpol N
...
Minimum Pixel Clock: 552922 kHz
Maximum Pixel Clock: 552922 kHz
When using mirror mode, resolutions like 2560x1440 120Hz can be too high
to meet the pixelclock limitation, so 2560x1440 90Hz is selected
instead. However, the panel only supports 120Hz so using 90Hz result to
failed mode set.
So add reduced blanking to fallback mode, so correct refresh rate can be
used.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3449>
To paraphrase jadahl: we have a dedicated KMS thread now, which also
has realtime scheduling enabled unconditionally. realtime scheduling
on the main thread isn't too great of an idea, considering GC can
take a hot minute.
And to quote rmader: we most likely won't be able to make the main
thread rt as long as we use GJS and thus have GC.
So let's get rid of it! It's just been breaking things anyways.
This just ignores the setting; we'll fully remove it when GNOME 46
comes around.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3296>
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>
There might not be a single plane that is "for" a CRTC, so remove the
API that made it appear as if it did. The existing users only cared if
there was some plane for said CRTC, so replace the getters with API that
just checks the existance at all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
When there are a set of primary planes, and a set of CRTCs, where each
plane can be used on multiple CRTCs, we need to make sure that when we
mode set and page flip, each CRTC gets assigned an individual plane that
isn't used with any other CRTC.
Do this during the monitor resource assignments that sets up later to be
applied configurations of the mode setting objects, but with the new
hooks into the backend, so that we don't need to teach the monitor
config manager about planes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2398
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
This means that it doesn't necessarily mean what transform / rotation
the hardware resource gets, e.g. it instead represents the logical
transform related to the configured mode. This allows us to postpone
checking the plane capabilities until later (as rotation capabilities
depends is a plane property), when a plane has been assigned.
This was in practice already handled when configuring the
transform-via-offscreen case, handled when creating the view, and the
mode setting configuration.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
When we're configuring monitors, allow backends to add backend specific
assignments during resource assignment (mapping connectors and CRTCs
etc).
This will later allow the native backend's KMS monitor resources to
assign a primary plane and optionally a cursor plane during
configuration. This will then dictate what plane will be used for
primary plane updates, as well as cursor updates, until reconfigured
again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
Musl doesn't seem to include this by default so explicitly including it
should fix compilation on Musl.
Tested with Clang 16/17 and GCC 14.
Error:
src/backends/meta-fd-source.c:70:3: error: call to undeclared function 'close'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
close (fd_source->poll_fd.fd);
^
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3078
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3455>
