1
0
Fork 0
Commit graph

12016 commits

Author SHA1 Message Date
Dor Askayo
9eb38b4107 kms/impl-device: Add function to resume all devices
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3534>
2024-01-19 18:46:41 +00:00
Dor Askayo
ada4ac49fb kms/impl-device: Add function to handle device resumption
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>
2024-01-19 18:46:41 +00:00
Dor Askayo
98cdafdf0b kms/impl-device: Use enum for deadline timer state
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>
2024-01-19 18:46:41 +00:00
Leorize
8e39398d05 backends: Allow XKB model to be configured
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>
2024-01-18 18:51:42 +00:00
Florian Müllner
1ab4faaf18 place: Fix centering transients over parent
Transient dialogs are meant to be placed centered over their
parent. However as we don't use the DIALOG window type on
wayland, this currently only works for modal dialogs.

To fix this, also apply the policy to NORMAL windows for
wayland clients.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3533>
2024-01-18 16:07:15 +00:00
Kai-Heng Feng
8e58aa46ac gen_default_modes: Consider reduced blanking with lower pixelclock
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>
2024-01-18 12:12:06 +08:00
Shmuel Melamud
237e505cc7 clutter: Move ClutterCanvas to gnome-shell
Since StDrawingArea in gnome-shell is the only user of ClutterCanvas,
it is possible to move ClutterCanvas completely out of Mutter to
gnome-shell. This allows to remove another Cairo dependency from
Mutter.

This patch removes ClutterCanvas code from Mutter.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3470>
2024-01-17 11:58:47 +01:00
Sebastian Wick
41a7e8e3e0 build: Make g-ir-scanner warnings fatal when -werror is set
This should help catching problems with introspection in CI.

This also pulls out some common arguments to the gnome.generate_gir
call.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3528>
2024-01-17 09:26:00 +00:00
Bilal Elmoussaoui
2dd04f7cbe compositor: Use subclassing macros for Module
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3520>
2024-01-13 17:22:26 +00:00
Bilal Elmoussaoui
b1bc03a314 native: Use subclassing macros for InputDeviceToolNative
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3520>
2024-01-13 17:22:26 +00:00
Bilal Elmoussaoui
a79834a1ff x11: Use subclassing macros for InputSettingsX11
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3520>
2024-01-13 17:22:26 +00:00
Bilal Elmoussaoui
b1fc022ee6 x11: Use subclassing macros for InputDeviceX11
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3520>
2024-01-13 17:22:26 +00:00
Bilal Elmoussaoui
5387135220 x11: Use subclassing macros for InputDeviceToolX11
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3520>
2024-01-13 17:22:26 +00:00
Bilal Elmoussaoui
4f96b43222 x11: Use subclassing macros for CursorRendererX11
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3520>
2024-01-13 17:22:26 +00:00
Bilal Elmoussaoui
d90a938c17 core: Use subclassing macros for GestureTracker
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3520>
2024-01-13 17:22:26 +00:00
Bilal Elmoussaoui
59bdc69544 native: Use subclassing macros for InputSettingsNative
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3520>
2024-01-13 17:22:26 +00:00
Dallas Strouse
c8c5560916 backends/native: Main thread rt-scheduler: experimental feature no more
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>
2024-01-13 15:10:31 +01:00
Simon McVittie
ecdd2aeb85 workspace: Don't crash on invalid argument to meta_workspace_index
Mitigates: https://gitlab.gnome.org/GNOME/mutter/-/issues/2559
Mitigates: https://bugs.debian.org/1024438
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2774>
2024-01-12 15:24:14 +00:00
Sebastian Wick
399ffdfc88 kms/connector: Keep a ref to the KmsImplDevice instead of KmsDevice
The KmsImplDevice always exists as long as a KmsConnector exists. The
KmsDevice doesn't exist yet as long as the KmsImplDevice is not fully
initiallized. Going through the KmsImplDevice makes sure we always have
a valid reference and can release the device fd correctly when the
initialization fails.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3243
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3518>
2024-01-12 14:51:14 +00:00
Carlos Garnacho
7b232d9f65 wayland: Keep track of the "input focus" on MetaWaylandSeat
This is the unified focus (key, IM, pads, ...) for the focus window.
Just like MetaWaylandPointer and others keep track of the "current"
surface, this is the "current" surface for those (not necessarily
the focused surface, e.g. in the case of compositor grabs).

