mutter merge requestshttps://gitlab.gnome.org/GNOME/mutter/-/merge_requests2024-03-19T11:24:25Zhttps://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3667window-actor/wayland: Remove surface actors when destorying the window2024-03-19T11:24:25ZSebastian Wickwindow-actor/wayland: Remove surface actors when destorying the windowThe surface of the actor can get a new surface role immediately and be
added to a new parent. To make sure this works the surface has to be
removed from its current parent: the window actor that's destroyed.The surface of the actor can get a new surface role immediately and be
added to a new parent. To make sure this works the surface has to be
removed from its current parent: the window actor that's destroyed.https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3666cursor-renderer/native: Don't predict the dumb buffer stride2024-03-18T13:00:03ZJonas Ådahlcursor-renderer/native: Don't predict the dumb buffer strideThe stride of the dumb buffer isn't necessarily 4 * width even if the
bytes per pixel is 4, so lets not make that assumption.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2267951
----
Just a guess that it fixes the downstream...The stride of the dumb buffer isn't necessarily 4 * width even if the
bytes per pixel is 4, so lets not make that assumption.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2267951
----
Just a guess that it fixes the downstream bug. Can't really test it since I don't know of any way to override any dumb buffer stride.GNOME 46https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3665Draft: Add Support for Display Hardware/engine based adaptive sharpening.2024-03-18T11:32:36ZAdarsh G MDraft: Add Support for Display Hardware/engine based adaptive sharpening.**Summary:**
- This draft MR intends to provide basic support to the Display hardware based adaptive sharpening feature which can be found in [Introduce drm sharpening property](https://patchwork.freedesktop.org/series/129926/)
- User sp...**Summary:**
- This draft MR intends to provide basic support to the Display hardware based adaptive sharpening feature which can be found in [Introduce drm sharpening property](https://patchwork.freedesktop.org/series/129926/)
- User space is expected to provide filter strength value via the exposed CRTC property, kernel would apply required scalar and compute filter-coefficients w.r.t to user provided filter strength.
**Implementation in Mutter:**
**CRTC Support:**
- An UAPI as Pipe/CRTC property would be exposed to the user space to get required filter strength value ranging from 0-255, CRTC support is required from mutter.
**Options for user to enter the filter Strength value:**
- Currently provision for user has been provided to update the required value of filter strength with help of an environment variable "ADAPTIVE_SHARPNESS_FILTER_STRENGTH".
- A provision to Provide Filter strength via GNOME Shell's integrated debugger Looking Glass shall be made in the future commits to make it more user friendly.https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3650wayland/text-input: Don't crash on wrong parameters to delete_surrounding()2024-03-12T17:32:09ZJonas Dreßlerwayland/text-input: Don't crash on wrong parameters to delete_surrounding()The compositor should not crash when a client reports an incorrect cursor or
anchor position with its surrounding text, so warn and return instead of
asserting here.
This crash currently happens when pressing the OSKs backspace key afte...The compositor should not crash when a client reports an incorrect cursor or
anchor position with its surrounding text, so warn and return instead of
asserting here.
This crash currently happens when pressing the OSKs backspace key after gtk4
reported an outdated cursor/anchor position.https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649Draft: Implement support for tablet tool keybindings and actions2024-03-19T03:43:45ZPeter HuttererDraft: Implement support for tablet tool keybindings and actionsRequires https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/76 for the gsettings.
Sits on top of !3647
Notes on the implementation:
The approach I've chosen here is for stylus button mapped to a non-button actio...Requires https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/76 for the gsettings.
Sits on top of !3647
Notes on the implementation:
The approach I've chosen here is for stylus button mapped to a non-button action to create a `CLUTTER_BUTTON_PRESS/RELEASE` event with a clutter button of zero. That one is filtered during `meta_display_handle_event()` and only makes it as far as the new `MetaToolActionMapper`. I'm not sure what the fallout of a zero button clutter event is within mutter and whether that will blow something else up.
For the new action mapper I started with duplicating the pad action mapper but then decided to implement a parent `MetaTabletActionMapper` for both. More boilerplate but overall a less duplicated approach and I can envision this maybe being used as a more generic action mapper for any buttons. I still consider myself a GObject newb so there's probably a few issues with the structure there.
`backends/native: Apply stylus button mappings before anything else` fixes a real bug: currently the stylus buttons are used as-is in clutter despite carrying a mapped button, e.g. mapping `BTN_STYLUS` to right-click only affects the behaviour in clients but not in gnome-shell where it remains the (default) middle button.
The new `MetaToolActionMapper` needs to read the settings which is... tricky. The button mapping happens when the Clutter event is generated. I'm not sure what black magic is required to get to the input settings but it turns out they're stored in the tool via a GQuark so right now I'm abusing that. Any hints on how to do this better would be appreciate.
Draft because this needs more testing, esp. in X11.
For testing:
```
$ STYLUS_SERIAL=99800b93
$ gsettings set org.gnome.desktop.peripherals.tablet.stylus:/org/gnome/desktop/peripherals/stylus/$STYLUS_SERIAL/ button-action keybinding
$ gsettings set org.gnome.desktop.peripherals.tablet.stylus:/org/gnome/desktop/peripherals/stylus/$STYLUS_SERIAL/ button-keybinding '<Control><Alt>t'
$ gsettings set org.gnome.desktop.peripherals.tablet.stylus:/org/gnome/desktop/peripherals/stylus/$STYLUS_SERIAL/ secondary-button-action switch-monitor
```
cc @carlosg, @Joshua-Dickenshttps://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3644wayland: Preserve serial for all pressed keys2024-03-07T13:49:32ZCarlos Garnachowayland: Preserve serial for all pressed keysThe current code checking keyboard serials for popup/grab
validation is a bit simple, tracking one key press exclusively.
This may break expectations if a client uses a serial
corresponding to a previous key that is still pressed.
Keep ...The current code checking keyboard serials for popup/grab
validation is a bit simple, tracking one key press exclusively.
This may break expectations if a client uses a serial
corresponding to a previous key that is still pressed.
Keep track of the serials corresponding to all pressed keys,
and ensure these are reset across focus changes, since the
validity of those serials is already outdated. The code does
still keep track of a single (last) key release serial, since
the validity lifetime is somewhat underdefined with those if
we keep track of multiple keys simultaneously.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3267https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3639Draft: Connect "highest-scale-monitor-changed" signal for Xwayland surfaces2024-03-07T14:47:00ZOlivier FourdanDraft: Connect "highest-scale-monitor-changed" signal for Xwayland surfacesWith the fractional scale protocol in Wayland, the clutter actor's
transform may change.
`MetaWindowActorWayland` would connect `"highest-scale-monitor-changed"` to
`clutter_actor_notify_transform_invalid()` so that the transformation...With the fractional scale protocol in Wayland, the clutter actor's
transform may change.
`MetaWindowActorWayland` would connect `"highest-scale-monitor-changed"` to
`clutter_actor_notify_transform_invalid()` so that the transformation is
updated when needed, but this was missing in the X11 equivalent.
Connect `"highest-scale-monitor-changed"` for `MetaWindowActorX11` as well
so that Xwayland's X11 windows can use fractional scale if ever
implemented in Xwayland.
Similar to what MetaWaylandShellSurface does, connect the signal
`"highest-scale-monitor-changed"` to the handler
`meta_wayland_surface_notify_highest_scale_monitor()` so that
`Xwaylandsurface` can be notified of the fractional scale changes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3326https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3631wayland/popup: Only close popups if press count drops from 1 to 02024-03-02T00:01:28ZJonas Dreßlerwayland/popup: Only close popups if press count drops from 1 to 0We close wayland popups when a button or touch release happens outside
of the grab, except we don't want to close them when that button release is
actually the release of the press that was opening the grab in the first
place.
We never ...We close wayland popups when a button or touch release happens outside
of the grab, except we don't want to close them when that button release is
actually the release of the press that was opening the grab in the first
place.
We never see the press event that opened the grab, so the first event we
see is actually always a release. Make sure to not close the popup on that
event, and instead only close the popup if we see the press count drop from
1 to 0.
This fixes a bug where popup would close right after they open. To
reproduce, click to open a popup, hold pressed and move the cursor over
shell chrome, then release. Or alternatively test with a popup that gets
opened with a long-press gesture (eg. long touch long press on libadwaita
tabs), just doing the touch long-press and then release.https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3626Draft: onscreen/native: Pass sync_file from EGL via KMS update2024-02-29T14:52:06ZMichel DänzerDraft: onscreen/native: Pass sync_file from EGL via KMS updateWith the nvidia driver, this ensures correct synchronization of KMS
atomic commits with mutter's compositing GPU work.
With other drivers, it might avoid over-synchronization in some cases.
a84e6927 is from https://gitlab.gnome.org/GNO...With the nvidia driver, this ensures correct synchronization of KMS
atomic commits with mutter's compositing GPU work.
With other drivers, it might avoid over-synchronization in some cases.
a84e6927 is from https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3300.https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3616monitor: Simplify scale selection2024-03-01T16:45:45ZDaniel van Vugtdaniel.van.vugt@canonical.commonitor: Simplify scale selectionPrecalculate what the perfect scaling factor would be to achieve
the target DPI and just compare the available scaling factors to that.
Same results, all tests still pass.Precalculate what the perfect scaling factor would be to achieve
the target DPI and just compare the available scaling factors to that.
Same results, all tests still pass.https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3609cogl: Disable mipmaps for i9152024-03-18T23:58:06ZBalló Györgycogl: Disable mipmaps for i915The mipmap support in the i915 driver is buggy, causing rendering issues. Add a driver-specific quirk to disable use of mipmaps.
Mesa issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10410
Closes: https://gitlab.gnome.org/GNOME...The mipmap support in the i915 driver is buggy, causing rendering issues. Add a driver-specific quirk to disable use of mipmaps.
Mesa issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10410
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3232https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3607core: Include a small subset of xcursor in-tree2024-03-19T11:26:48ZBilal Elmoussaouibil.elmoussaoui@gmail.comcore: Include a small subset of xcursor in-treeFor a Wayland only build, we would like to avoid linking against
libXcursor which on it turn, links back to some of the X11 deps.
In order to achieve that, we include a small subset of xcursor. The code kept as it was with only slightly ...For a Wayland only build, we would like to avoid linking against
libXcursor which on it turn, links back to some of the X11 deps.
In order to achieve that, we include a small subset of xcursor. The code kept as it was with only slightly code style changes and replacing the internal `XcursorBool` with `gboolean`
In case Mutter is built with X11 or with both Wayland & X11, we link
against libXcursor and don't make use of the in-tree implementation.
This patch mimics what [GTK 4](https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/wayland/cursor/xcursor.c) do by shipping an in-tree copy of xcursor.
Especially that libwayland-cursor does not provide an alternative to xcursor itself.
Helps #2272GNOME 47https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3605Draft: Add more Struts and Struts with monitor changes tests2024-03-13T15:22:41ZSebastian WickDraft: Add more Struts and Struts with monitor changes testsRebased version of !3014 with all the window management changes dropped.
This extends the stacking tests and gives us a reproducer for the long-standing https://gitlab.gnome.org/GNOME/mutter/-/issues/1627.Rebased version of !3014 with all the window management changes dropped.
This extends the stacking tests and gives us a reproducer for the long-standing https://gitlab.gnome.org/GNOME/mutter/-/issues/1627.https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3604wayland/text-input: Reset surrounding text values by focus change2024-03-07T13:20:45ZTakao Fujiwarawayland/text-input: Reset surrounding text values by focus changezwp_text_input_v3_set_surrounding_text() does not support null string
but mutter need to know which input focus supprots the surrounding
text feature and now mutter resets the surrounding text values by
focus change so that the null stri...zwp_text_input_v3_set_surrounding_text() does not support null string
but mutter need to know which input focus supprots the surrounding
text feature and now mutter resets the surrounding text values by
focus change so that the null string indicates the curent input focus
does not support the surrounding text feature.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2712https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3602edid: Make libdisplay-info hard dep2024-03-08T19:00:28ZSebastian Wickedid: Make libdisplay-info hard depWhat it says on the box.
It also starts using libdisplay-info data types instead of our own. Still uses some low-level API so output names stay stable. Material for the next cycle.What it says on the box.
It also starts using libdisplay-info data types instead of our own. Still uses some low-level API so output names stay stable. Material for the next cycle.GNOME 47https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3600Draft: Implement version 2 of text_input_v3 protocol2024-02-20T13:47:34ZCarlos GarnachoDraft: Implement version 2 of text_input_v3 protocolRelated: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/282Related: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/282https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596Store the monitor layout mode in monitors.xml and migrate existing configs2024-02-27T10:11:39ZJonas DreßlerStore the monitor layout mode in monitors.xml and migrate existing configsThis MR gets the monitor config ready for enabling `scale-monitor-framebuffer` by default:
- start out by removing the old migration code for migrating from v1 monitor.xml files, this migration (has been done in 2017)[https://gitlab.gno...This MR gets the monitor config ready for enabling `scale-monitor-framebuffer` by default:
- start out by removing the old migration code for migrating from v1 monitor.xml files, this migration (has been done in 2017)[https://gitlab.gnome.org/GNOME/mutter/-/commit/bc3162460fa9da6bcadb60cec7318eef24e4000a] (so GNOME 3.26 includes it), and even RHEL 7 (with GNOME 3.28) has the new format already
- make the layout mode a more explicit part of monitor configurations: Add the layout mode to `MetaMonitorsConfigKey` so that we can store and lookup the same configuration twice depending on layout mode.
- add a `<layout_mode>` key to the `<configuration>` blocks in monitors.xml, so that we can have the same explicit storing in monitors.xml
- since we have no way of knowing which layout mode existing configurations are in, introduce some detection code that detects the layout mode in case we didn't see a `<layout_mode>` entry. If the detection finds that an existing configuration can be interpreted as both LOGICAL and PHYSICAL layout, a `MetaMonitorsConfig` gets created for each layout mode.
- finally, since this is the path that most users will go through when updating mutter, add "best effort" conversion code to migrate monitor configurations with scaled monitors from PHYSICAL to LOGICAL layout mode. It's introducing two algorithms to migrate 1-dimensional lines of monitors and simple 2-dimensional layouts
- and in the end obviously add various tests to ensure all of these things are workinghttps://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567Let scaling-aware Xwayland clients scale themselves with "scale-monitor-frame...2024-03-09T22:47:01ZJonas DreßlerLet scaling-aware Xwayland clients scale themselves with "scale-monitor-framebuffers"Based on [this branch](https://gitlab.gnome.org/jadahl/mutter/-/commits/wip%2Fx11-ui-scaling) from Jonas Ådahl, main commit:
```
Apply custom scaling to Xwayland
When monitor framebuffers are scaled, this special cases Xwayland and...Based on [this branch](https://gitlab.gnome.org/jadahl/mutter/-/commits/wip%2Fx11-ui-scaling) from Jonas Ådahl, main commit:
```
Apply custom scaling to Xwayland
When monitor framebuffers are scaled, this special cases Xwayland and
sends output regions in a way that Xwayland think everything is N times
as large as the logical region, where N is the ceil of the max monitor
scale.
This is done by introducing a "stage" vs "protocol" coordinate space for
X11, where the "protocol" coordinate space is "stage" multiplied by a
scaling factor.
```
Goes with https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/merge_requests/353https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3564Draft: backends/native: Support XKB Keysyms for pointer control2024-02-06T22:00:07ZPeter HuttererDraft: backends/native: Support XKB Keysyms for pointer controlXKB has two approaches to pointer control:
The PointerKeys actions in Xorg (search for 'PtrBtn' in your
keymap) which are interpreted and handled by the XKB implementation.
But only in Xorg, libxkbcommon does not support thoes actions an...XKB has two approaches to pointer control:
The PointerKeys actions in Xorg (search for 'PtrBtn' in your
keymap) which are interpreted and handled by the XKB implementation.
But only in Xorg, libxkbcommon does not support thoes actions and
mutter native has a hardcoded implementation of the mousekeys feature
featuring NumLock and the keypad.
XKB also defines a number of keysyms representing pointer movements and
button events, e.g. `XKB_KEY_Pointer_UpRight` and `XKB_KEY_Pointer_Button1`.
Hook up (some of) those keysyms to their intended meaning so that a key
sending the keysym `XKB_KEY_Pointer_Button1` triggers a left button click.
This allows users to assign arbitrary keys to pointer actions, useful in
particular for devices with specific keys that (should) emulate pointer
events.
One possible option is this setup ([explainer](https://who-t.blogspot.com/2020/09/user-specific-xkb-configuration-putting.html)) which assigns WASD for pointer movement
and Q/E for left/right button clicks:
```
$ export XDG_CONFIG_HOME=$HOME/.config
$ mkdir -p $XDG_CONFIG_HOME/xkb/{rules,symbols,types}
$ cat > $XDG_CONFIG_HOME/xkb/symbols/pointerkeys <<EOF
partial modifier_keys
xkb_symbols "wasd" {
key <AD02> { [ NoSymbol, NoSymbol, Pointer_Up ], type[Group1] = "LEVEL_THREE_NUMLOCK" };
key <AC01> { [ NoSymbol, NoSymbol, Pointer_Left ], type[Group1] = "LEVEL_THREE_NUMLOCK" };
key <AC02> { [ NoSymbol, NoSymbol, Pointer_Down ], type[Group1] = "LEVEL_THREE_NUMLOCK" };
key <AC03> { [ NoSymbol, NoSymbol, Pointer_Right ], type[Group1] = "LEVEL_THREE_NUMLOCK" };
key <AD01> { [ NoSymbol, NoSymbol, Pointer_Button1 ], type[Group1] = "LEVEL_THREE_NUMLOCK" };
key <AD03> { [ NoSymbol, NoSymbol, Pointer_Button3 ], type[Group1] = "LEVEL_THREE_NUMLOCK" };
};
EOF
$ cat > $XDG_CONFIG_HOME/xkb/types/numlock <<EOF
default partial xkb_types "level3" {
type "LEVEL_THREE_NUMLOCK" {
modifiers = Shift + NumLock;
map[None] = Level1;
map[Shift] = Level2;
preserve[Shift] = Shift;
map[NumLock] = Level3;
level_name[Level1] = "Base";
level_name[Level2] = "Shift";
level_name[Level3] = "NumLock";
};
};
EOF
$ cat > $HOME/.config/xkb/rules/evdev << EOF
! option = symbols
pointerkeys:wasd = +pointerkeys(wasd)
! option = types
pointerkeys:wasd = +numlock(level3)
// Include the system 'evdev' file
! include %S/evdev
EOF
```
Test with the "xkbcli interactive-evdev" tool to ensure it takes effect
first, then enable via the `pointerkeys:wasd` option:
```
$ gsettings set org.gnome.desktop.input-sources xkb-options "['pointerkeys:wasd']"
```
cc @bentiss
---
This is mostly a PoC for now unless there's more interest in it. Related [libxkbcommon issue #4348](https://github.com/xkbcommon/libxkbcommon/issues/438)https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3558Draft: wayland: Implement the WM "gestures" protocol2024-02-02T16:32:06ZCarlos GarnachoDraft: wayland: Implement the WM "gestures" protocolThis is a generic WM action system, based on user intent,
and leaving the interpretation to the compositor.This is a generic WM action system, based on user intent,
and leaving the interpretation to the compositor.