The min distance to the right/bottom edge depends on Wayland concepts
(wl_fixed_t) and eventually geometry scale. Move the logic the Wayland
side of the pointer constraints machinery to avoid the backend trying to
figure this out without the proper data.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2460>
There were some coordinate nudging to avoid running into Clutter
floating point math issues related to coordinate transformations. Over
the years these things have improved, especially with the move to
graphene, so remove the old work around.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2460>
The ImplDeviceAtomic converts the MetaKmsPlaneRotation back to the
concrete KMS value. The MetaMonitorTransform is always directly
converted to a MetaKmsPlaneRotation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2379>
Updating the PropTable has the side effect that the parse callback now
also gets called on hotplug but it is used to initialize data. The parse
callbacks are moved to the read_state functions which are aware if this
is an initializing call or just an update.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2379>
We don't make use of the refresh rate in any useful way in the X11, and
in this case we just ended up with warnings since the refresh rate was
NaN. Fix this by making it 0.0 to mean "no refresh rate". This also is
what 'xrandr' itself reports.
Fixes warnings when launching 'mutter --x11' in Xvfb.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2434>
This adds a minimalistic fullscreen direct scanout test case, that runs
on vkms. It doesn't use EGL, and it uses uninitialized memory, thus it
lacks any kind of implicit synchronization, but it does test that the
scanout selection paths are working.
What is tested is:
* DMA buffer allocated using gbm on top of VKMS
* Buffer passes a mode setting TEST_ONLY check
* Paint is omitted
* Correct buffer active in KMS after presentation
What isn't yet tested:
* Implicit synchronization related behavior
* Presented pixel content
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2417>
The property doesn't necessarily exist when using drivers that doesn't
support atomic mode setting, and the way it worked will break night
light and other gamma related features. This makes things use the gamma
length; if it is higher than 0, it definitely supports it one way or the
other, i.e. GAMMA_LUT with the atomic backend, and drmModeCrtcSetGamma()
with the legacy/simple backend.
Fixes: 364572b95c
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2287
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2435>
It doesn't depend on whether the CRTC is active or not, so always read
it. This is also useful to know whether a CRTC supports gamma, before it
is being turned on, without relying on the existance of properties.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2435>
Mutter makes use of a gsettings scheme that comes from
gnome-settings-daemon to check for the screen orientation.
In use cases where gnome-settings-daemon is not available,
this would lead to a crash as the key doesn't exists
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2398>
The monitors settings such as the privacy screen property is propagated
to the monitors via kms updates, however during initialization and
on monitors changes, we end up clearing the pending KMS updates because
such settings are added to the queue before the backend has fully
initialized the monitors, and this may lead to discarding all the
pending updates, including the one we've just planned.
To avoid this, move settings applications after we've both initialized
the backend and notified it about changes.
Also avoid to try set the settings during actual initialization, but
delay that after post-init.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2372>
'kms/impl-device/simple: Get the buffer handle from MetaDrmBuffer'
changed how fb ids are generated, but it only made it fully work with
atomic mode setting. For legacy/simple mode setting, it only handled the
primary plane buffer, not the hardware cursor.
Fix this by making sure the fb id is generated also in the legacy mode
setting case.
Fixes: ea39142da2
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2250
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2397>
With the unthrottled input emission, we ended up often getting the
cursor updates long before any damage had been posted, meaning that if
you moved around the mouse pointer where the mouse had a high enough
refresh rate, we'd effectively stall the screen cast stream by only
sending cursor updates and nothing else.
Fix this by scheduling an update when we get a cursor update, then
sending a cursor-only frame after any damage and relayout has been
processed, but only if there is no queued damage that will cause an
actual repaint.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2393>
This handle is used by the legacy KMS API; lets avoid having to have GBM
specific code where this is done by letting the MetaDrmBuffer API, that
already has this information, expose it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2275>
DMA buffers might be allocatable, but it doesn't mean the driver doesn't
fail when we try to allocate a buffer with an implicit modifier. Using
the proprietary NVIDIA driver for example, it will fail. Lets catch this
up front and avoid advertising DMA buffer support when we know it won't
work.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2383>
MetaCursorRendererNative only updates the cursor state when the
underlying texture changes. The cursor scale and transform do not
trigger updates. This results in wrong cursor orientations on rotated
displays. Use both texture changes and scale and transformation changes
to figure out when to update the cursor state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2363>
We rather confusingly still call a secondary display card that is
GPU-less (DisplayLink or other basic KMS device) a "secondary GPU",
so just because secondary_gpu_state is non-NULL doesn't mean we
can use it for rendering. The clearest indication of this is when
there is no EGL surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2341>
Since devices may be multiple things now, check all capabilities in order
to ensure all aspects of the device are correctly configured.
This change does the following observations:
- Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad'
settings path. The regular pointer settings path is left for all
non-touchpads.
- Devices that are both a tablet and a touchscreen prefer the tablet
relocatable schema. This works for both aspects as the touchscreen
schema is a subset of the tablet one.
Other than that it's a rather boring, even if verbose search and replace.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
We do not need to open code the ClutterInputDeviceType fetching from a
libinput_device, since we already created a native ClutterInputDevice that
has the right type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