Since this unified focus will exist regardless of keyboard
capabilities (e.g. even if just for "logical" focus like IM/clipboard
that does not depend on input devices), it does not make sense
to trigger a focus sync on keyboard capability changes, the focus
is staying the same, we however need to focus the keyboard interface
to the already existing focus when the capability is enabled.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3511>
2024-01-12 14:39:17 +00:00
Carlos Garnacho
962eb9e054 wayland: Hook focus synchronization to MetaDisplay signals
Instead of letting the MetaDisplay be aware of the Wayland compositor,
and take care of updating its focus. This makes the MetaWaylandCompositor
able to track focus changes by itself, using MetaDisplay as the source
of truth.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3511>
2024-01-12 14:39:17 +00:00
Carlos Garnacho
38421b07c7 compositor: Use MetaWaylandCompositor API to drive focus synchronization
Use Wayland API directly here, and avoid using MetaDisplay API that will
go away.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3511>
2024-01-12 14:39:17 +00:00
Carlos Garnacho
a2d2e04d80 wayland: Use MetaWaylandCompositor API to drive focus synchronization
Keep this within the wayland code itself, and avoid poking MetaDisplay
API that will go away.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3511>
2024-01-12 14:39:17 +00:00
Carlos Garnacho
9383171958 wayland: Move Wayland focus synchronization code out of core
Handle focus synchronization in MetaWaylandCompositor itself. This
is so far plumbed so that MetaDisplay still drives focus synchronization
directly.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3511>
2024-01-12 14:39:17 +00:00
Carlos Garnacho
17d1d3abd8 compositor: Avoid special grab begin/end handling in MetaWindowDrag
This is already performed through the ClutterStage::is-grabbed property
being tracked. There is no need to do this ad-hoc.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3511>
2024-01-12 14:39:17 +00:00
Carlos Garnacho
54e4d1df79 x11: Defer ClutterStage focus actor change until window is focused
If we happen to be changing focus to a window *while* taking focus
away from Clutter widgetry, we would unintendedly trigger reentrance
in a way that the old focused window remained in focus, by asking
to focus the default focus window in an untimely manner.

To handle this reentrancy, delay dropping the Clutter key focus
until the window focus changed, so that the focus change will look
up the default focused window in the workspace, and find the up to
date one.

Fixes: ae102ee301 ("x11: Refactor ClutterStage key focus management")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3467>
2024-01-10 20:56:24 +01:00
Bilal Elmoussaoui
94f9d88371 x11: Drop error trap helpers
They are no longer that useful as they end up calling
mtk functions nowadays

Followup of https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3230

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3483>
2024-01-10 13:58:18 +00:00
Bilal Elmoussaoui
09b7cd9f4a x11/display: Don't try to retrieve xwindow of wayland windows
Trying to get the xwindow of a wayland only window would fail when
casting to a x11 window. Which happens as
meta_x11_display_set_input_focus is called whenever the focused
window changes, whether it is a wayland or x11 one

Fixes: bc9cd123e ("window: Move xwindow to WindowX11")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3506>
2024-01-09 23:51:37 +01:00
Bilal Elmoussaoui
5ad8a79823 display: Add a helper to retrieve associated xwindow
As we moved the xwindow property from Window to WindowX11 which is
not exposed as public API. So instead of exposing WindowX11,
the API is added to MetaX11Display which is already exposed.

