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>
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>
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>
Otherwise a tablet in relative mode will never have a tool set and
nothing happens on motion events - meta_wayland_tablet_seat_update()
simply exits early for tablet proximity, button or motion events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3410>
Since meta_kms_impl_device_get_sync_file always returns the same
file descriptor referencing the same sync_file, this means the atomic
ioctl doesn't need to wait for any fences to signal. This is fine
because we already waited for the buffer to become idle before applying
the Wayland surface state.
Fixes the atomic commit ioctl spuriously synchronizing to the screen
cast paint (at least with the amdgpu driver), which could result in
the page flip missing its target scanout cycle.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3148
v2:
* Rename local variable to signaled_sync_file for consistency with new
function name
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3389>
It returns a file descriptor which references a signaled sync_file.
v2:
* Change function name and add Doxygen comment to hopefully make its
purpose a bit clearer (Ivan Molodetskikh)
v3: (Jonas Ådahl)
* Create sync_file from scratch via a syncobj, no buffer needed anymore
* Initialize priv->sync_file = 1 and use g_clear_fd in finalize
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3389>
`count_mode_setting_devices` was incorrect in both name and in function.
What it was actually doing was counting GPUs that had been registered with
the backend so far (during the `init_gpus` loop). What it was intended to
do was to count the number of `MetaRenderDeviceEglStream` instances, which
is the thing we're limited to only one of. So `count_mode_setting_devices`
would return zero whenever the first GPU initialized happened to be a
`MetaRenderDeviceEglStream`, which would in turn prevent
`MetaRenderDeviceEglStream` from successfully initializing. Seems it only
ever worked in the case of a hybrid system where the first GPU initialized
was GBM-based.
Now we count `MetaRenderDeviceEglStream` instances (zero or one) externally.
This allows initialization to succeed when it happens to be the first (or
only) GPU. And so `MUTTER_DEBUG_FORCE_EGL_STREAM=1` now works.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2905>
