mutter issueshttps://gitlab.gnome.org/GNOME/mutter/-/issues2024-01-03T10:15:35Zhttps://gitlab.gnome.org/GNOME/mutter/-/issues/3189Dragging application across workspaces that contain other applications result...2024-01-03T10:15:35ZFabrizio SorbaDragging application across workspaces that contain other applications results in a different application been dragged### Affected version
Ubuntu 23.10.
GNOME 45.
Xorg.
The issue occurs also with extensions disabled.
### Bug summary
When dragging an application (using the shortcut Shift+Ctrl+Alt+Arrow) across a workspace that contain other applications...### Affected version
Ubuntu 23.10.
GNOME 45.
Xorg.
The issue occurs also with extensions disabled.
### Bug summary
When dragging an application (using the shortcut Shift+Ctrl+Alt+Arrow) across a workspace that contain other applications, the application looses focus and one of the other workspace's applications is dragged instead.
### Steps to reproduce
1. Open an application (App1) on Workspace 1 (e.g. gedit,...).
2. Open an application (App2) on Workspace 2 (e.g. gedit, firefox,...).
3. Drag App1 to Workspace 3 hitting the shortcut Shift+Ctrl+Alt+R-arrow 2 times.
### What happened
App1 has moved to Workspace 2 and App2 has moved to Workspace 3.
### What did you expect to happen
App1 should have moved to Workspace 3 and App2 should still be on Workspace 2.
### Relevant logs, screenshots, screencasts etc.
![Screencast_from_2023-12-03_11-51-50](/uploads/ae4b73aea3101b150b2fbb8b00ef8fa7/Screencast_from_2023-12-03_11-51-50.webm)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3186[Wayland][Nvidia Optimus] input stutter while using nvidia as primary gpu2024-02-21T10:31:04ZSolDev69[Wayland][Nvidia Optimus] input stutter while using nvidia as primary gpu<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
ArchLinux, mutter 45.1-1, wayland session
<!--
Provide at le...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
ArchLinux, mutter 45.1-1, wayland session
<!--
Provide at least the following information:
* Your OS and version: ArchLinux
* Affected Mutter version: 45.1
* Does this issue appear in XOrg and/or Wayland: Wayland
-->
### Bug summary
strange "input lag", don't really know how to describe it, see the video below at around the 1:24 mark
### Steps to reproduce
1. Setup a clean install of arch on an Nvidia Optimus laptop (I have an Acer Nitro 5)
2. Install nvidia proprietary and GNOME
3. `systemctl enable nvidia-hibernate.service nvidia-resume.service nvidia-persistenced.service nvidia-suspend.service nvidia-powerd.service` + enable modesetting
4. Following [this](https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562), add `ENV{DEVNAME}=="/dev/dri/card1", TAG+="mutter-device-preferred-primary"` to /etc/udev/rules.d/61-mutter-primary-gpu.rules
5. `sudo touch /etc/udev/rules.d/61-gdm.rules`
6. Reboot and plug in a monitor since the laptop monitor will probably not display anything (this is likely another issue), close the laptop lid, and plug in a keyboard and mouse
7. Set up [Nvidia Optimus](https://wiki.archlinux.org/title/NVIDIA_Optimus#Use_NVIDIA_graphics_only) on XOrg, idk if this does anything but it seems to help probably due to xwayland
8. Try using the wayland session, you will likely encounter this issue
### What happened
![Screencast_from_2023-12-01_18-16-44](/uploads/be60864f230434a12ad63fe489fb31ae/Screencast_from_2023-12-01_18-16-44.webm)
### What did you expect to happen
Typing to work normally like on Mesa drivers
<!--
What did you expect Mutter to do?
-->
### Relevant logs, screenshots, screencasts etc.
See above
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3185Weird Shadow at the Corners when Trying to use Rounded Corners2023-12-04T07:02:19Zitsmenewbie03Weird Shadow at the Corners when Trying to use Rounded Corners### Info
- OS: Ubuntu 22.04
- Gnome Version: 42.9
- Kitty Version: kitty 0.31.0 created by Kovid Goyal
```
$ dpkg --get-selections | grep mutter
gir1.2-mutter-10:amd64 install
libmutter-10-0:amd64 hold
mutter-common ...### Info
- OS: Ubuntu 22.04
- Gnome Version: 42.9
- Kitty Version: kitty 0.31.0 created by Kovid Goyal
```
$ dpkg --get-selections | grep mutter
gir1.2-mutter-10:amd64 install
libmutter-10-0:amd64 hold
mutter-common hold
```
### The problem
I recently tried `kitty` so I could support ligatures on my terminal as I've been using neovim for coding. I am using [mutter-rounded](https://github.com/yilozt/mutter-rounded) to have a nice looking rounded windows and it also comes with a blur feature which looks awesome for me. It works good on the built-in apps like `Files` and also on the built-in `Terminal`. However, it kinda looks a bit odd on `kitty`.
> This looks normal
![Screenshot_from_2023-12-01_19-15-07](/uploads/987fd3f7aa5b1feb290d19f13300458c/Screenshot_from_2023-12-01_19-15-07.png)
> But the problem is at the corners
![Screenshot_from_2023-12-01_19-15-36](/uploads/7eed5cc36a2e4ffd3ff18f784ca511a6/Screenshot_from_2023-12-01_19-15-36.png)
> If you take a closer look at the bottom corners of the window you can see my problem.
![image](/uploads/70943e0695588cbe7d2fd64c1a8efb22/image.png)
### Note
> I am not an experienced linux user, I recently got into it because I want to try [bun](bun.sh). So if there is still missing information, please guide me on how I can provided it.https://gitlab.gnome.org/GNOME/mutter/-/issues/3184Cursor is now just a grey square in mutter 46 when using cursor theme without...2024-03-25T11:45:54ZDaniel van Vugtdaniel.van.vugt@canonical.comCursor is now just a grey square in mutter 46 when using cursor theme without CSS cursor names![Screenshot_from_2023-12-01_13-41-42](/uploads/e8c6808592553dab45caccdad4a2532d/Screenshot_from_2023-12-01_13-41-42.png)
Failing: 9f89421ef5abfe5143a777aa33eee308e81a7055
Working: a2a4067e07311e9f74ac8744027601ccba69c496
Regression...![Screenshot_from_2023-12-01_13-41-42](/uploads/e8c6808592553dab45caccdad4a2532d/Screenshot_from_2023-12-01_13-41-42.png)
Failing: 9f89421ef5abfe5143a777aa33eee308e81a7055
Working: a2a4067e07311e9f74ac8744027601ccba69c496
Regression started in: d970c9db1abdb0e1f26aeff43518265471ba303bhttps://gitlab.gnome.org/GNOME/mutter/-/issues/3181Moving window using touchscreen causes freeze on Wayland and xorg2023-12-09T21:27:49ZrahmanshaberMoving window using touchscreen causes freeze on Wayland and xorg<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
* Fedora 38
* GNOME Shell version 44.5
* Using Wayland
* This...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
* Fedora 38
* GNOME Shell version 44.5
* Using Wayland
* This issue happen without extensions
### Bug summary
When moving a window using the touchscreen by touch on window bar and drag causes freezes and touching anything else in the UI doesn't do anything.
It unfreezes when i attach a mouse and move the mouse. It's happening both qt and gtk apps
### Steps to reproduce
<!--
1. open any app
2. hold the window title bar and drag it
3. ...
-->
### What happened
Whole shell/ screen freezes
### What did you expect to happen
<!--
What did you expect Mutter to do?
-->
### Relevant logs, screenshots, screencasts etc.
here is a video showing the freeze, i demonstrated using VLC.
Note: I tested with GTK apps and still frezzes
[fe.mkv](/uploads/4b2512420875b8db4553064867d7434d/fe.mkv)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3180<Super><Shift>Escape keyboard shortcut do not work.2023-11-28T12:36:51ZMaciej Błędkowski<Super><Shift>Escape keyboard shortcut do not work.### Affected version
Fedora Linux 39 (Workstation Edition) x86_64
GNOME 45.1
XOrg
### Bug summary
I have bound `<Super><Shift>Escape` to "Move window to workspace 1" in Gnome settings. The problem is that this shortcut do not work.
I...### Affected version
Fedora Linux 39 (Workstation Edition) x86_64
GNOME 45.1
XOrg
### Bug summary
I have bound `<Super><Shift>Escape` to "Move window to workspace 1" in Gnome settings. The problem is that this shortcut do not work.
In `xev` when I use this shortcut I get the following:
```console
FocusOut event, serial 38, synthetic NO, window 0x3a00001,
mode NotifyGrab, detail NotifyAncestor
FocusIn event, serial 38, synthetic NO, window 0x3a00001,
mode NotifyUngrab, detail NotifyAncestor
```
I found that in Mutter, this shortcut is bound to `cancel-input-capture`, so I created that value in dconf and set it to ['']; but it did not solve the problem.
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3177nvidia-drm: Failed to initialise accelerated framebuffer sharing: No EGL disp...2024-01-08T01:36:02ZTim Kanenvidia-drm: Failed to initialise accelerated framebuffer sharing: No EGL display (dual GPU configuration)<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
UPDATE: Turns out this only affects GDM. Stopping the GDM ser...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
UPDATE: Turns out this only affects GDM. Stopping the GDM service and starting a gnome-session directly from the console works as expected. I probably should have posted this as a GDM issue.
```
Fedora 39
Gnome 45.1
Kernal 6.5.12-300.fc39.x86_64
nVidia driver 535.129.03
```
### Bug summary
<!--
Provide a short summary of the bug you encountered.
-->
### Steps to reproduce
I have a multiple GPU setup on this machine, running Fedora 39
The primary interface is an RX 580 running amdgpu drivers
The secondary interface is a GTX 960 running one of nvidia (proprietary) or nouveau as required
I have multiple boot profiles to blacklist the appropriate drivers depending on my needs. I'm using systemd-boot
Note that when I boot with multiple drivers, I do not encounter this particular issue
eg:
nvidia + amdgpu
nouveau + amdgpu
The below issue occurs only when booting with nvidia (proprietary) drivers and all others blacklisted (amdgpu,nouveau)
### What happened
GDM failed to initialise the primary framebuffer, reporting "No EGL display"
```
Nov 25 12:38:58 fender-local gnome-shell[1914]: Running GNOME Shell (using mutter 45.1) as a Wayland display server
Nov 25 12:38:59 fender-local rtkit-daemon[992]: Successfully made thread 1932 of process 1914 (/usr/bin/gnome-shell) owned by '42' RT at priority 20.
Nov 25 12:38:59 fender-local gnome-shell[1914]: Made thread 'KMS thread' realtime scheduled
Nov 25 12:38:59 fender-local gnome-shell[1914]: Device '/dev/dri/card0' prefers shadow buffer
Nov 25 12:38:59 fender-local gnome-shell[1914]: Added device '/dev/dri/card0' (nvidia-drm) using atomic mode setting.
Nov 25 12:38:59 fender-local gnome-shell[1914]: Failed to initialize accelerated iGPU/dGPU framebuffer sharing: No EGL display
Nov 25 12:38:59 fender-local gnome-shell[1914]: Created gbm renderer for '/dev/dri/card0'
Nov 25 12:38:59 fender-local gnome-shell[1914]: Boot VGA GPU /dev/dri/card0 selected as primary
Nov 25 12:38:59 fender-local org.gnome.Shell.desktop[1914]: Failed to setup: The GPU /dev/dri/card0 chosen as primary is not supported by EGL.
Nov 25 12:38:59 fender-local gnome-session[1902]: gnome-session-binary[1902]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1
Nov 25 12:38:59 fender-local gnome-session-binary[1902]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1
Nov 25 12:38:59 fender-local gnome-session-binary[1902]: Unrecoverable failure in required component org.gnome.Shell.desktop
Nov 25 12:38:59 fender-local /usr/libexec/gdm-wayland-session[1901]: dbus-daemon[1901]: [session uid=42 pid=1901] Activating service name='ca.desrt.dconf' requested by ':1.2' (uid=42 pid=1902 comm="/usr/libexec/gnome-session-binary --autostart /usr" label="system_u:system_r:xdm_t:s0-s0:c0.c1023")
Nov 25 12:38:59 fender-local /usr/libexec/gdm-wayland-session[1901]: dbus-daemon[1901]: [session uid=42 pid=1901] Successfully activated service 'ca.desrt.dconf'
Nov 25 12:38:59 fender-local gdm-launch-environment][1805]: pam_unix(gdm-launch-environment:session): session closed for user gdm
Nov 25 12:38:59 fender-local audit[1805]: USER_END pid=1805 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=fender-local addr=? terminal=/dev/tty1 res=success'
Nov 25 12:38:59 fender-local audit[1805]: CRED_DISP pid=1805 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_permit acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=fender-local addr=? terminal=/dev/tty1 res=success'
Nov 25 12:38:59 fender-local gdm[1728]: Gdm: GdmDisplay: Session never registered, failing
Nov 25 12:38:59 fender-local systemd[1]: session-c1.scope: Deactivated successfully.
Nov 25 12:38:59 fender-local gdm[1728]: Gdm: Child process -1894 was already dead.
Nov 25 12:38:59 fender-local gdm[1728]: Gdm: GdmDisplay: Session never registered, failing
Nov 25 12:38:59 fender-local gdm[1728]: Gdm: Child process -1894 was already dead.
```
As a result, both GDM and Mutter fall back to X11 rather than Wayland.
### What did you expect to happen
I expected the primary device to be initialised as normal and used to establish a Wayland session
It isn't clear to me what might cause "No EGL display" to be reported
```
Failed to initialize accelerated iGPU/dGPU framebuffer sharing: No EGL display
```
### Relevant logs, screenshots, screencasts etc.
Kernel options
```
ernel: Command line: initrd=\b15ac8eef3e44d67984d2034a33a47d4\6.5.12-300.fc39.x86_64\initrd quiet rhgb rd.driver.blacklist=n
ouveau,amdgpu modprobe.blacklist=nouveau,amdgpu nvidia-drm.modeset=1 systemd.machine_id=b15ac8eef3e44d67984d2034a33a47d4 fbcon=rotate:1
```
inxi (while running X11) reports
```
Graphics:
Device-1: NVIDIA GM204 [GeForce GTX 970] vendor: ASUSTeK driver: nvidia
v: 535.129.03 arch: Maxwell bus-ID: 01:00.0
Device-2: AMD Ellesmere [Radeon RX 470/480/570/570X/580/580X/590]
vendor: Sapphire Nitro+ driver: N/A arch: GCN-4 bus-ID: 02:00.0
Display: server: X.Org v: 1.20.14 with: Xwayland v: 23.2.2 driver: X:
loaded: nvidia unloaded: fbdev,modesetting,nouveau,vesa
gpu: nvidia,nvidia-nvswitch resolution: 1440x2560~60Hz
API: EGL v: 1.5 drivers: nvidia,swrast platforms:
active: gbm,x11,surfaceless,device inactive: wayland,device-1
API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 535.129.03
glx-v: 1.4 direct-render: yes renderer: NVIDIA GeForce GTX 970/PCIe/SSE2
API: Vulkan v: 1.3.268 drivers: nvidia,llvmpipe surfaces: xcb,xlib
devices: 2
```
My /dev/dri devices are showing as:
```
/dev/dri/by-path/pci-0000:01:00.0-card -> ../card0
/dev/dri/by-path/pci-0000:01:00.0-render -> ../renderD128
```
Relevant modules show only nvidia as loaded
```
# lsmod | grep -E 'nvidia|nouveau|amdgpu'
nvidia_drm 94208 9
nvidia_modeset 1556480 12 nvidia_drm
nvidia_uvm 3510272 0
nvidia 62758912 480 nvidia_uvm,nvidia_modeset
video 77824 2 asus_wmi,nvidia_modeset
```
I noticed this interesting section from `eglinfo -B` indicating issues with Device \#1
That makes sense given I've not loaded any drivers for that device, though I would have expected eglinfo to skip it entirely..
And it seems to provide an llvmpipe driver, perhaps this is confusing matters (?)
```
Device platform:
Device #0:
Platform Device platform:
EGL API version: 1.5
EGL vendor string: NVIDIA
EGL version string: 1.5
EGL client APIs: OpenGL_ES OpenGL
OpenGL core profile vendor: NVIDIA Corporation
OpenGL core profile renderer: NVIDIA GeForce GTX 970/PCIe/SSE2
OpenGL core profile version: 4.6.0 NVIDIA 535.129.03
OpenGL core profile shading language version: 4.60 NVIDIA
OpenGL compatibility profile vendor: NVIDIA Corporation
OpenGL compatibility profile renderer: NVIDIA GeForce GTX 970/PCIe/SSE2
OpenGL compatibility profile version: 4.6.0 NVIDIA 535.129.03
OpenGL compatibility profile shading language version: 4.60 NVIDIA
OpenGL ES profile vendor: NVIDIA Corporation
OpenGL ES profile renderer: NVIDIA GeForce GTX 970/PCIe/SSE2
OpenGL ES profile version: OpenGL ES 3.2 NVIDIA 535.129.03
OpenGL ES profile shading language version: OpenGL ES GLSL ES 3.20
Device #1:
Platform Device platform:
libEGL warning: egl: failed to create dri2 screen
libEGL warning: egl: failed to create dri2 screen
eglinfo: eglInitialize failed
Device #2:
Platform Device platform:
EGL API version: 1.5
EGL vendor string: Mesa Project
EGL version string: 1.5
EGL client APIs: OpenGL OpenGL_ES
OpenGL core profile vendor: Mesa
OpenGL core profile renderer: llvmpipe (LLVM 16.0.6, 256 bits)
OpenGL core profile version: 4.5 (Core Profile) Mesa 23.2.1
OpenGL core profile shading language version: 4.50
OpenGL compatibility profile vendor: Mesa
OpenGL compatibility profile renderer: llvmpipe (LLVM 16.0.6, 256 bits)
OpenGL compatibility profile version: 4.5 (Compatibility Profile) Mesa 23.2.1
OpenGL compatibility profile shading language version: 4.50
OpenGL ES profile vendor: Mesa
OpenGL ES profile renderer: llvmpipe (LLVM 16.0.6, 256 bits)
OpenGL ES profile version: OpenGL ES 3.2 Mesa 23.2.1
OpenGL ES profile shading language version: OpenGL ES GLSL ES 3.20
```
Relevant packages:
```
]# dnf list installed | grep -E 'xorg|amd|nvid|nouv'
abrt-addon-xorg.x86_64 2.17.1-3.fc39 @fedora-modular
akmod-nvidia.x86_64 3:535.129.03-1.fc39 @rpmfusion-nonfree-nvidia-driver
amd-gpu-firmware.noarch 20231111-1.fc39 @updates
amd-ucode-firmware.noarch 20231111-1.fc39 @updates
kmod-nvidia-6.5.10-200.fc38.x86_64.x86_64 3:535.129.03-1.fc38 @@commandline
kmod-nvidia-6.5.11-300.fc39.x86_64.x86_64 3:535.129.03-1.fc39 @@commandline
kmod-nvidia-6.5.12-300.fc39.x86_64.x86_64 3:535.129.03-1.fc39 @@commandline
nvidia-gpu-firmware.noarch 20231111-1.fc39 @updates
nvidia-persistenced.x86_64 3:535.129.03-1.fc39 @rpmfusion-nonfree-nvidia-driver
nvidia-settings.x86_64 3:535.129.03-1.fc39 @rpmfusion-nonfree-nvidia-driver
teamd.x86_64 1.32-1.fc39 @fedora-modular
xorg-x11-drv-amdgpu.x86_64 23.0.0-2.fc39 @fedora-modular
xorg-x11-drv-ati.x86_64 19.1.0-10.fc39 @fedora-modular
xorg-x11-drv-evdev.x86_64 2.10.6-14.fc39 @fedora-modular
xorg-x11-drv-fbdev.x86_64 0.5.0-13.fc39 @fedora-modular
xorg-x11-drv-intel.x86_64 2.99.917-56.20210115.fc39 @fedora-modular
xorg-x11-drv-libinput.x86_64 1.4.0-1.fc39 @fedora-modular
xorg-x11-drv-nouveau.x86_64 1:1.0.17-6.fc39 @fedora-modular
xorg-x11-drv-nvidia.x86_64 3:535.129.03-2.fc39 @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-cuda.x86_64 3:535.129.03-2.fc39 @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-cuda-libs.x86_64 3:535.129.03-2.fc39 @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-kmodsrc.x86_64 3:535.129.03-2.fc39 @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-libs.x86_64 3:535.129.03-2.fc39 @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-power.x86_64 3:535.129.03-2.fc39 @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-openchrome.x86_64 0.6.400-6.20210215git5dbad06.fc39 @fedora-modular
xorg-x11-drv-qxl.x86_64 0.1.6-2.fc39 @fedora-modular
xorg-x11-drv-vesa.x86_64 2.5.0-6.fc39 @fedora-modular
xorg-x11-drv-vmware.x86_64 13.4.0-2.fc39 @fedora-modular
xorg-x11-drv-wacom.x86_64 1.2.0-2.fc39 @fedora-modular
xorg-x11-drv-wacom-serial-support.x86_64 1.2.0-2.fc39 @fedora-modular
xorg-x11-font-utils.x86_64 1:7.5-56.fc39 @fedora-modular
xorg-x11-fonts-ISO8859-1-100dpi.noarch 7.5-36.fc39 @fedora-modular
xorg-x11-proto-devel.noarch 2023.2-2.fc39 @fedora-modular
xorg-x11-server-Xorg.x86_64 1.20.14-26.fc39 @updates
xorg-x11-server-Xwayland.x86_64 23.2.2-1.fc39 @updates
xorg-x11-server-common.x86_64 1.20.14-26.fc39 @updates
xorg-x11-xauth.x86_64 1:1.1.2-4.fc39 @fedora-modular
xorg-x11-xinit.x86_64 1.4.2-1.fc39 @updates
```
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3173Mouse cursor stutters when the desktop is only achieving partial framerate2023-11-24T08:57:25ZDaniel van Vugtdaniel.van.vugt@canonical.comMouse cursor stutters when the desktop is only achieving partial framerateMouse cursor stutters when the desktop is only achieving partial framerate. Last verified today on mutter main 69e0ce36b1d02e0ee04283dbc1834154cc7cf465 using a 1000Hz mouse on a 60Hz display.
I see this when dragging the icon grid, as t...Mouse cursor stutters when the desktop is only achieving partial framerate. Last verified today on mutter main 69e0ce36b1d02e0ee04283dbc1834154cc7cf465 using a 1000Hz mouse on a 60Hz display.
I see this when dragging the icon grid, as the framerate drops to half or less, so does the mouse cursor as revealed by the large gap between sprites. It's easy to tell the difference when compared to dragging something less intensive like the small grid of an app folder which is perfectly smooth.
I believe KMS thread had the goal of solving this but we're not there yet.https://gitlab.gnome.org/GNOME/mutter/-/issues/3171Busy cursor flickers under wayland2023-12-03T19:27:48ZSakith BanmithaBusy cursor flickers under waylandThe busy cursor (or the waiting cursor) flickers, I first noticed this when opening applications. This is not an on and off thing, it always happens whenever the cursor is busy, and goes away when the cursor goes back to normal. This onl...The busy cursor (or the waiting cursor) flickers, I first noticed this when opening applications. This is not an on and off thing, it always happens whenever the cursor is busy, and goes away when the cursor goes back to normal. This only happens on wayland.
- Graphic driver: nvidia proprietary
- GNOME version: 45.1
- Distro: Arch (This happens on fedora 39 as well)
- Kernel: 6.6.2https://gitlab.gnome.org/GNOME/mutter/-/issues/3169Delay the null cursor on prox-out for tablets in relative move2023-11-22T19:39:30ZPeter HuttererDelay the null cursor on prox-out for tablets in relative move### Feature summary
The tablet tool's cursor is set to NULL on proximity out. When a tablet is in relative mode that behaviour is a bit confusing because moving the pointer across the screen requires multiple motions, each with the tool...### Feature summary
The tablet tool's cursor is set to NULL on proximity out. When a tablet is in relative mode that behaviour is a bit confusing because moving the pointer across the screen requires multiple motions, each with the tool going out of proximity (similar to moving across the screen on a touchpad with multiple finger motions). It would be nicer UX if hiding the cursor were delayed for a second or two on prox out.
### How would you like it to work
Probable requirements:
- the tool needs to remember which tablet it was last used on (relative mode is set on the tablet, not the tool)
- set a timer on proximity out to delay the cursor -> NULL update
- ???
- profit!https://gitlab.gnome.org/GNOME/mutter/-/issues/3166mutter uses obsolete LidIsClosed UPower property2024-01-03T10:29:00ZBastien Noceramutter uses obsolete LidIsClosed UPower propertyupower releases after 1.90.2 will remove lid tracking, as that's been the purview of logind for the past 10 years, and deprecated since 0.99.14:
https://gitlab.freedesktop.org/upower/upower/-/commit/8dcf54440d7eb58b75d7982bc1c29ee35dccf0...upower releases after 1.90.2 will remove lid tracking, as that's been the purview of logind for the past 10 years, and deprecated since 0.99.14:
https://gitlab.freedesktop.org/upower/upower/-/commit/8dcf54440d7eb58b75d7982bc1c29ee35dccf0c2
The gnome-settings-daemon changes:
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/merge_requests/238https://gitlab.gnome.org/GNOME/mutter/-/issues/3165Window can get lost on non-existent monitor when extending and unplugging2023-12-05T23:39:01ZMichael DWindow can get lost on non-existent monitor when extending and unplugging### Affected version
* OS: Fedora 39
* Gnome: 45.1 (Wayland session)
* Display Mgr: Wayland
* Yes
### Bug summary
When plugging into an external monitor and extending the display, if a window is left on the external display, it may ge...### Affected version
* OS: Fedora 39
* Gnome: 45.1 (Wayland session)
* Display Mgr: Wayland
* Yes
### Bug summary
When plugging into an external monitor and extending the display, if a window is left on the external display, it may get stuck off screen when unplugging from the monitor.
### Steps to reproduce
1. Plug into external monitor, extend the screen.
2. Open Firefox, browse to a video and play it
3. Maximize the video on the external monitor
4. Unplug the monitor and lock the screen
5. Unlock the screen and open / close the overview
6. Observe the firefox window will appear in the overview, but will move off screen when closing the overview
#### Steps to recover from the undesirable state
1. Open the overview
2. Grab the firefox window in the overview
3. Drag the firefox window onto a different workspace
4. Close the overview
5. Observe the firefox window is now back on the notebook's display and is visible again
### What happened
When unplugging the monitor firefox stayed off screen at the original coordinates as if the monitor was still plugged in.
### What did you expect to happen
Unplugging from the monitor usually restores the windows back onto the laptop display and attempts to scale them back to the internal display's settings.
### Relevant logs, screenshots, screencasts etc.
I looked through `dmesg` and `journalctl` but could not find much relevant information on the window states.
The only thing I could find related to gnome-shell or mutter was:
```
Nov 19 18:48:01 hostname gnome-shell[2611]: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
Nov 19 18:47:48 hostname gnome-shell[2611]: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
```
Please let me know if there is a better log I can find and I will work to reproduce the issues again while screen casting.
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3164Screencast: in result video terminal characters are wiggling while resizing t...2023-11-20T00:02:04Zdarkblaze69Screencast: in result video terminal characters are wiggling while resizing the window* OS: Arch Linux
* GNOME 45.1 (also on `main`)
* In GNOME 44.5 it doesn't reproduce
* vte 0.74.1 (also tried from `main`)
Screencast: in result video terminal characters are wiggling while resizing the window. In real life it is not obs...* OS: Arch Linux
* GNOME 45.1 (also on `main`)
* In GNOME 44.5 it doesn't reproduce
* vte 0.74.1 (also tried from `main`)
Screencast: in result video terminal characters are wiggling while resizing the window. In real life it is not observable.
**Steps to reproduce:**
* Record screen with internal recorder.
* Slowly resize terminal window with some text.
* In result video the characters are wiggling while IRL it was not seen.
**Characters are wiggling while resizing window**
![Screencast_from_2023-11-19_14-52-36](/uploads/2ec70d0d2cc29bdf70c8de4ad8e98a9b/Screencast_from_2023-11-19_14-52-36.webm)
**The same session IRL**
![video_2023-11-19_14-53-53-small](/uploads/5f3c38c0e7497234e549fe9e187813d4/video_2023-11-19_14-53-53-small.mp4)https://gitlab.gnome.org/GNOME/mutter/-/issues/3178wayland protocol error when opening popover when another one is open2023-12-11T19:06:08Ztwowayland protocol error when opening popover when another one is open## Steps to reproduce
1. open a popover
2. alt+esc to another window
3. open a popover there
4. the app exits
```
gnome-shell[1917]: WL: error in client communication (pid 2182)
gnome-software[2182]: Error 71 (Помилка протоколу) dis...## Steps to reproduce
1. open a popover
2. alt+esc to another window
3. open a popover there
4. the app exits
```
gnome-shell[1917]: WL: error in client communication (pid 2182)
gnome-software[2182]: Error 71 (Помилка протоколу) dispatching to Wayland display.
```
## Version information
debian, 4.12.3+ds-2https://gitlab.gnome.org/GNOME/mutter/-/issues/3163Painting to screencast DMABUF for OBS takes unusually long on the GPU2023-11-18T05:45:44ZIvan Molodetskikhyalterz@gmail.comPainting to screencast DMABUF for OBS takes unusually long on the GPU<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS an...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS and version
* Affected Mutter version
* Does this issue appear in XOrg and/or Wayland
-->
Fedora 39 Silverblue, Wayland, 45.1, both AMD and Intel iGPUs
### Bug summary
<!--
Provide a short summary of the bug you encountered.
-->
Painting or blitting to a screencast DMABUF for OBS takes much longer compared to painting for monitor display or painting to a screencast DMABUF for the built-in recorder.
### Steps to reproduce
<!--
1. Step one
2. Step two
3. ...
-->
1. Try to record a monitor with OBS.
### Relevant logs, screenshots, screencasts etc.
<!--
If you have further information, such as technical documentation, logs,
screenshots or screencasts related, please provide them here.
If the bug is a crash, please obtain a stack trace with installed debug
symbols (at least for GNOME Shell and Mutter) and attach it to
this issue following the instructions on
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces.
-->
Here's an example from an Intel iGPU laptop.
![image](/uploads/3eb5a362bba2345b8bb466cf8de224e4/image.png)
The red rectangles at the top are GPU work, it happens asynchronously from CPU work below. The small red rectangle on the left is painting the stage for the monitor display normally, it takes about 8.6 ms. The big red rectangle to the right is painting the same stage into an OBS screencast DMABUF. For whatever reason, it takes 44.5 ms.
When using the built-in screen recorder, which uses the same DMABUF screencasting, both paints take about the same time (as they should):
![image](/uploads/100350e112a11550438aede8c974fc89/image.png)
This problem also manifests on my AMD iGPU laptop. It's a bit faster, so the numbers are lower, but relatively the same, or even bigger, difference can be observed:
![Screenshot_from_2023-11-18_09-22-23](/uploads/1c70e118dd5178326ccd6f4da61f3d8e/Screenshot_from_2023-11-18_09-22-23.png)
The OBS screencast paint takes 5.6 ms, compared to the regular paint taking 0.3 ms.
!3406 makes screencast blit, instead of fully repainting, if possible. This helps things, but even this blit takes longer (1.3 ms) than the usual stage paint (0.3 ms):
![Screenshot_from_2023-11-18_09-23-52](/uploads/11602aaababec9c7e3acb16ab7237e9a/Screenshot_from_2023-11-18_09-23-52.png)
cc @daenzerhttps://gitlab.gnome.org/GNOME/mutter/-/issues/3162Flickering when creating 2 wl_buffer's for the same dmabuf2023-11-22T18:11:48ZBenjamin OtteFlickering when creating 2 wl_buffer's for the same dmabufWhen an application creates 2 wl_buffers for the same dmabuf fd via `zwp_linux_buffer_params_v1::create()` and attaches it to a subsurface, that subsurface starts flickering.
The flickering does not happen with (nested) Weston.
To rep...When an application creates 2 wl_buffers for the same dmabuf fd via `zwp_linux_buffer_params_v1::create()` and attaches it to a subsurface, that subsurface starts flickering.
The flickering does not happen with (nested) Weston.
To reproduce, you can get GTK main and revert https://gitlab.gnome.org/GNOME/gtk/-/commit/010ff81b2f3d8b52f7cb90835712b9a826b771e3 and then run `build/tests/testdmabuf XR24 ~/some-image.png` and interactive-resize the window.
(You want to either build with Vulkan or `sudo chmod 666 /dev/dma_heap/system` or that tool can't create dmabufs)
It will look something like this:
![Screencast_from_2023-11-17_01-38-42](/uploads/2176c67d867651b959eb9695404c0164/Screencast_from_2023-11-17_01-38-42.webm)https://gitlab.gnome.org/GNOME/mutter/-/issues/3157Support CRTCs with multiple encoders/connectors2023-11-13T16:07:42ZThomas ZimmermannSupport CRTCs with multiple encoders/connectors
### Affected version
Linux 6.6 with
Mutter 45
Both Xorg and Wayland are affected
### Bug summary
Aspeed graphics chips are mostly used in servers and some embedded systems. The chips are combined with a BMC that allows to watch the ...
### Affected version
Linux 6.6 with
Mutter 45
Both Xorg and Wayland are affected
### Bug summary
Aspeed graphics chips are mostly used in servers and some embedded systems. The chips are combined with a BMC that allows to watch the display's output remotely. In Linux 6.6, we've added a second encoder/connector for Aspeed hardware.
That newly added second output represents the BMC. It is always a mirror/clone of the first output.
Mutter does not work with the second output. It starts, but it is then impossible to change resolution on any of the outputs, or do anything at all in the Settings' display dialog.
### Steps to reproduce
<!--
1. Step one
2. Step two
3. ...
-->
1) Happens on Aspeed hardware.
2) You need Linux 6.6
3) In Gnome, go to Settings and try to configure the display.
### What happened
Mutter does allow to change the output's configuration. It permanently shows a warning that the configuration is incompatible.
### What did you expect to happen
I would expect to at least be able to configure the VGA/DP/DVI configuration as usual.
### Relevant logs, screenshots, screencasts etc.
The affected system is in drmdb at https://drmdb.emersion.fr/snapshots/4c406f948ee9
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3155mpv with dmabuf in mirror screen mode shows videos in green tint2023-12-15T14:55:52Zdarkblaze69mpv with dmabuf in mirror screen mode shows videos in green tint* OS: Arch Linux
* GNOME 45.1, `main`, with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177 patches
* iGPU Intel Tigerlake (Gen12)
Though it's great to watch in mpv dmabuf especially with 3177 patch even in multimon join mod...* OS: Arch Linux
* GNOME 45.1, `main`, with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177 patches
* iGPU Intel Tigerlake (Gen12)
Though it's great to watch in mpv dmabuf especially with 3177 patch even in multimon join mode, it fails in mirror screen mode and shows videos in green tint. Not sure maybe it's mpv's fault.
<details><summary>Click to expand</summary>
```
mpv --hwdec=vaapi --vo=dmabuf-wayland --fs --sid=0 ~/Videos/BigBuckBunnyFULLHD60FPS/Big\ Buck\ Bunny\ -\ FULL\ HD\ 60FPS.mp4
(+) Video --vid=1 (*) (h264 1920x1080 60.000fps)
(+) Audio --aid=1 (*) (aac 2ch 44100Hz)
Cannot load libcuda.so.1
Using hardware decoding (vaapi).
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [dmabuf-wayland] 1920x1080 vaapi[nv12]
[ffmpeg/video] h264: get_buffer() failed
[ffmpeg/video] h264: decode_slice_header error
[ffmpeg/video] h264: no frame!
Error while decoding frame (hardware decoding)!
[ffmpeg/video] h264: get_buffer() failed
[ffmpeg/video] h264: decode_slice_header error
[ffmpeg/video] h264: no frame!
Error while decoding frame (hardware decoding)!
[ffmpeg/video] h264: get_buffer() failed
[ffmpeg/video] h264: decode_slice_header error
[ffmpeg/video] h264: no frame!
Error while decoding frame (hardware decoding)!
Attempting next decoding method after failure of h264-vaapi.
[ffmpeg/video] h264: co located POCs unavailable
[ffmpeg/video] h264: co located POCs unavailable
[autoconvert] HW-uploading to vaapi
[hwupload] upload yuv420p -> vaapi[yuv420p]
VO: [dmabuf-wayland] 1920x1080 vaapi[yuv420p]
Exiting... (Quit)
```
</details>
![PXL_20231112_180522481.TS-small](/uploads/820120fd97579d88a32200ec14c58441/PXL_20231112_180522481.TS-small.mp4)https://gitlab.gnome.org/GNOME/mutter/-/issues/3154Manually moving a window in a multi-monitor setup does not stick to some scre...2023-11-11T09:53:30ZAdoa CoturnixManually moving a window in a multi-monitor setup does not stick to some screen edges### Affected version
* Arch Linux
* gnome-shell version 1:45.1-1 as packaged by archlinux
* only tested on wayland
* I do not use gnome extensions
### Bug summary
I love the feature that when you move windows manually via Super + drag...### Affected version
* Arch Linux
* gnome-shell version 1:45.1-1 as packaged by archlinux
* only tested on wayland
* I do not use gnome extensions
### Bug summary
I love the feature that when you move windows manually via Super + drag left mouse button, they stick to the screen edges. However, this sticking is inconsistent in a multi-monitor setup. Some screen edges are not sticky – without obvious reason.
### Steps to reproduce
I can reproduce it in at least two variants:
Two monitor setup A: moving a window across the *lower* edge of the smaller screen on the right-hand side does not stick.
```
+–––––––––––––––––––+––––––––––––+
| | |
| | |
| | |
| |––––––––––––+
| |
| |
+–––––––––––––––––––+
```
Two monitor setup B: moving a window across the *upper* edge of the smaller screen on the right-hand side does not stick.
```
+–––––––––––––––––––+
| |
| |
| |––––––––––––+
| | |
| | |
| | |
+–––––––––––––––––––+––––––––––––+
```
In both cases, when trying to move a window between the monitors, the sticking is as expected.
However, when trying to move a *small* window from the big screen into the space *below* the secondary screen in setup A or *above* the secondary screen in setup B does not stick either. The latter effect is only reproducible if the window you try to move does not "hit" the secondary screen while moving.
### What happened
Manually moving a window sticks to some screen edges, yet not to others.
### What did you expect to happen
Manually moving a window should stick to all screen edges, irrespective of virtual screen arrangement.https://gitlab.gnome.org/GNOME/mutter/-/issues/3153Switching windows of an application (partly) doesn't work anymore2024-01-31T09:40:26ZBaby GnuSwitching windows of an application (partly) doesn't work anymoreHi :) Since GNOME 45 (Fedora), I cannot always (see below) switch between windows of the same application using Super+^ ("dead circumflex" / "Above_Tab"). In the settings / dconf-editor, I see it correctly configured, the default in dcon...Hi :) Since GNOME 45 (Fedora), I cannot always (see below) switch between windows of the same application using Super+^ ("dead circumflex" / "Above_Tab"). In the settings / dconf-editor, I see it correctly configured, the default in dconf-editor is `['<Super>Above_Tab', '<Alt>Above_Tab']` and that is activated. Switching with Alt+^ works reliably. Switching with Super+^ only works if there is no active input in the current window. So when I have two windows of the Files app, for example, it works. But when I'm typing something in gnome-terminal and then want to switch to another gnome-terminal window, it doesn't work. Instead, I just type the character ^ in my current command line / open editor / whatever I have in the terminal.