mutter issueshttps://gitlab.gnome.org/GNOME/mutter/-/issues2023-12-22T12:35:28Zhttps://gitlab.gnome.org/GNOME/mutter/-/issues/2783Since 44.1, sometimes frame updates are only occasionally pushed to the clien...2023-12-22T12:35:28ZJeff FortinSince 44.1, sometimes frame updates are only occasionally pushed to the client (both X11 and Wayland), breaking GNOME Remote Desktop## Problem statement
When connecting over RDP onto my desktop workstation running GNOME Shell 44.1 on a fully up-to-date Fedora 38:
* If connecting to an unlocked screen, the client gets a black screen, until the first frame update (se...## Problem statement
When connecting over RDP onto my desktop workstation running GNOME Shell 44.1 on a fully up-to-date Fedora 38:
* If connecting to an unlocked screen, the client gets a black screen, until the first frame update (see below)
* Frame updates only happen sometimes when clicking on some GNOME Shell UI elements, such as the notifications tray button, or the system menu button, but the frame on the client does not get updated when dismissing those menus
* Repeatedly clicking those elements on and off may eventually trigger a frame update to the client
* Input events from the client get sent to the server fine
This used to work fine in previous versions. I did not change anything in the Remmina client configuration.
I really don't know what to look for here, the journalctl logs (below) don't seem to say anything special, but I tried troubleshooting and demonstrating the symptoms as best as I can in a short video. Please have a look at this video, and the problem will be clear: https://youtu.be/ETaGMSvN-ok
## Software, drivers, hardware
Both the server and the client are running GNOME Shell 44.1 on a fully up-to-date Fedora 38.
I'm using Remmina 1.4.30 as the connecting client.
The host/server uses an AMD Radeon "Pitcairn" R7/R9 270 GPU. It is not set up for VA-API, so I don't think I have HW-accelerated H.264 encoding/decoding there. I am running the open source AMD graphics driver that comes with Fedora 38. I did full reboots (and poweroffs) between tries, so it's presumably not the GPU simply being in a borked state.
I tested both using Xorg and Wayland on the server, and in both display servers I also tested both the vanilla version vs the patched triple-buffering version (from [this COPR](https://copr.fedorainfracloud.org/coprs/calcastor/gnome-patched/)), just to be sure if it would benefit from triple-buffering somehow. The problems remain the same in all cases.
## Logs
Upon connecting:
```
Apr 30 20:47:50 workstation gnome-remote-desktop-daemon[12499]: [20:47:50:604] [12499:14038] [WARN][com.winpr.negotiate] - AcceptSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
Apr 30 20:47:50 workstation gnome-remote-desktop-daemon[12499]: [20:47:50:705] [12499:14038] [WARN][com.winpr.negotiate] - AcceptSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
Apr 30 20:47:52 workstation gnome-remote-de[12499]: [RDP.CLIPRDR] Relieving CLIPRDR filename restriction
Apr 30 20:47:52 workstation gnome-remote-de[12499]: [RDP.CLIPRDR] Client capabilities: long format names
Apr 30 20:47:52 workstation gnome-remote-de[12499]: [RDP.RDPGFX] CapsAdvertise: Accepting capability set with version RDPGFX_CAPVERSION_107, Client cap flags: H264 (AVC444): false, H264 (AVC420): false
Apr 30 20:47:52 workstation gnome-remote-de[12499]: [RDP.AUDIO_PLAYBACK] Client Formats: [AAC: false, PCM: true]
```
Upon disconnecting:
```
Apr 30 20:49:25 workstation gnome-remote-desktop-daemon[12499]: [20:49:25:452] [12499:14038] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 0: Success
Apr 30 20:49:25 workstation gnome-remote-desktop-daemon[12499]: [20:49:25:452] [12499:14038] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
Apr 30 20:49:25 workstation gnome-remote-de[12499]: Unable to check file descriptor, closing connection
Apr 30 20:49:25 workstation systemd[1]: run-user-1000-gnome\x2dremote\x2ddesktop-cliprdr\x2d0DBvj4.mount: Deactivated successfully.
```GNOME 44https://gitlab.gnome.org/GNOME/mutter/-/issues/2624Some X11 window title bars do not show title anymore2023-03-03T17:05:01ZMichel DänzerSome X11 window title bars do not show title anymore### Affected version
* Mutter 44.beta
* Wayland (haven't tested X11)
### Bug summary
The title bar of some X11 windows no longer shows the window title.
### Steps to reproduce
1. Run `glxgears`
### What happened
Title bar of `glxg...### Affected version
* Mutter 44.beta
* Wayland (haven't tested X11)
### Bug summary
The title bar of some X11 windows no longer shows the window title.
### Steps to reproduce
1. Run `glxgears`
### What happened
Title bar of `glxgears` window shows no title.
### What did you expect to happen
Title bar of `glxgears` window shows "glxgears" title.
### Regression
This is a regression of the new `mutter-x11-frames` client.
<!-- Do not remove the following line. -->GNOME 44Carlos GarnachoCarlos Garnachohttps://gitlab.gnome.org/GNOME/mutter/-/issues/2495g-s crashes in clutter_actor_run_actions(), when clicking in overview in remo...2023-09-30T09:08:10ZPascal Nowackg-s crashes in clutter_actor_run_actions(), when clicking in overview in remote desktop sessions (with RecordVirtual)Affected version: mutter/main, g-s/main
Reproduction steps:
1. Run g-s with `--wayland --headless` options
2. Create a remote desktop session via `RecordVirtual()`
3. Click in the overview with the left mouse button (but not in the top ...Affected version: mutter/main, g-s/main
Reproduction steps:
1. Run g-s with `--wayland --headless` options
2. Create a remote desktop session via `RecordVirtual()`
3. Click in the overview with the left mouse button (but not in the top bar) several times
Observations: The mouse clicks are not recognized (overview should exit), g-s crashes
Stacktrace: [backtrace](/uploads/ef5f41e7eea861b71023fa7ae29319d1/backtrace)GNOME 43https://gitlab.gnome.org/GNOME/mutter/-/issues/2282dma-buf screencasts produce old frames with mutter/main and mutter-42.x2023-10-11T02:24:24ZPascal Nowackdma-buf screencasts produce old frames with mutter/main and mutter-42.xReproduction steps:
1. Start g-r-d
2. Open a new workspace (should be position-wise, the most right one (no workspace on the right of this new workspace))
3. Start a g-t (terminal window)
4. Move the terminal window a bit outside the sc...Reproduction steps:
1. Start g-r-d
2. Open a new workspace (should be position-wise, the most right one (no workspace on the right of this new workspace))
3. Start a g-t (terminal window)
4. Move the terminal window a bit outside the screen (to the left side), so that the blinking cursor won't mess this reproduction up (see the screenshot below for reference here)
5. (Nothing should change now on the screen) Maybe check the clock, to wait for the next minute, so that the number change in the clock won't create damage
6. Connect to g-r-d with a remote desktop client to the session
7. Switch the workspace to the right using the keyboard shortcut (this new workspace should be empty)
Observation: On the remote desktop client side, the terminal window is still shown, although the workspace was switched.
Moving the mouse somewhere should trigger an updated frame without the terminal window.
The error here is in mutter, the damage detection in g-r-d works fine (also g-r-d does not mess up any frame order here).
The issue only happens with dma-buf screencasts, but not with screencasts, where MemFds are used.
Screenshot regarding step 4: ![Bildschirmfoto_vom_2022-06-08_04-42-55](/uploads/b0ea5207f2898450b187b63d024dbbb2/Bildschirmfoto_vom_2022-06-08_04-42-55.png)
CC: @jadahlGNOME 42https://gitlab.gnome.org/GNOME/mutter/-/issues/1615Xwayland windows do not get mapped in the overview2021-10-11T05:37:33ZRobert Maderrobert.mader@posteo.deXwayland windows do not get mapped in the overview![Screencast_from_20.01.2021_19_09_15](/uploads/b3f31471b03b07842a7116694c3fa759/Screencast_from_20.01.2021_19_09_15.webm)
This is a regression from https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285 but surprisingly neither me...![Screencast_from_20.01.2021_19_09_15](/uploads/b3f31471b03b07842a7116694c3fa759/Screencast_from_20.01.2021_19_09_15.webm)
This is a regression from https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285 but surprisingly neither me nor anyone else seems to have found and posted a simple reproducer for this - now I've finally found this one :)
Other occurrences include some "Do you want to safe ..." dialogs when closing things from the overview.
cc: @jadahlGNOME 3.38https://gitlab.gnome.org/GNOME/mutter/-/issues/1536Input unresponsive after screen blank since 209b1ba32020-11-26T15:11:13ZSimon McVittieInput unresponsive after screen blank since 209b1ba3https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974172
We've had a bug report in Debian that after upgrading mutter from 3.38.0 to 3.38.1 on multiple arm64 (aarch64) systems, the keyboard and mouse become unresponsive and GNOME Shell ...https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974172
We've had a bug report in Debian that after upgrading mutter from 3.38.0 to 3.38.1 on multiple arm64 (aarch64) systems, the keyboard and mouse become unresponsive and GNOME Shell cannot be unlocked.
One user reports that "The screen can be unlocked if it is not blanked, but it cannot be unlocked after blanking".
Apparently this regressed with 209b1ba3 "clutter/frame-clock: Adapt refresh rate from to frame info".
Perhaps the frame rate needs a minimum, so that even if no frames are drawn at all, the frame-clock still runs?GNOME 3.38https://gitlab.gnome.org/GNOME/mutter/-/issues/1058Cursor is invisible on Wayland2020-04-25T17:20:10ZDaniel SmithCursor is invisible on Wayland### Affected version
OS: Fedora 32.20200219.n.0 (Workstation Edition) (Silverblue)
Mutter: mutter-3.35.91-1.fc32.x86_64
Kernel: kernel-5.6.0-0.rc2.git0.1.fc32.x86_64
Mesa: mesa-libGL-20.0.0~rc3-1.fc32.x86_64
### Bug summary
When usi...### Affected version
OS: Fedora 32.20200219.n.0 (Workstation Edition) (Silverblue)
Mutter: mutter-3.35.91-1.fc32.x86_64
Kernel: kernel-5.6.0-0.rc2.git0.1.fc32.x86_64
Mesa: mesa-libGL-20.0.0~rc3-1.fc32.x86_64
### Bug summary
When using a hardware cursor, it is invisible. I can still interact with the desktop.
### Relevant logs, screenshots, screencasts etc.
These show up in the journal when moving the mouse.
```
Feb 20 14:05:31 isaplanet-local gnome-shell[1921]: set_crtc_cursor: assertion 'cursor_plane' failed
Feb 20 14:05:31 isaplanet-local gnome-shell[1921]: unset_crtc_cursor: assertion 'cursor_plane' failed
```
GPU driver. This happens with both amdgpu and radeon.
```
Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: AMD PITCAIRN (DRM 2.50.0, 5.6.0-0.rc2.git0.1.fc32.x86_64, LLVM 9.0.1) (0x6811)
Version: 20.0.0
Accelerated: yes
Video memory: 2048MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 4.5
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
```
<!-- Do not remove the following line. -->GNOME 3.36https://gitlab.gnome.org/GNOME/mutter/-/issues/1045Fix buffer transform to comply with spec2022-06-03T09:26:55ZJonas ÅdahlFix buffer transform to comply with specThe buffer transform implementation in mutter followed the path set by weston, which was incorrect.
The weston issue was reported here: https://gitlab.freedesktop.org/wayland/weston/issues/99 and fixed here: https://gitlab.freedesktop.o...The buffer transform implementation in mutter followed the path set by weston, which was incorrect.
The weston issue was reported here: https://gitlab.freedesktop.org/wayland/weston/issues/99 and fixed here: https://gitlab.freedesktop.org/wayland/weston/merge_requests/383 .GNOME 3.36Robert Maderrobert.mader@posteo.deRobert Maderrobert.mader@posteo.dehttps://gitlab.gnome.org/GNOME/mutter/-/issues/728Monitors not recognized after redocking to WD15 dock2020-08-06T20:30:46ZJonas ÅdahlMonitors not recognized after redocking to WD15 dockSee for original thread: https://gitlab.gnome.org/GNOME/mutter/issues/726#note_579500
The problem is that `MetaKmsConnector`s are not generated for connectors after a `MetaKmsDevice` was initially created. This works fine for a regular ...See for original thread: https://gitlab.gnome.org/GNOME/mutter/issues/726#note_579500
The problem is that `MetaKmsConnector`s are not generated for connectors after a `MetaKmsDevice` was initially created. This works fine for a regular computer or e.g. hot plugged KMS devices (e.g. DisplayLink devices), but in other configurations, such as when docking with a WD15, the connectors come and go on the fly.GNOME 3.34Jonas ÅdahlJonas Ådahlhttps://gitlab.gnome.org/GNOME/mutter/-/issues/660Some apps cause mutter to hang in meta_window_x11_focus -> meta_stack_get_def...2019-07-08T16:33:34ZMarco Trevisanmail@3v1n0.netSome apps cause mutter to hang in meta_window_x11_focus -> meta_stack_get_default_focus_windowSome apps (like JetBrain's java apps) can lead to an hanging shell when dialogs are closed.
See:
![Screencast_2019-07-03_00_27_06](/uploads/8da129e4d3bcbf44d918f48b56ef81d4/fooo.webm)
Relevant trace is:
```
#10 0x00007fc929805cc3 in ...Some apps (like JetBrain's java apps) can lead to an hanging shell when dialogs are closed.
See:
![Screencast_2019-07-03_00_27_06](/uploads/8da129e4d3bcbf44d918f48b56ef81d4/fooo.webm)
Relevant trace is:
```
#10 0x00007fc929805cc3 in
meta_stack_get_default_focus_window
(stack=stack@entry=0x55c3f44b73b0, workspace=workspace@entry=0x55c3f4481190, not_this_one=not_this_one@entry=0x55c3f74be3f0) at ../src/core/stack.c:1264
No locals.
#11 0x00007fc92982ba9e in
meta_window_x11_focus
(window=0x55c3f74be070, timestamp=21028465) at ../src/x11/window-x11.c:904
focus_window = 0x55c3f74be3f0
x11_display = 0x55c3f4492aa0
workspace = 0x55c3f4481190
stack = 0x55c3f44b73b0
window_x11 = <optimized out>
priv = <optimized out>
#12 0x00007fc92981308f in
meta_window_focus
(window=0x55c3f74be070, timestamp=21028465) at ../src/core/window.c:4785
workspace_manager = 0x55c3f44b5b40
modal_transient = <optimized out>
__func__ = "meta_window_focus"
#13 0x00007fc929815ece in
focus_ancestor_or_top_window
(workspace=0x55c3f4481190, not_this_one=not_this_one@entry=0x55c3f74bee70, timestamp=timestamp@entry=21028465) at ../src/core/workspace.c:1399
window = 0x55c3f74be070
#14 0x00007fc929817484 in
meta_workspace_focus_default_window
(workspace=<optimized out>, not_this_one=not_this_one@entry=0x55c3f74bee70, timestamp=timestamp@entry=21028465) at ../src/core/workspace.c:1282
No locals.
#15 0x00007fc92981050e in
meta_window_unmanage
(window=window@entry=0x55c3f74bee70, timestamp=timestamp@entry=21028465) at ../src/core/window.c:1530
workspace_manager = 0x55c3f44b5b40
tmp = <optimized out>
__func__ = "meta_window_unmanage"
#16 0x00007fc92981d48c in
handle_other_xevent
(x11_display=x11_display@entry=0x55c3f4492aa0, event=event@entry=0x7ffd2db9c0d0) at ../src/x11/events.c:1368
timestamp = 21028465
display = 0x55c3f43e0010
workspace_manager = 0x55c3f44b5b40
modified = <optimized out>
window = 0x55c3f74bee70
property_for_window = <optimized out>
frame_was_receiver = <optimized out>
bypass_gtk = 0
#17 0x00007fc92981e39b in
meta_x11_display_handle_xevent
(event=0x7ffd2db9c0d0, x11_display=0x55c3f4492aa0) at ../src/x11/events.c:1821
input_event = <optimized out>
display = 0x55c3f43e0010
backend = <optimized out>
modified = 31484367
bypass_compositor = 0
bypass_gtk = 0
cursor_tracker = <optimized out>
display = <optimized out>
backend = <optimized out>
modified = <optimized out>
bypass_compositor = <optimized out>
bypass_gtk = <optimized out>
input_event = <optimized out>
cursor_tracker = <optimized out>
window = <optimized out>
#18
xevent_filter
(xevent=0x7ffd2db9c0d0, event=<optimized out>, data=0x55c3f4492aa0) at ../src/x11/events.c:1859
x11_display = 0x55c3f4492aa0
```
This can be reproduced with this `.metatest`:
```
new_client 0 x11
create 0/1
show 0/1
new_client 1 x11
create 1/1
show 1/1
create 1/2 csd
set_parent 1/2 1
accept_focus 1/2 false
show 1/2
create 1/3 csd
set_parent 1/3 2
accept_focus 1/3 false
show 1/3
create 1/4 csd
set_parent 1/4 3
accept_focus 1/4 false
show 1/4
create 1/5 csd
set_parent 1/5 3
show 1/5
wait
assert_focused 1/5
assert_stacking 0/1 1/1 1/2 1/3 1/4 1/5
destroy 1/5
dispatch
assert_focused none
assert_stacking 0/1 1/1 1/2 1/3 1/4
sleep 250
assert_focused none
assert_stacking 0/1 1/1 1/2 1/3 1/4
destroy 1/3
wait
assert_focused none
assert_stacking 0/1 1/1 1/2 1/4
```
Related to commit f71151a5dd990d935f3fbb39451f9b41f640b625GNOME 3.34Marco Trevisanmail@3v1n0.netMarco Trevisanmail@3v1n0.nethttps://gitlab.gnome.org/GNOME/mutter/-/issues/3263Wayland stacking tests are flaky2024-01-26T23:05:40ZBilal Elmoussaouibil.elmoussaoui@gmail.comWayland stacking tests are flakyThe following discussion from !3539 should be addressed:
- [ ] @swick started a [discussion](https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3539#note_1985556): (+13 comments)
> What the hell is going on in CI? Some stackin...The following discussion from !3539 should be addressed:
- [ ] @swick started a [discussion](https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3539#note_1985556): (+13 comments)
> What the hell is going on in CI? Some stacking tests failing but only in dist...
And the commit in https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3548 should be revertedhttps://gitlab.gnome.org/GNOME/mutter/-/issues/3259Cursor movement becomes synchronized with main content updates after VT switch2024-01-22T07:33:17ZDor AskayoCursor movement becomes synchronized with main content updates after VT switch### Description
After switching out to a different VT and back to the one that Mutter/gnome-shell controls, cursor movement is no longer independent of content updates and remains so until the session is restarted. Essentially, the main...### Description
After switching out to a different VT and back to the one that Mutter/gnome-shell controls, cursor movement is no longer independent of content updates and remains so until the session is restarted. Essentially, the main user-visible benefit introduced in https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777 is lost.
The following error is shown when switching out of the VT:
```
Failed to determine deadline: drmWaitVBlank failed: Operation not permitted
```
### Root cause analysis
The error above results in `priv->deadline_timer_inhibited` being set to `TRUE` in
[main/src/backends/native/meta-kms-impl-device.c#L1622-1629](https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/backends/native/meta-kms-impl-device.c#L1622-1629).
After that, `priv->deadline_timer_inhibited` remains set to `TRUE` for the entire lifetime of the `MetaKmsImplDevice`. As long as it's set to `TRUE`, the deadline timer is not armed and cursor updates are no longer done on their own schedule independent of the main thread.
I'll upload a MR to fix this issue.https://gitlab.gnome.org/GNOME/mutter/-/issues/3227meta-seat-x11: Uninitialized group and mode params to clutter_event_pad_butto...2024-01-06T22:27:56ZMart Raudseppmeta-seat-x11: Uninitialized group and mode params to clutter_event_pad_button_new without libwacomThe `group` and `mode` variables in `src/backends/x11/meta-seat-x11.c:2209` are declared uninitialized and only initialized in a `#ifdef HAVE_LIBWACOM` block, and then used right after outside that:
```
[428/1567] Compiling C object src...The `group` and `mode` variables in `src/backends/x11/meta-seat-x11.c:2209` are declared uninitialized and only initialized in a `#ifdef HAVE_LIBWACOM` block, and then used right after outside that:
```
[428/1567] Compiling C object src/libmutter-13.so.0.0.0.p/backends_x11_meta-seat-x11.c.o
../src/backends/x11/meta-seat-x11.c:212:37: warning: cast from 'XIAnyClassInfo *' to 'XIValuatorClassInfo *' increases required alignment from 4 to 8 [-Wcast-align]
212 | (XIValuatorClassInfo *) class_info);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/backends/x11/meta-seat-x11.c:217:46: warning: cast from 'XIAnyClassInfo *' to 'XIScrollClassInfo *' increases required alignment from 4 to 8 [-Wcast-align]
217 | XIScrollClassInfo *scroll_info = (XIScrollClassInfo *) class_info;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/backends/x11/meta-seat-x11.c:404:39: warning: cast from 'XIAnyClassInfo *' to 'XIValuatorClassInfo *' increases required alignment from 4 to 8 [-Wcast-align]
404 | XIValuatorClassInfo *valuator = (XIValuatorClassInfo*) info->classes[i];
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/backends/x11/meta-seat-x11.c:2245:51: warning: variable 'group' is uninitialized when used here [-Wuninitialized]
2245 | group,
| ^~~~~
../src/backends/x11/meta-seat-x11.c:2209:35: note: initialize the variable 'group' to silence this warning
2209 | uint32_t button, group, mode;
| ^
| = 0
../src/backends/x11/meta-seat-x11.c:2246:51: warning: variable 'mode' is uninitialized when used here [-Wuninitialized]
2246 | mode);
| ^~~~
../src/backends/x11/meta-seat-x11.c:2209:41: note: initialize the variable 'mode' to silence this warning
2209 | uint32_t button, group, mode;
| ^
| = 0
5 warnings generated.
```
Is there a safe default that can be used here to not feed `clutter_event_pad_button_new()` potentially garbage in such a build configuration?
This happens in gnome-45 branch, but confirmed in `main` after local workarounds for #3226https://gitlab.gnome.org/GNOME/mutter/-/issues/3226cogl-cpu-caps.c and cogl-buffer.c fail to compile with clang on ARM642024-01-04T16:45:49ZMart Raudseppcogl-cpu-caps.c and cogl-buffer.c fail to compile with clang on ARM64### Affected version
commit 3a94822e755e530b71 from `origin/main`
### Bug summary
Compilation fails with clang-17.0.6 on at least cogl-buffer.c and cogl-cpu-caps.c. Unrelatedly there's also lots of compiler warnings, which might be of...### Affected version
commit 3a94822e755e530b71 from `origin/main`
### Bug summary
Compilation fails with clang-17.0.6 on at least cogl-buffer.c and cogl-cpu-caps.c. Unrelatedly there's also lots of compiler warnings, which might be of interest (lots from `-Wcast-align` and more)
### Steps to reproduce
```
CXX=clang++ AR=llvm-ar RANLIB=llvm-ranlib OBJCOPY=llvm-objcopy CC=clang CFLAGS="-O3 -pipe -fno-omit-frame-pointer -fdebug-default-version=4 -gdwarf-4" meson setup build -Dlibwacom=false
ninja -C build
```
### What happened
Build failed on ARM64 (Apple M2, Gentoo)
### What did you expect to happen
Successful compilation like in `origin/gnome-45` branch
### Relevant logs, screenshots, screencasts etc.
```
[36/1687] Compiling C object cogl/cogl/libmutter-cogl-13.so.0.0.0.p/cogl-buffer.c.o
FAILED: cogl/cogl/libmutter-cogl-13.so.0.0.0.p/cogl-buffer.c.o
clang -Icogl/cogl/libmutter-cogl-13.so.0.0.0.p -Icogl/cogl -I../cogl/cogl -Imtk -I../mtk -Imtk/mtk -I../mtk/mtk -Icogl -I../cogl -I. -I.. -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/gio-unix-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/lib64/libffi/include -I/usr/include/graphene-1.0 -I/usr/lib64/graphene-1.0/include -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/libpng16 -fvisibility=hidden -fcolor-diagnostics -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O0 -g -D_GNU_SOURCE -fno-strict-aliasing -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wundef -Wunused -Wcast-align -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-include-dirs -Wignored-qualifiers -Werror=redundant-decls -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type -Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -Werror=empty-body -Werror=write-strings -Werror=strict-aliasing -Wno-sign-compare -Wno-cast-function-type -Wno-unused-parameter -Wno-missing-field-initializers -Wno-type-limits -DG_ENABLE_DEBUG -fno-omit-frame-pointer -O3 -pipe -fno-omit-frame-pointer -fdebug-default-version=4 -gdwarf-4 -fPIC -pthread '-DCOGL_LOCALEDIR="/usr/local/share/locale"' -DCOGL_COMPILATION '-DCOGL_GL_LIBNAME="libGL.so.1"' '-DCOGL_GLES2_LIBNAME="libGLESv2.so.2"' -DCOGL_GL_DEBUG -DCOGL_OBJECT_DEBUG -DCOGL_ENABLE_DEBUG -fno-omit-frame-pointer -MD -MQ cogl/cogl/libmutter-cogl-13.so.0.0.0.p/cogl-buffer.c.o -MF cogl/cogl/libmutter-cogl-13.so.0.0.0.p/cogl-buffer.c.o.d -o cogl/cogl/libmutter-cogl-13.so.0.0.0.p/cogl-buffer.c.o -c ../cogl/cogl/cogl-buffer.c
../cogl/cogl/cogl-buffer.c:135:7: error: expected expression
135 | gboolean use_malloc = FALSE;
| ^
../cogl/cogl/cogl-buffer.c:141:13: error: use of undeclared identifier 'use_malloc'
141 | use_malloc = TRUE;
| ^
../cogl/cogl/cogl-buffer.c:144:11: error: use of undeclared identifier 'use_malloc'; did you mean 'g_malloc'?
144 | if (use_malloc)
| ^~~~~~~~~~
| g_malloc
/usr/include/glib-2.0/glib/gmem.h:84:10: note: 'g_malloc' declared here
84 | gpointer g_malloc (gsize n_bytes) G_GNUC_MALLOC G_GNUC_ALLOC_SIZE(1);
| ^
3 errors generated.
[42/1687] Compiling C object cogl/cogl/libmutter-cogl-13.so.0.0.0.p/cogl-cpu-caps.c.o
FAILED: cogl/cogl/libmutter-cogl-13.so.0.0.0.p/cogl-cpu-caps.c.o
clang -Icogl/cogl/libmutter-cogl-13.so.0.0.0.p -Icogl/cogl -I../cogl/cogl -Imtk -I../mtk -Imtk/mtk -I../mtk/mtk -Icogl -I../cogl -I. -I.. -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/gio-unix-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/lib64/libffi/include -I/usr/include/graphene-1.0 -I/usr/lib64/graphene-1.0/include -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/libpng16 -fvisibility=hidden -fcolor-diagnostics -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O0 -g -D_GNU_SOURCE -fno-strict-aliasing -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wundef -Wunused -Wcast-align -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-include-dirs -Wignored-qualifiers -Werror=redundant-decls -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type -Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -Werror=empty-body -Werror=write-strings -Werror=strict-aliasing -Wno-sign-compare -Wno-cast-function-type -Wno-unused-parameter -Wno-missing-field-initializers -Wno-type-limits -DG_ENABLE_DEBUG -fno-omit-frame-pointer -O3 -pipe -fno-omit-frame-pointer -fdebug-default-version=4 -gdwarf-4 -fPIC -pthread '-DCOGL_LOCALEDIR="/usr/local/share/locale"' -DCOGL_COMPILATION '-DCOGL_GL_LIBNAME="libGL.so.1"' '-DCOGL_GLES2_LIBNAME="libGLESv2.so.2"' -DCOGL_GL_DEBUG -DCOGL_OBJECT_DEBUG -DCOGL_ENABLE_DEBUG -fno-omit-frame-pointer -MD -MQ cogl/cogl/libmutter-cogl-13.so.0.0.0.p/cogl-cpu-caps.c.o -MF cogl/cogl/libmutter-cogl-13.so.0.0.0.p/cogl-cpu-caps.c.o.d -o cogl/cogl/libmutter-cogl-13.so.0.0.0.p/cogl-cpu-caps.c.o -c ../cogl/cogl/cogl-cpu-caps.c
../cogl/cogl/cogl-cpu-caps.c:50:7: error: invalid output constraint '=a' in asm
50 | : "=a"(eax),
| ^
1 error generated.
```
The use_malloc case is somewhat obvious - it's not allowed to make a new variable in a case branch without a new block or something. No immediate idea about the asm myself though :(
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3109Mouse pointer randomly starts to disappear at the right edge of the left moni...2023-12-13T14:59:06ZUnknown UserMouse pointer randomly starts to disappear at the right edge of the left monitor, when there is a maximised window<!--
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: Endeavour OS
* Affected GNOME Shell version (see https://wiki.gnome.org/Schedule for currently supported versions) 43.3
* Does this issue appear in XOrg and/or Wayland: Wayland
* Does this issue happen without extensions (please follow instructions below)
To properly disable extensions you can use gnome-extensions-app and then restart
your session. Disabling extensions without a restart is not sufficient to rule
out extensions as cause of a bug. If an issue can only be reproduced with a
certain extension, please file a bug report against that extension first.
-->
* Your OS and version: Endeavour OS (Arch-based)
* Affected GNOME Shell version: 43.3
* Does this issue appear in XOrg and/or Wayland: Wayland. I do not know if it would happen on XOrg. I have been only using Wayland since the installation of the OS. It is difficult for me to test XOrg, because this is my main PC and I need Wayland to use the PC.
* Does this issue happen without extensions: Yes. I have disabled extension support and rebooted the PC, and it happened again. Note that I did not uninstall individual extensions, but I just unticked the overall extension support.
![image](/uploads/d43e20916e2970c3bd1e3285d0c0394e/image.png)
### Bug summary
When I just logged in to Gnome, it does not happen and the pointer works normally. But after while, the pointer starts disappearing at the right edge of the left monitor, when there is a maximised window on the left monitor.
### Steps to reproduce
I have not figured out the exact condition or steps. It starts to happen randomly. Maybe putting the computer to sleep and then waking it up facilitates this.
If it is relevant, my left monitor is a 24" 1920x1200 monitor with 100% DPI. My right monitor is a 32" 4K monitor with 150% DPI. Fractional scaling has been enabled. The right monitor is the primary monitor. The GPU is AMD Radeon Navi2. In the Accessibility, I have set the cursor size to "Large", but it also happened when I changed it to "default". Due to the random nature of its starting to happen, I cannot yet say this with high certainty (because I need more testing time) but so far it seems that it does not happen if `scale-monitor-framebuffer` is not enabled and I use 100% (left) and 200% (right) DPI's .
### What happened
Pointer becomes invisible. I can still click with the invisible pointer.
### What did you expect to happen
Pointer not disappearing.
### Relevant logs, screenshots, screencasts etc.
I have recorded the monitors, and the file size is 57MB. It failed to to trying to attach the video file directly, probably because it is too large. So, I will uploaded it on FileBin, and link the URL.
https://filebin.net/9ps8h1kiwj046kt1
<!--
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.
-->
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3096Launching applications from the shell triggers meta_window_set_stack_position...2023-11-05T13:30:59Zdarkblaze69Launching applications from the shell triggers meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed- GNOME OS / Arch Linux (fcgu repo)
- 45 beta, also tried latest main of mutter and gnome-shell
Open gnome-control-center. In journalctl this warning appears:
`meta_window_set_stack_position_no_sync: assertion 'window->stack_position ...- GNOME OS / Arch Linux (fcgu repo)
- 45 beta, also tried latest main of mutter and gnome-shell
Open gnome-control-center. In journalctl this warning appears:
`meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed`https://gitlab.gnome.org/GNOME/mutter/-/issues/3073Crash in meta_wayland_keyboard_set_focus2024-01-15T11:30:20ZIvan Molodetskikhyalterz@gmail.comCrash in meta_wayland_keyboard_set_focus<!--
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 GNOME Shell version (see https://wiki.gnome.org/Schedule for currently supported versions)
* Does this issue appear in XOrg and/or Wayland
* Does this issue happen without extensions (please follow instructions below)
To properly disable extensions you can use gnome-extensions-app and then restart
your session. Disabling extensions without a restart is not sufficient to rule
out extensions as cause of a bug. If an issue can only be reproduced with a
certain extension, please file a bug report against that extension first.
-->
Fedora 38 Silverblue, Wayland, mutter-44.5-1.fc38.x86_64, gnome-shell-44.5-1.fc38.x86_64
### Bug summary
<!--
Provide a short summary of the bug you encountered.
-->
Shell crashed:
```
#0 wl_resource_add_destroy_listener (resource=resource@entry=0x0, listener=listener@entry=0x561eda078e20) at ../src/wayland-server.c:842
#1 0x00007f338e74fbcf in meta_wayland_keyboard_set_focus (keyboard=0x561eda078de0, surface=<optimized out>) at ../src/wayland/meta-wayland-keyboard.c:786
#2 0x00007f338e6c4ba5 in meta_wayland_seat_set_input_focus (surface=0x561ede335fd0, seat=0x561ed9d8bee0) at ../src/wayland/meta-wayland-seat.c:424
#3 meta_wayland_compositor_set_input_focus (window=<optimized out>, compositor=<optimized out>) at ../src/wayland/meta-wayland.c:360
#4 meta_display_sync_wayland_input_focus (display=<optimized out>) at ../src/core/display.c:1411
#5 0x00007f338f21d4ea in g_closure_invoke (closure=0x561eda081220, return_value=0x0, n_param_values=2, param_values=0x7ffe4e4feec0, invocation_hint=0x7ffe4e4fee40) at ../gobject/gclosure.c:832
#6 0x00007f338f24be16 in signal_emit_unlocked_R.isra.0 (node=node@entry=0x561ed97977a0, detail=detail@entry=728, instance=instance@entry=0x561ed9e0b320, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffe4e4feec0) at ../gobject/gsignal.c:3812
#7 0x00007f338f23ccbd in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ffe4e4ff080) at ../gobject/gsignal.c:3565
#8 0x00007f338f23cf33 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at ../gobject/gsignal.c:3622
#9 0x00007f338f2286b4 in g_object_dispatch_properties_changed (object=0x561ed9e0b320, n_pspecs=<optimized out>, pspecs=<optimized out>) at ../gobject/gobject.c:1428
#10 0x00007f338f22bc67 in g_object_notify_by_spec_internal (pspec=<optimized out>, object=0x561ed9e0b320) at ../gobject/gobject.c:1552
#11 g_object_notify_by_pspec (object=object@entry=0x561ed9e0b320, pspec=<optimized out>) at ../gobject/gobject.c:1658
#12 0x00007f338ea1897c in clutter_stage_unlink_grab (stage=0x561ed9e0b320, grab=0x561eded13790) at ../clutter/clutter/clutter-stage.c:4273
#13 0x00007f338ea18ad5 in clutter_grab_dismiss (grab=<optimized out>) at ../clutter/clutter/clutter-stage.c:4304
#14 0x00007f338e6bd1b0 in meta_window_drag_end (window_drag=0x561eddedc640) at ../src/compositor/meta-window-drag.c:387
#15 0x00007f338f21d4ea in g_closure_invoke (closure=0x561edae73390, return_value=0x0, n_param_values=1, param_values=0x7ffe4e4ff3f0, invocation_hint=0x7ffe4e4ff370) at ../gobject/gclosure.c:832
#16 0x00007f338f24be16 in signal_emit_unlocked_R.isra.0 (node=node@entry=0x561eddb913a0, detail=detail@entry=0, instance=instance@entry=0x561ed9fb9aa0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffe4e4ff3f0) at ../gobject/gsignal.c:3812
#17 0x00007f338f23ccbd in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ffe4e4ff590) at ../gobject/gsignal.c:3565
#18 0x00007f338f23cf33 in g_signal_emit (instance=instance@entry=0x561ed9fb9aa0, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3622
#19 0x00007f338e6e6e2e in meta_window_unmanage (window=0x561ed9fb9aa0, timestamp=<optimized out>) at ../src/core/window.c:1431
#20 0x00007f338e75ae38 in meta_wayland_shell_surface_destroy_window (shell_surface=shell_surface@entry=0x561edb3827b0) at ../src/wayland/meta-wayland-shell-surface.c:305
#21 0x00007f338e75aebd in xdg_toplevel_destructor (resource=<optimized out>) at ../src/wayland/meta-wayland-xdg-shell.c:214
#22 0x00007f338c914791 in destroy_resource (element=0x561eddf104b0, data=data@entry=0x0, flags=0) at ../src/wayland-server.c:732
#23 0x00007f338c91672a in wl_resource_destroy (resource=<optimized out>) at ../src/wayland-server.c:749
#24 0x00007f338e75f2a6 in meta_wayland_xdg_toplevel_finalize (object=0x561edb3827b0) at ../src/wayland/meta-wayland-xdg-shell.c:1013
#25 0x00007f338f22ba53 in g_object_unref (_object=0x561edb3827b0) at ../gobject/gobject.c:3938
#26 g_object_unref (_object=0x561edb3827b0) at ../gobject/gobject.c:3802
#27 0x00007f338e755c7a in meta_wayland_surface_finalize (object=0x561ede335fd0) at ../src/wayland/meta-wayland-surface.c:1468
#28 0x00007f338f22ba53 in g_object_unref (_object=0x561ede335fd0) at ../gobject/gobject.c:3938
#29 g_object_unref (_object=0x561ede335fd0) at ../gobject/gobject.c:3802
#30 0x00007f338c914791 in destroy_resource (element=0x561edbf26ec0, data=data@entry=0x7ffe4e4ff8a4, flags=0) at ../src/wayland-server.c:732
#31 0x00007f338c914f2b in for_each_helper (entries=0x561ede33c7c0, data=0x7ffe4e4ff8a4, func=0x7f338c9146e0 <destroy_resource>) at ../src/wayland-util.c:416
#32 wl_map_for_each (data=0x7ffe4e4ff8a4, func=0x7f338c9146e0 <destroy_resource>, map=0x561ede33c7c0) at ../src/wayland-util.c:430
#33 wl_client_destroy (client=client@entry=0x561ede33c790) at ../src/wayland-server.c:928
#34 0x00007f338c9154b8 in wl_client_connection_data (fd=<optimized out>, mask=<optimized out>, data=0x561ede33c790) at ../src/wayland-server.c:343
#35 0x00007f338c9148e2 in wl_event_loop_dispatch (loop=0x561ed981a970, timeout=timeout@entry=0) at ../src/event-loop.c:1027
#36 0x00007f338e74118b in wayland_event_source_dispatch (base=<optimized out>, callback=<optimized out>, data=<optimized out>) at ../src/wayland/meta-wayland.c:125
#37 0x00007f338f11c4fc in g_main_dispatch (context=0x561ed979a920) at ../glib/gmain.c:3460
#38 g_main_context_dispatch (context=0x561ed979a920) at ../glib/gmain.c:4200
#39 0x00007f338f17a6b8 in g_main_context_iterate.isra.0 (context=0x561ed979a920, block=1, dispatch=1, self=<optimized out>) at ../glib/gmain.c:4276
#40 0x00007f338f11baff in g_main_loop_run (loop=0x561edb5fadc0) at ../glib/gmain.c:4479
#41 0x00007f338e6d54ea in meta_context_run_main_loop (context=context@entry=0x561ed9798cf0, error=error@entry=0x7ffe4e4ffeb0) at ../src/core/meta-context.c:482
#42 0x0000561ed8490fb7 in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.c:683
```
### Steps to reproduce
Not sure what I did exactly.
<!--
1. Step one
2. Step two
3. ...
-->
### What happened
<!--
What did GNOME Shell do that was unexpected?
-->
Crash.
### What did you expect to happen
<!--
What did you expect GNOME Shell to do?
-->
No crash.
### 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.
-->
<details><summary>bt full</summary>
```
#0 wl_resource_add_destroy_listener (resource=resource@entry=0x0, listener=listener@entry=0x561eda078e20) at ../src/wayland-server.c:842
No locals.
#1 0x00007f338e74fbcf in meta_wayland_keyboard_set_focus (keyboard=0x561eda078de0, surface=<optimized out>) at ../src/wayland/meta-wayland-keyboard.c:786
focus_surface_resource = 0x0
resource = <optimized out>
input_device = 0x561eda078de0
#2 0x00007f338e6c4ba5 in meta_wayland_seat_set_input_focus (surface=0x561ede335fd0, seat=0x561ed9d8bee0) at ../src/wayland/meta-wayland-seat.c:424
compositor = 0x561ed981a690
tablet_seat = <optimized out>
compositor = <optimized out>
tablet_seat = <optimized out>
#3 meta_wayland_compositor_set_input_focus (window=<optimized out>, compositor=<optimized out>) at ../src/wayland/meta-wayland.c:360
surface = 0x561ede335fd0
surface = <optimized out>
#4 meta_display_sync_wayland_input_focus (display=<optimized out>) at ../src/core/display.c:1411
compositor = <optimized out>
focus_window = <optimized out>
backend = <optimized out>
clutter_backend = <optimized out>
seat = 0x561ed9d8e7a0
stage = 0x561ed9e0b320
is_no_focus_xwindow = <optimized out>
#5 0x00007f338f21d4ea in g_closure_invoke (closure=0x561eda081220, return_value=0x0, n_param_values=2, param_values=0x7ffe4e4feec0, invocation_hint=0x7ffe4e4fee40) at ../gobject/gclosure.c:832
marshal = 0x7f338f222f00 <g_cclosure_marshal_VOID__PARAM>
marshal_data = 0x0
in_marshal = 0
real_closure = 0x561eda081200
__func__ = "g_closure_invoke"
#6 0x00007f338f24be16 in signal_emit_unlocked_R.isra.0 (node=node@entry=0x561ed97977a0, detail=detail@entry=728, instance=instance@entry=0x561ed9e0b320, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffe4e4feec0) at ../gobject/gsignal.c:3812
tmp = <optimized out>
handler = 0x561eda083250
accumulator = 0x0
emission = {next = 0x7ffe4e4ff360, instance = 0x561ed9e0b320, ihint = {signal_id = 1, detail = 728, run_type = (G_SIGNAL_RUN_FIRST | G_SIGNAL_ACCUMULATOR_FIRST_RUN)}, state = EMISSION_RUN, chain_type = 4}
class_closure = <optimized out>
hlist = <optimized out>
handler_list = 0x561ed9e217d0
return_accu = 0x0
accu = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
signal_id = 1
max_sequential_handler_number = 808788
return_value_altered = <optimized out>
EMIT_RESTART = <optimized out>
#7 0x00007f338f23ccbd in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ffe4e4ff080) at ../gobject/gsignal.c:3565
instance_and_params = <optimized out>
signal_return_type = <optimized out>
param_values = <optimized out>
node = <optimized out>
i = <optimized out>
n_params = <optimized out>
__func__ = "g_signal_emit_valist"
#8 0x00007f338f23cf33 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at ../gobject/gsignal.c:3622
var_args = {{gp_offset = 32, fp_offset = 48, overflow_arg_area = 0x7ffe4e4ff160, reg_save_area = 0x7ffe4e4ff0a0}}
#9 0x00007f338f2286b4 in g_object_dispatch_properties_changed (object=0x561ed9e0b320, n_pspecs=<optimized out>, pspecs=<optimized out>) at ../gobject/gobject.c:1428
i = <optimized out>
#10 0x00007f338f22bc67 in g_object_notify_by_spec_internal (pspec=<optimized out>, object=0x561ed9e0b320) at ../gobject/gobject.c:1552
nqueue = <optimized out>
need_thaw = <optimized out>
object_flags = <optimized out>
needs_notify = 1
in_init = <optimized out>
object_flags = <optimized out>
needs_notify = <optimized out>
in_init = <optimized out>
_g_boolean_var_49 = <optimized out>
nqueue = <optimized out>
need_thaw = <optimized out>
#11 g_object_notify_by_pspec (object=object@entry=0x561ed9e0b320, pspec=<optimized out>) at ../gobject/gobject.c:1658
__func__ = "g_object_notify_by_pspec"
#12 0x00007f338ea1897c in clutter_stage_unlink_grab (stage=0x561ed9e0b320, grab=0x561eded13790) at ../clutter/clutter/clutter-stage.c:4273
priv = 0x561ed9e0aec0
prev = <optimized out>
next = <optimized out>
was_grabbed = <optimized out>
__func__ = "clutter_stage_unlink_grab"
_g_boolean_var_70 = <optimized out>
#13 0x00007f338ea18ad5 in clutter_grab_dismiss (grab=<optimized out>) at ../clutter/clutter/clutter-stage.c:4304
__func__ = "clutter_grab_dismiss"
#14 0x00007f338e6bd1b0 in meta_window_drag_end (window_drag=0x561eddedc640) at ../src/compositor/meta-window-drag.c:387
grab_window = 0x561ed9fb9aa0
grab_op = META_GRAB_OP_WINDOW_BASE
display = 0x561eda07ed70
__func__ = "meta_window_drag_end"
#15 0x00007f338f21d4ea in g_closure_invoke (closure=0x561edae73390, return_value=0x0, n_param_values=1, param_values=0x7ffe4e4ff3f0, invocation_hint=0x7ffe4e4ff370) at ../gobject/gclosure.c:832
marshal = 0x7f338f2224d0 <g_cclosure_marshal_VOID__VOID>
marshal_data = 0x0
in_marshal = 0
real_closure = 0x561edae73370
__func__ = "g_closure_invoke"
#16 0x00007f338f24be16 in signal_emit_unlocked_R.isra.0 (node=node@entry=0x561eddb913a0, detail=detail@entry=0, instance=instance@entry=0x561ed9fb9aa0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffe4e4ff3f0) at ../gobject/gsignal.c:3812
tmp = <optimized out>
handler = 0x561eda1a79b0
accumulator = 0x0
emission = {next = 0x0, instance = 0x561ed9fb9aa0, ihint = {signal_id = 797, detail = 0, run_type = (G_SIGNAL_RUN_FIRST | G_SIGNAL_ACCUMULATOR_FIRST_RUN)}, state = EMISSION_RUN, chain_type = 4}
class_closure = <optimized out>
hlist = <optimized out>
handler_list = 0x561edd32c9a0
return_accu = 0x0
accu = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
signal_id = 797
max_sequential_handler_number = 808786
return_value_altered = <optimized out>
EMIT_RESTART = <optimized out>
#17 0x00007f338f23ccbd in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ffe4e4ff590) at ../gobject/gsignal.c:3565
instance_and_params = <optimized out>
signal_return_type = <optimized out>
param_values = <optimized out>
node = <optimized out>
i = <optimized out>
n_params = <optimized out>
__func__ = "g_signal_emit_valist"
#18 0x00007f338f23cf33 in g_signal_emit (instance=instance@entry=0x561ed9fb9aa0, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3622
var_args = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7ffe4e4ff670, reg_save_area = 0x7ffe4e4ff5b0}}
#19 0x00007f338e6e6e2e in meta_window_unmanage (window=0x561ed9fb9aa0, timestamp=<optimized out>) at ../src/core/window.c:1431
workspace_manager = <optimized out>
tmp = <optimized out>
__func__ = "meta_window_unmanage"
#20 0x00007f338e75ae38 in meta_wayland_shell_surface_destroy_window (shell_surface=shell_surface@entry=0x561edb3827b0) at ../src/wayland/meta-wayland-shell-surface.c:305
priv = 0x561edb382770
window = 0x561ed9fb9aa0
display = <optimized out>
timestamp = <optimized out>
__func__ = "meta_wayland_shell_surface_destroy_window"
#21 0x00007f338e75aebd in xdg_toplevel_destructor (resource=<optimized out>) at ../src/wayland/meta-wayland-xdg-shell.c:214
xdg_toplevel = 0x561edb3827b0
shell_surface = 0x561edb3827b0
#22 0x00007f338c914791 in destroy_resource (element=0x561eddf104b0, data=data@entry=0x0, flags=0) at ../src/wayland-server.c:732
resource = 0x561eddf104b0
#23 0x00007f338c91672a in wl_resource_destroy (resource=<optimized out>) at ../src/wayland-server.c:749
client = 0x561ede33c790
id = 46
flags = <optimized out>
#24 0x00007f338e75f2a6 in meta_wayland_xdg_toplevel_finalize (object=0x561edb3827b0) at ../src/wayland/meta-wayland-xdg-shell.c:1013
_pp = 0x561edb3827c8
_ptr = <optimized out>
xdg_toplevel = 0x561edb3827b0
#25 0x00007f338f22ba53 in g_object_unref (_object=0x561edb3827b0) at ../gobject/gobject.c:3938
weak_locations = <optimized out>
nqueue = 0x561edae43950
object = <optimized out>
old_ref = <optimized out>
retry_atomic_decrement1 = <optimized out>
object = <optimized out>
old_ref = <optimized out>
__func__ = <optimized out>
retry_atomic_decrement1 = <optimized out>
_g_boolean_var_133 = <optimized out>
gaig_temp = <optimized out>
weak_locations = <optimized out>
nqueue = <optimized out>
gaig_temp = <optimized out>
_pp = <optimized out>
_ptr = <optimized out>
gaig_temp = <optimized out>
gaig_temp = <optimized out>
_g_boolean_var_144 = <optimized out>
_g_boolean_var_145 = <optimized out>
#26 g_object_unref (_object=0x561edb3827b0) at ../gobject/gobject.c:3802
object = 0x561edb3827b0
old_ref = <optimized out>
retry_atomic_decrement1 = <optimized out>
__func__ = "g_object_unref"
gaig_temp = <optimized out>
weak_locations = <optimized out>
nqueue = <optimized out>
gaig_temp = <optimized out>
_pp = <optimized out>
_ptr = <optimized out>
gaig_temp = <optimized out>
gaig_temp = <optimized out>
_g_boolean_var_144 = <optimized out>
_g_boolean_var_145 = <optimized out>
#27 0x00007f338e755c7a in meta_wayland_surface_finalize (object=0x561ede335fd0) at ../src/wayland/meta-wayland-surface.c:1468
_pp = 0x561ede335ff8
_ptr = <optimized out>
surface = 0x561ede335fd0
compositor = 0x561ed981a690
cb = <optimized out>
next = <optimized out>
#28 0x00007f338f22ba53 in g_object_unref (_object=0x561ede335fd0) at ../gobject/gobject.c:3938
weak_locations = <optimized out>
nqueue = 0x561eda2fc580
object = <optimized out>
old_ref = <optimized out>
retry_atomic_decrement1 = <optimized out>
object = <optimized out>
old_ref = <optimized out>
__func__ = <optimized out>
retry_atomic_decrement1 = <optimized out>
_g_boolean_var_133 = <optimized out>
gaig_temp = <optimized out>
weak_locations = <optimized out>
nqueue = <optimized out>
gaig_temp = <optimized out>
_pp = <optimized out>
_ptr = <optimized out>
gaig_temp = <optimized out>
gaig_temp = <optimized out>
_g_boolean_var_144 = <optimized out>
_g_boolean_var_145 = <optimized out>
#29 g_object_unref (_object=0x561ede335fd0) at ../gobject/gobject.c:3802
object = 0x561ede335fd0
old_ref = <optimized out>
retry_atomic_decrement1 = <optimized out>
__func__ = "g_object_unref"
gaig_temp = <optimized out>
weak_locations = <optimized out>
nqueue = <optimized out>
gaig_temp = <optimized out>
_pp = <optimized out>
_ptr = <optimized out>
gaig_temp = <optimized out>
gaig_temp = <optimized out>
_g_boolean_var_144 = <optimized out>
_g_boolean_var_145 = <optimized out>
#30 0x00007f338c914791 in destroy_resource (element=0x561edbf26ec0, data=data@entry=0x7ffe4e4ff8a4, flags=0) at ../src/wayland-server.c:732
resource = 0x561edbf26ec0
#31 0x00007f338c914f2b in for_each_helper (entries=0x561ede33c7c0, data=0x7ffe4e4ff8a4, func=0x7f338c9146e0 <destroy_resource>) at ../src/wayland-util.c:416
idx = <optimized out>
ret = WL_ITERATOR_CONTINUE
entry = <optimized out>
start = <optimized out>
count = <optimized out>
ret = <optimized out>
entry = <optimized out>
start = <optimized out>
count = <optimized out>
idx = <optimized out>
#32 wl_map_for_each (data=0x7ffe4e4ff8a4, func=0x7f338c9146e0 <destroy_resource>, map=0x561ede33c7c0) at ../src/wayland-util.c:430
ret = <optimized out>
#33 wl_client_destroy (client=client@entry=0x561ede33c790) at ../src/wayland-server.c:928
serial = 0
#34 0x00007f338c9154b8 in wl_client_connection_data (fd=<optimized out>, mask=<optimized out>, data=0x561ede33c790) at ../src/wayland-server.c:343
client = 0x561ede33c790
connection = <optimized out>
resource = <optimized out>
object = <optimized out>
closure = <optimized out>
message = <optimized out>
p = {3753545488, 22046}
resource_flags = <optimized out>
opcode = <optimized out>
size = <optimized out>
since = <optimized out>
len = <optimized out>
#35 0x00007f338c9148e2 in wl_event_loop_dispatch (loop=0x561ed981a970, timeout=timeout@entry=0) at ../src/event-loop.c:1027
ep = {{events = 17, data = {ptr = 0x561edd4a0ff0, fd = -582348816, u32 = 3712618480, u64 = 94690561626096}}, {events = 0, data = {ptr = 0x7ffe4e4ffaf0, fd = 1313864432, u32 = 1313864432, u64 = 140730212285168}}, {events = 593265408, data = {ptr = 0x4e4ffb4040f0c33b, fd = 1089520443, u32 = 1089520443, u64 = 5643005111504519995}}, {events = 32766, data = {ptr = 0x7f338f186bf0, fd = -1894224912, u32 = 2400742384, u64 = 139859420802032}}, {events = 2400706750, data = {ptr = 0x4e4ffbe000007f33, fd = 32563, u32 = 32563, u64 = 5643005797609799475}}, {events = 32766, data = {ptr = 0x7fffffff, fd = 2147483647, u32 = 2147483647, u64 = 2147483647}}, {events = 3653769520, data = {ptr = 0x4e4ffbd00000561e, fd = 22046, u32 = 22046, u64 = 5643005728890312222}}, {events = 32766, data = {ptr = 0x7f338f17bdee <sysprof_collector_mark_vprintf+62>, fd = -1894269458, u32 = 2400697838, u64 = 139859420757486}}, {events = 0, data = {ptr = 0x7b600000000, fd = 0, u32 = 0, u64 = 8478265442304}}, {events = 0, data = {ptr = 0x4cf2da6c26d4, fd = -630446380, u32 = 3664520916, u64 = 84605930317524}}, {events = 2401140612, data = {ptr = 0x7f33, fd = 32563, u32 = 32563, u64 = 32563}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x235c830000000000, fd = 0, u32 = 0, u64 = 2548055525208096768}}, {events = 1089520443, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 3648629024, data = {ptr = 0x4e4ffd200000561e, fd = 22046, u32 = 22046, u64 = 5643007171999323678}}, {events = 32766, data = {ptr = 0x7ffe4e4ffd08, fd = 1313864968, u32 = 1313864968, u64 = 140730212285704}}, {events = 2147483647, data = {ptr = 0xd9c8193000000000, fd = 0, u32 = 0, u64 = 15692820595521617920}}, {events = 22046, data = {ptr = 0x7ffe4e4ffcb0, fd = 1313864880, u32 = 1313864880, u64 = 140730212285616}}, {events = 593265408, data = {ptr = 0x2840f0c33b, fd = 1089520443, u32 = 1089520443, u64 = 172888212283}}, {events = 48, data = {ptr = 0xffffffffffffff88, fd = -120, u32 = 4294967176, u64 = 18446744073709551496}}, {events = 11, data = {ptr = 0xd9aa3d9000000000, fd = 0, u32 = 0, u64 = 15684416340955758592}}, {events = 22046, data = {ptr = 0x7f338e741170 <wayland_event_source_dispatch>, fd = -1904995984, u32 = 2389971312, u64 = 139859410030960}}, {events = 0, data = {ptr = 0x4e4ffc5000000000, fd = 0, u32 = 0, u64 = 5643006278646104064}}, {events = 32766, data = {ptr = 0x7f338e4bf20e <__GI___libc_free+126>, fd = -1907625458, u32 = 2387341838, u64 = 139859407401486}}, {events = 1313864784, data = {ptr = 0xd9c8102000007ffe, fd = 32766, u32 = 32766, u64 = 15692810631197523966}}, {events = 22046, data = {ptr = 0x7ffe4e4ffc80, fd = 1313864832, u32 = 1313864832, u64 = 140730212285568}}, {events = 3651812768, data = {ptr = 0x200000561e, fd = 22046, u32 = 22046, u64 = 137438975518}}, {events = 0, data = {ptr = 0x561ed97775d0, fd = -646482480, u32 = 3648484816, u64 = 94690497492432}}, {events = 1313864816, data = {ptr = 0x8e5231b100007ffe, fd = 32766, u32 = 32766, u64 = 10255313937755045886}}, {events = 32563, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 8, data = {ptr = 0x4e4ffc9000000000, fd = 0, u32 = 0, u64 = 5643006553524011008}}, {events = 32766, data = {ptr = 0x8, fd = 8, u32 = 8, u64 = 8}}}
source = <optimized out>
i = 0
count = <optimized out>
has_timers = <optimized out>
#36 0x00007f338e74118b in wayland_event_source_dispatch (base=<optimized out>, callback=<optimized out>, data=<optimized out>) at ../src/wayland/meta-wayland.c:125
source = <optimized out>
loop = <optimized out>
#37 0x00007f338f11c4fc in g_main_dispatch (context=0x561ed979a920) at ../glib/gmain.c:3460
dispatch = 0x7f338e741170 <wayland_event_source_dispatch>
prev_source = 0x0
begin_time_nsec = 84605930321311
was_in_call = 0
user_data = 0x0
callback = 0x0
cb_funcs = 0x0
cb_data = 0x0
need_destroy = <optimized out>
source = 0x561ed981ab70
current = 0x561ed97775d0
i = 0
current = <optimized out>
i = <optimized out>
__func__ = <optimized out>
source = <optimized out>
_g_boolean_var_163 = <optimized out>
was_in_call = <optimized out>
user_data = <optimized out>
callback = <optimized out>
cb_funcs = <optimized out>
cb_data = <optimized out>
need_destroy = <optimized out>
dispatch = <optimized out>
prev_source = <optimized out>
begin_time_nsec = <optimized out>
_g_boolean_var_164 = <optimized out>
#38 g_main_context_dispatch (context=0x561ed979a920) at ../glib/gmain.c:4200
No locals.
#39 0x00007f338f17a6b8 in g_main_context_iterate.isra.0 (context=0x561ed979a920, block=1, dispatch=1, self=<optimized out>) at ../glib/gmain.c:4276
max_priority = 2147483647
timeout = 1
some_ready = 1
nfds = 12
allocated_nfds = <optimized out>
fds = <optimized out>
begin_time_nsec = 84605929995780
#40 0x00007f338f11baff in g_main_loop_run (loop=0x561edb5fadc0) at ../glib/gmain.c:4479
self = <optimized out>
__func__ = "g_main_loop_run"
#41 0x00007f338e6d54ea in meta_context_run_main_loop (context=context@entry=0x561ed9798cf0, error=error@entry=0x7ffe4e4ffeb0) at ../src/core/meta-context.c:482
priv = 0x561ed9798c70
__func__ = "meta_context_run_main_loop"
#42 0x0000561ed8490fb7 in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.c:683
context = 0x561ed9798cf0
error = 0x0
ecode = 0
```
</details>
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3058CapsLock does not work for French accent characters in Wayland2024-01-26T09:49:09ZTakao FujiwaraCapsLock does not work for French accent characters in Wayland<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
* Fedora 39
* gnome-shell-45.0, mutter-45.0, gtk4-4.12.2, gtk3...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
* Fedora 39
* gnome-shell-45.0, mutter-45.0, gtk4-4.12.2, gtk3-3.24.38
* Wayland only
<!--
Provide at least the following information:
* Your OS and version
* Affected Mutter version
* Does this issue appear in XOrg and/or Wayland
-->
### Bug summary
Reported in https://bugzilla.redhat.com/show_bug.cgi?id=2240490
Using Fedora 39 with GNOME Wayland environment and AZERTY (French) layout, CapsLock works for ASCII characters but does not work for accented characters.
<!--
Provide a short summary of the bug you encountered.
-->
### Steps to reproduce
The purpose is to get upper case character with accent. Shift lock + é = É. It's the behaviour until Fedora 38. Since Fedora 39, Shift lock + é = é. Obviously for characters without accents, the character is upper case.
This issue happens for other characters like èàçù...
<!--
1. Step one
2. Step two
3. ...
-->
### What happened
CapsLock + é = é
<!--
What did Mutter do that was unexpected?
-->
### What did you expect to happen
CapsLock + é = É
<!--
What did you expect Mutter to do?
-->
### 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.
-->
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3054mutter 44.5 freezes on Linux 6.5.x kernel2023-11-10T07:23:26ZBohdan Shkliarenkomutter 44.5 freezes on Linux 6.5.x kernelSetup:
```
ArchLinux
AMD Ryzen 9 6900HX
GPU0: AMD ATI Radeon 680M
GPU1: AMD ATI Radeon RX 6600/6600 XT/6600M
64GB DDR5 ram
Samsung evo 970 nvme drive
(super fast PC)
Gnome 44.5 from ArchLinux stable branch, latest mesa - v23.1.8-1
``...Setup:
```
ArchLinux
AMD Ryzen 9 6900HX
GPU0: AMD ATI Radeon 680M
GPU1: AMD ATI Radeon RX 6600/6600 XT/6600M
64GB DDR5 ram
Samsung evo 970 nvme drive
(super fast PC)
Gnome 44.5 from ArchLinux stable branch, latest mesa - v23.1.8-1
```
Problem:
When **Linux 6.5** released - I installed this kernel (stable archlinux repository)
It enables amd p-state epp driver (active) for my CPU by default, so ofc I want to use this kernel. And power daemon also supports this driver, so all tests here done in Performance mode for **6.5.x** kernels. In **6.4** or **6.1** kernel it's just old acpi-cpufreq
![image](/uploads/f0e67496d97d326b7a76cc398766d035/image.png)
But suddenly I noticed that gnome started freezing when changing focused window.
Okay, updated from **6.5.2** to **6.5.3**, than to **6.5.4**. Tried zen kernel. Today updated to **6.5.5** - still freezing.
But on **6.4** or **6.1-lts** kernels everything is fine. I can just select **6.4** or **6.1** from GRUB menu, load it and live without freezes.
Tried to disable ALL extension - same, freezes. It can freeze up to 1-3 seconds, also cursor is not moving. Sound still playing btw, so I it's not whole system freeze, just mutter. And it's not fTPM freezes, it's disabled in BIOS.
Examples when it freezing:
- Open gnome overview
- Volume up/down OSD menu appears
- Open application (like terminal, nautilus, telegram, browser, obs, any new window basically)
- Exit fullscreen mode when playing youtube video or enter fullscreen mode
- Alt-tab to any fullscreen window or from fullscreen to windowed
- etc...
And it's super random, when I didn't change focus for a long time - there is gonna be a freeze. If there was a freeze - I can change focus between this window for a lot of times without freezes.
Just recorded how it looks like (sorry for not using OBS):
https://youtu.be/-hSC1Z1kf6o So, game was working on background (There game sounds, also it's fullscreen, browser sitting on top, so game keep rendering stuff)
I changed focus from browser to game - and it freezes for few seconds.
https://youtu.be/ybLLanjjAZ4 Here I just open overview - and freeze for no reason.
https://youtu.be/vAebeyIchQk - youtube - enter fullscreen mode freeze
**And it never happens on 6.4 or 6.1-lts kernel.**
Also there is no errors in journalctl. It's only related to current kernel.
UPD: it happens on X11 and Wayland, no difference.https://gitlab.gnome.org/GNOME/mutter/-/issues/3031Direct scanout is broken for NV12 and P010 on Intel2024-02-12T10:13:51ZRobert Maderrobert.mader@posteo.deDirect scanout is broken for NV12 and P010 on Intel### Mesa issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9952
### Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25603
---
STR:
- use Mutter with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3286...### Mesa issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9952
### Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25603
---
STR:
- use Mutter with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3286 (`45.1`?)
- download e.g. https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/1080/Big_Buck_Bunny_1080_10s_30MB.mp4 to `~/Videos`
- build `mpv` from main (>= the upcoming(?) 0.36.1 release)
- set the resolution of the screen to `1920x1080` (or have https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177 applied to Mutter)
- run `mpv --hwdec=vaapi --vo=dmabuf-wayland -fs ~/Videos/Big_Buck_Bunny_1080_10s_30MB.mp4`
You should see something like the following:
![2023-09-17-19-23-09-998](/uploads/f02e8caee36c92ff3edec41b1e882802/2023-09-17-19-23-09-998.jpg)
![2023-09-17-19-32-51-583](/uploads/5cd2e0de4d6662069a433ca7922fe63a/2023-09-17-19-32-51-583.jpg)
This has been reproduced on several Intel devices. It doesn't affect e.g. AMD or other formats[1].
My suspicion here is that that it's a kms driver bug only affecting the primary plane. Compositors like Weston, that usually use an overlay plane here, are apparently not affected.
I also double-checked that this is not about wrong passing of drm format modifiers - the same issue is visible when forcing `mpv` to use an invalid/implicit modifier instead of the explicit one (which in all tested cases was `INTEL_Y_TILED`).
1: You can try `YUYV`/`yuyv422` with `mpv --hwdec=vaapi --vo=dmabuf-wayland --vf=format=yuyv422 --fs ~/Videos/Big_Buck_Bunny_1080_10s_30MB.mp4`