This is only needed by gnome-shell for it tray icons support
https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/81f18d7d/src/shell-tray-icon.c#L67

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3211>
2024-01-09 18:59:36 +00:00
Bilal Elmoussaoui
0236506cff window: Move has_pointer_x11 to WindowX11
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3211>
2024-01-09 18:59:36 +00:00
Bilal Elmoussaoui
19a36b8879 window: Stop storing xtransient_for field
Instead retrieve the associated Window from the xwindow property.
Avoids having a vfunc to handle the get_transient_for differences
between Wayland and x11

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3211>
2024-01-09 18:59:36 +00:00
Bilal Elmoussaoui
5e098eadce window: Move user_time_window to WindowX11
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3211>
2024-01-09 18:59:36 +00:00
Bilal Elmoussaoui
9e150fda42 window: Move xgroup_leader to WindowX11
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3211>
2024-01-09 18:59:36 +00:00
Bilal Elmoussaoui
7d6e7773bf window: Make Window.set_transient_for a vfunc
So we can move the xgroup_leader to WindowX11. See next commit

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3211>
2024-01-09 18:59:36 +00:00
Bilal Elmoussaoui
c0685fe29b window: Move xclient_leader to WindowX11
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3211>
2024-01-09 18:59:36 +00:00
Bilal Elmoussaoui
bc9cd123e9 window: Move xwindow to WindowX11
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3211>
2024-01-09 18:59:36 +00:00
Bilal Elmoussaoui
d98b0eb71e window: Move xvisual to WindowX11
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3211>
2024-01-09 18:59:36 +00:00
Bilal Elmoussaoui
2a75661883 region: Move RegionBuilder to Mtk
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3501>
2024-01-09 18:47:34 +00:00
Bilal Elmoussaoui
fced59b33d region: Make Region.transform private
It is only used once in MetaWaylandSurface

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3501>
2024-01-09 18:47:34 +00:00
Bilal Elmoussaoui
9953704ceb region: Move RegionIterator to Mtk
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3501>
2024-01-09 18:47:34 +00:00
Bilal Elmoussaoui
cf8eb4944a region: Make make_region_border private
It is only used by the shadow factory and doesn't make sense to
have as part of mtk

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3501>
2024-01-09 18:47:34 +00:00
Bilal Elmoussaoui
39aeb81a8b region: Move Region.apply_matrix_transform_expand to Mtk
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3501>
2024-01-09 18:47:34 +00:00
Bilal Elmoussaoui
4d53e4d156 region: Move Region.crop_and_scale to Mtk
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3501>
2024-01-09 18:47:34 +00:00
Bilal Elmoussaoui
6e7d314e75 region: Move Region.scale to Mtk
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3501>
2024-01-09 18:47:34 +00:00
Bilal Elmoussaoui
4513abd584 region: Move rectangle helper macro to Mtk
Rename it to Rectangle prefix to avoid confusion with MtkRegion

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3501>
2024-01-09 18:47:34 +00:00
Bilal Elmoussaoui
6f9e75b6f2 boxes: Move Rectangle.is_adjacent_to to Mtk
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3501>
2024-01-09 18:47:34 +00:00
Bilal Elmoussaoui
fcc8cfff11 boxes: Move Rectangle.scale_double to Mtk
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3501>
2024-01-09 18:47:34 +00:00
Bilal Elmoussaoui
59457dff81 boxes: Move Rectangle.crop_and_scale to Mtk
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3501>
2024-01-09 18:47:34 +00:00
Peter Hutterer
b5e9279ea0 backends/x11: Fetch the tablet serial prop on device add
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>
2024-01-09 17:33:33 +00:00
Zander Brown
b1dd6973df workspace-manager: Accessors for layout-{columns,rows}
This will allow C code in shell to avoid going though `g_object_get`,
and in future GJS will also be able to take advantage giving a slender
yet not unwelcome boost to perf in some animations

(Semi relates to https://gitlab.gnome.org/GNOME/mutter/-/issues/3083)

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3351>
2024-01-09 16:38:25 +00:00