mutter issueshttps://gitlab.gnome.org/GNOME/mutter/-/issues2024-03-16T18:15:58Zhttps://gitlab.gnome.org/GNOME/mutter/-/issues/3365Multi-monitor screenshots going beyond screen boundaries will record garbled ...2024-03-16T18:15:58ZJeff FortinMulti-monitor screenshots going beyond screen boundaries will record garbled visual artifactsWith Mutter / GNOME Shell 45.4 on Wayland, and any previous version (I think it also previously happened on Xorg):
1. Set up two displays in a way that they are not entirely aligned (easiest is using one landscape and one portrait displ...With Mutter / GNOME Shell 45.4 on Wayland, and any previous version (I think it also previously happened on Xorg):
1. Set up two displays in a way that they are not entirely aligned (easiest is using one landscape and one portrait display), like this for example:
![image](/uploads/1168b62d8a412561b6f68b4ede525b3d/image.png)
2. `PrintScreen` to bring up GNOME Shell's screenshot tool
3. Start dragging the screenshot area on one screen
4. Drag one of its crop handles, or drag the whole screenshot area (i.e. move the area) in a way that overlays an off-screen area
Result:
![GNOME_Shell_out-of-screen-boundary_artifacts_-_happens_with_screenshots_-_crop.opti](/uploads/1b21f2a5a1cfd21c0ff94b657d5c02d4/GNOME_Shell_out-of-screen-boundary_artifacts_-_happens_with_screenshots_-_crop.opti.png)
Tested on my open source AMD Radeon graphics driver from Mesa on Fedora 39. I think this also affects other drivers as well.
This does _not_ affect video recording anymore (at least, not with version 45.x), only screenshots, and the magnifier (as seen in #3362). Video recording, instead of putting garbled artifacts there, just records a blank area made out of a solid black color.https://gitlab.gnome.org/GNOME/mutter/-/issues/3331Games Do Not Detect Native Screen Resolution with Fractional Scaling Set to 2...2024-03-05T13:02:17ZVincent DelorGames Do Not Detect Native Screen Resolution with Fractional Scaling Set to 25% on Wayland### Affected Version
```
fedora:fedora/40/x86_64/silverblue
Version: 40.20240304.n.0 (2024-03-04T07:52:47Z)
BaseCommit: 857b0c3de2e18bcb3f201b7775cddd8a2319c57e272928a319d64d038bc396b8
GPGSi...### Affected Version
```
fedora:fedora/40/x86_64/silverblue
Version: 40.20240304.n.0 (2024-03-04T07:52:47Z)
BaseCommit: 857b0c3de2e18bcb3f201b7775cddd8a2319c57e272928a319d64d038bc396b8
GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC
RemovedBasePackages: firefox firefox-langpacks 123.0-2.fc40
LayeredPackages: akmod-nvidia gnome-tweaks goverlay langpacks-fr lutris mangohud steam touchegg wine xorg-x11-drv-nvidia xorg-x11-drv-nvidia-cuda xorg-x11-drv-nvidia-libs xpadneo
Kernel Version: 6.8.0-0.rc6.49.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 32 × Intel® Core™ i9-14900HX
Memory: 31.0 Gio of RAM
Graphics Processor: Mesa Intel® Graphics
Discrete Graphics Processor: Nvidia RTX 4090 Laptop
Manufacturer: Alienware
Product Name: Alienware m18 R2
```
- Issue on Wayland only
- Issue occurs when fractional scaling is set at 25%.
- Issue on Silverblue 39/40
### Bug Summary
Under Wayland with fractional scaling set to 25%, games do not detect the native screen resolution of 2560x1600. Instead, the maximum resolution available in-game is limited to 2048x1280. This issue does not occur under XOrg or without fractional scaling enabled.
### Steps to Reproduce
1. Set the display to use Wayland.
2. Enable fractional scaling and set it to 25%.
3. Launch a game and access its video settings.
### What Happened
The game does not recognize or list the native screen resolution (2560x1600) as an available option. The highest resolution available is 2048x1280, leading to a suboptimal gaming experience.
### What Did You Expect to Happen
I expected the game to detect and allow selection of the native screen resolution of 2560x1600, regardless of the fractional scaling settings under Wayland.
### Screencasts.
- **Screencast demonstrating the issue on Silverblue**: [https://www.youtube.com/watch?v=gRs6m8MBJDE)
- **Comparative screencast showing expected behavior on Kinoite**: [https://youtu.be/EnqVOo7Ka0k]
This issue seems to be specific to the interaction between Wayland's handling of fractional scaling and how games detect available screen resolutions. Addressing it could improve the gaming experience on high-resolution displays under Wayland, especially when fractional scaling is used to optimize the desktop environment for high DPI screens.https://gitlab.gnome.org/GNOME/mutter/-/issues/3301Dual monitor, mouse moves in wrong orientation on lock screen2024-03-11T12:56:56ZAlexandre FrankeDual monitor, mouse moves in wrong orientation on lock screenTwo identical monitors, primary one is “Portrait Right”, while the secondary one is in landscape. On lock screen, for the vertical monitor, mouse pointer moves as if it was landscape (mouse right moves pointer down), but the mouse pointe...Two identical monitors, primary one is “Portrait Right”, while the secondary one is in landscape. On lock screen, for the vertical monitor, mouse pointer moves as if it was landscape (mouse right moves pointer down), but the mouse pointer is drawn in the correct orientation. [monitors.xml](/uploads/6cc6e8e73ecf78739828a6546c91bf61/monitors.xml) is identical in `~/.config/` and `/var/lib/gdm/.config/`.
It used to work correctly, but I don’t use the mouse often enough to tell when this broke. This is on an up to date Fedora 39 (`mutter-45.4-1.fc39`).https://gitlab.gnome.org/GNOME/mutter/-/issues/3246Modal windows appear in wrong monitor2024-02-27T11:07:41ZMaximilianoModal windows appear in wrong monitor<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
* Fedora Silverblue 39
* Affected Mutter version: 45.3
* Wayl...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
* Fedora Silverblue 39
* Affected Mutter version: 45.3
* Wayland
### Bug summary
Modal dialogs spawn in the wrong monitor, using the scale of the wrong monitor.
### Steps to reproduce
* Main monitor is a 24' screen on the right at 1920x1080 at 144hz.
* Secondary monitor is a 50' TV On the left at 3840x2160 at 60hz 'Adjust for TV' is ON and scale 200%
* Open steam in the main monitor
* Open an app on main monitor, probably move it closer to the top-left edge, but keep it entirely inside the main monitor
* Open a modal file picker in the app
### What happened
The corner of the app is in the wrong monitor.
### What did you expect to happen
The modal window spawns entirely inside the current monitor, same as the case where there is a single monitor
### Relevant logs, screenshots, screencasts etc.
![Screencast_from_2024-01-14_16-07-13](/uploads/de2a400b875e903b2340b81aecfa0b75/Screencast_from_2024-01-14_16-07-13.webm)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3245Unable to move window between monitors2024-01-25T19:45:08ZMaximilianoUnable to move window between monitors
### Affected version
* Fedora Silverblue 39
* mutter 45.3
* Wayland
### Bug summary
Sometimes a full-screen application will remain in its current monitor after dragging it to the other monitor from the overview.
### Steps to reprod...
### Affected version
* Fedora Silverblue 39
* mutter 45.3
* Wayland
### Bug summary
Sometimes a full-screen application will remain in its current monitor after dragging it to the other monitor from the overview.
### Steps to reproduce
- Main monitor is a 24' screen on the right at 1920x1080 at 144hz.
- Secondary monitor is a 50' TV On the left at 3840x2160 at 60hz 'Adjust for TV' is ON and scale 200%
- Open steam in the main monitor
- Open a full screen game (I used dark souls). Here it does not matter whether it is full screen or borderless
- press the windows key and drag the game to the other monitor
### What happened
App remains on main monitor
### What did you expect to happen
App is on the secondary monitor
### Relevant logs, screenshots, screencasts etc.
The only relevant thing on the logs is:
```
ene 14 16:00:05 alpha gnome-shell[2686]: Window manager warning: Window 0x4400003 sets an MWM hint indicating it isn't resizable, but sets min size 1 x 1 and max size 2147483647 x 2147483647; this doesn't make much sense.
ene 14 16:00:25 alpha gnome-shell[2686]: Window manager warning: Window 0x4400003 sets an MWM hint indicating it isn't resizable, but sets min size 1 x 1 and max size 2147483647 x 2147483647; this doesn't make much sense.
```
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3232Background wallpaper is blank on Intel Gen32024-03-18T23:58:07ZBalló GyörgyBackground wallpaper is blank on Intel Gen3Using the Gallium-based i915 driver for Intel's Gen3 GPUs, the default background image is not rendered on the desktop, I can see only black color. It happens under both Wayland and Xorg. It doesn't happen if I set 'picture-options' to '...Using the Gallium-based i915 driver for Intel's Gen3 GPUs, the default background image is not rendered on the desktop, I can see only black color. It happens under both Wayland and Xorg. It doesn't happen if I set 'picture-options' to 'centered', but it happens with all other values. I tried various image files, and I found that the problem occurs only with some specific image sizes (multiples of 2048):
- 2048×2048
- 4096×4096
- 4097×4097
- 8192×8192
- 8193×8193
- 8194×8194
The driver reports `GL_MAX_TEXTURE_SIZE = 2048`, which seems to be correct. I tested it with a simple WebGL code, and it's able to load an image with 2048×2048 as maximum size. So I guess it's a bug in mutter rather than in the driver.
Display controller:
Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02)
Package versions:
- mutter 45.2
- mesa 23.3.1
- linux 6.6.8
Distribution:
Arch Linux
I created !3477 which is a simple way to fix this problem.
I also reported this issue to mesa here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10410https://gitlab.gnome.org/GNOME/mutter/-/issues/3229xdg-toplevel is marked as suspended while it's visible and renders2024-01-23T23:51:36ZKirill Chibisovxdg-toplevel is marked as suspended while it's visible and renders### Affected version
45.2, probably broken right after when suspended was added.
This is all on fedora 39 without any extensions to gnome shell.
### Bug summary
The window has `SUSPENDED` state for the first configure preventing it f...### Affected version
45.2, probably broken right after when suspended was added.
This is all on fedora 39 without any extensions to gnome shell.
### Bug summary
The window has `SUSPENDED` state for the first configure preventing it from being shown
when the client uses that information to decide when to render or not.
### Steps to reproduce
You'd need alacritty 0.13.0 and run it with
`alacritty -o "window.startup_mode='Maximized'"` or `Fullscreen` instead of maximized.
This is **not** happening when the window is run without those mods.
### What happened
Window is invisible because it thinks that it's suspended, thus it doesn't try to render.
### What did you expect to happen
Never set `SUSPENDED` for the first configure.
### Relevant logs, screenshots, screencasts etc.
`WAYLAND_DEBUG=1` log interleaved with some extra alacritty logging and a configure dump.
[log.txt](/uploads/8f300531cb3eacb2b5a8c60f2ccd1729/log.txt)https://gitlab.gnome.org/GNOME/mutter/-/issues/3105mutter draws flickering cursor artifacts on top of screencasts of virtual mon...2024-01-25T06:05:54ZPascal Nowackmutter draws flickering cursor artifacts on top of screencasts of virtual monitorsAffected version: mutter/main, gnome-shell/main
This issue is very visible since at least GNOME 45.
Reproduction steps:
1. Create a screencast session using mutters dbus interfaces (e.g. by using g-r-d)
2. Create a virtual monitor stre...Affected version: mutter/main, gnome-shell/main
This issue is very visible since at least GNOME 45.
Reproduction steps:
1. Create a screencast session using mutters dbus interfaces (e.g. by using g-r-d)
2. Create a virtual monitor stream using `RecordVirtual()` with the cursor mode `metadata`
3. Optionally create another virtual monitor in the same screencast session, as this bug is much more visible on secondary virtual monitors created in the same screencast session
Observation: While the cursor bitmap is received as metadata, the cursor is also occasionally (or rather a bit more than occasionally) painted on top of the actual monitor (which is not wanted). This cursor artifact might be directly be painted over, so it just flickers shortly, but sometimes this does not always happen (see the screencasts below)
Reproduced here with g-r-d, where mutter runs in a nested dbus session (no physical monitors are here present)
With g-r-d's RDP backend, this is lesser visible with one monitor (compared to g-r-d's VNC backend), as the cursor artifact seems to be directly painted over by mutter. I think this is due to that g-r-d's VNC backend only sends the updated cursor position to mutter, when the x- or y-pos actually changed, while the RDP backend just forwards everything to mutter.
Reproduction with the RDP backend (screencast):
![Bildschirmaufzeichnung_vom_2023-10-21__10-51-45](/uploads/8903acc37a68da8283610c2364026a22/Bildschirmaufzeichnung_vom_2023-10-21__10-51-45.webm)
As you can see in the screencast, there is a following flickering cursor painted on top of the actual screencast (although the cursor mode `metadata` is used). This should not happen at any time here.
Reproduction with the VNC backend (screencast):
![Bildschirmaufzeichnung_vom_2023-10-21__10-55-05](/uploads/d2481e8d2d128d94f5ac6a03848704d8/Bildschirmaufzeichnung_vom_2023-10-21__10-55-05.webm)
As you can see in the screencast, the same behaviour can be reproduced with the VNC backend. The bug is here very visible with the loading cursor (when attempting to start gnome-terminal), where mutter just paints all these cursor artifacts on top the screencast stream. When moving over these cursors, mutter draws over them, so they disappear. But at the same time, new artifacts might be drawn over the same position.
This bug only happens with virtual monitors and only when `RecordVirtual()` is used to invoke the stream.
CC: @jadahl We need to get rid of this bug for headless sessions (46.0), as we use virtual monitors there.https://gitlab.gnome.org/GNOME/mutter/-/issues/3068Dialogs in Fedora installer partitioning tool sometimes do not respond to mou...2023-11-25T16:28:38ZAdam WilliamsonDialogs in Fedora installer partitioning tool sometimes do not respond to mouse input (Fedora 39, GNOME 45)This is an upstream report of https://bugzilla.redhat.com/show_bug.cgi?id=2239128 . It seems rather similar to e.g. https://gitlab.gnome.org/GNOME/mutter/-/issues/2918 and https://gitlab.gnome.org/GNOME/mutter/-/issues/2117 - which were ...This is an upstream report of https://bugzilla.redhat.com/show_bug.cgi?id=2239128 . It seems rather similar to e.g. https://gitlab.gnome.org/GNOME/mutter/-/issues/2918 and https://gitlab.gnome.org/GNOME/mutter/-/issues/2117 - which were both to do with mutter surface tracking - so I'm assuming this is in the same area.
The bug manifests when running the Fedora installer on the Workstation (GNOME) live image, and using the "advanced custom" partitioning option. When the 'advanced partitioning' UI opens a dialog - e.g. to show partition information, or provide formatting information for a partition, or something - sometimes that dialog cannot be interacted with using the mouse. Keyboard interaction works OK.
The bug doesn't happen every time, and the incidence seems to vary from person to person (so there's probably some relationship to system performance, or something). However, everyone who's tried has reproduced it at least sometimes (that's four different people so far).
To reproduce, download e.g. https://kojipkgs.fedoraproject.org/compose/branched/Fedora-39-20231004.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-39-20231004.n.0.iso , boot it, run the installer, click Installation Destination, ensure a disk is selected, click "Advanced Custom (Blivet-GUI)", click Done, right-click an existing partition (create one first if there isn't one), click Information. See if you can click the Close button on the resulting dialog. If you can, try it a few more times. Maybe try with not the right-most partition (as lruzicka suggests).
For me, in a quick trial, it fails about 50-60% of the time in a VM with an existing three-partition layout, using the second partition to reproduce.
Unfortunately it's a bit difficult to get debugging information when the bug happens in the installer like this, but I'll try.https://gitlab.gnome.org/GNOME/mutter/-/issues/3079tiled display flickering and artifacts when using accessibility filter2024-03-16T18:10:53ZTFFtiled display flickering and artifacts when using accessibility filterwhen using any accessibility filter, the screen will split down the middle and start flickering and only update one half of the screen
monitor model: LG 27MD5K
GPU: Intel XE 11th gen
tested with these extensions:
https://github.com...when using any accessibility filter, the screen will split down the middle and start flickering and only update one half of the screen
monitor model: LG 27MD5K
GPU: Intel XE 11th gen
tested with these extensions:
https://github.com/G-dH/gnome-colorblind-filters/tree/esm-modules
https://extensions.gnome.org/extension/4012/gnome-bedtime/
![IMG_1969](/uploads/c3113e1bdb4cbc45408db373812f7f41/IMG_1969.mov)https://gitlab.gnome.org/GNOME/mutter/-/issues/3049Invisible webview windows in GOG Galaxy (Wine) since Mutter 442023-10-13T12:41:13ZJonatas EstevesInvisible webview windows in GOG Galaxy (Wine) since Mutter 44<!--
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 38-39
* Mutter 44-45
* Both Wayland and X11
### Bug summary
<!--
Provide a short summary of the bug you encountered.
-->
This issue is a follow-up to #3005 about the invisible installer window.
Since GNOME 44, some windows of GOG Galaxy (a Windows app running through Wine) are invisible on gnome-shell. Specifically in this follow-up issue I refer to the Chrome Webviews used to log in to the integrations with other game stores. This window is transparent, it can be closed from the Activities Overview, where it shows as a transparent surface, but its icon and name are visible and the X button to close it is accessible.
This issue is somewhat intermittent. Most times the window is invisible, but a few times it may show as a black surface, and some other times it may show the correct content.
Here are pictures of the expected result and an instance of a black surface, Xbox and Ubisoft accounts in this example, but applies to all:
![Screenshot_from_2023-09-19_21-10-49](/uploads/955ba224e86e1c51e345e6c9d98802d6/Screenshot_from_2023-09-19_21-10-49.png)
![Screenshot_from_2023-09-19_20-58-51](/uploads/9204aa6db38f477cf6c19bed56fa48b8/Screenshot_from_2023-09-19_20-58-51.png)
### Steps to reproduce
<!--
1. Step one
2. Step two
3. ...
-->
1. Install GOG Galaxy. It's easier to use [Bottles](https://flathub.org/apps/com.usebottles.bottles) for this step. There's a step-by-step guide on #3005 if needed.
2. Start the app and log in — A free [https://www.gog.com/](https://www.gog.com/) account is necessary.
3. Click on the gear icon on the top-left and open "Settings".
4. Click "Connect" on any account and on the new window click "Connect" again.
5. A Webview window with a login form should appear, but it's invisible.
### What happened
<!--
What did Mutter do that was unexpected?
-->
### What did you expect to happen
<!--
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/3038Gap between window decorations and body for applications and other glitches (...2024-02-18T21:06:09ZAdonnen DagnirGap between window decorations and body for applications and other glitches (Wayland, Fractional Scaling)<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
Fedora Linux 38 (Workstation Edition) 64-bit, GNOME 44.5, Kern...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
Fedora Linux 38 (Workstation Edition) 64-bit, GNOME 44.5, Kernel 6.4.15-200.fc38.x86_64
Mutter 44.5
<!--
Provide at least the following information:
* Your OS and version
* Affected Mutter version
* Does this issue appear in XOrg and/or Wayland
-->
### Bug summary
Some applications have a gap between their window decorations and the window itself. This includes FirefoxPWA windows (running with native title bar) and chromium and some electron apps forced to run under wayland (ozone platform flags) including Signal, VSCode, and Bitwarden.
### Steps to reproduce
1. Open one of the affected apps.
### What happened
Sometimes, there is a transparent gap between the window body and decorations. There might also be a slight misalignment. This seems pretty random, but with the electron apps, it typically occurs when windowed, whereas with FirefoxPWAs, it only occurs when maximized. It is accompanied by other graphical glitches. There can be a slight horizontal misalignment, the window can appear slightly blurrier (but less blurry than xwayland), and tiling is inconsistent. Using keyboard shortcuts or drag-to-snap, windows sometimes split properly and have square corners (like in maximize), but other times, they keep their rounded corners and the graphical glitches or fail to cover the proper area.
### What did you expect to happen
I expected the windows to display properly.
What did you expect Mutter to do?
--> I expected mutter to display the windows properly.
### Relevant logs, screenshots, screencasts etc.
![Screenshot_from_2023-09-21_12-16-24](/uploads/275c954cd1d30332668b0d6dcadcb030/Screenshot_from_2023-09-21_12-16-24.png)
![Screenshot_from_2023-09-21_12-16-57](/uploads/d86b0b5fc0893b6c102886c56a8609f9/Screenshot_from_2023-09-21_12-16-57.png)
![Screenshot_from_2023-09-21_12-17-37](/uploads/3d660a433658771c4e224df049b6311a/Screenshot_from_2023-09-21_12-17-37.png)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3003Non-square icon displays garbled image2023-09-28T15:45:49ZMaartenNon-square icon displays garbled image
### Affected version
Provide at least the following information:
* Your OS and version: Fedora Linux 38
* Affected GNOME Shell version: 44.4
* Does this issue appear in XOrg and/or Wayland: XOrg only (you can't change an icon with Wayl...
### Affected version
Provide at least the following information:
* Your OS and version: Fedora Linux 38
* Affected GNOME Shell version: 44.4
* Does this issue appear in XOrg and/or Wayland: XOrg only (you can't change an icon with Wayland)
* Does this issue happen without extensions: yes
### Bug summary
When setting a non-square icon, garbled data is shown.
![image](/uploads/4cfc17c502bb091e1ce42ed329eed85e/image.png)
### Steps to reproduce
1. Save the python script below as e.g. `/tmp/non-square-icon.py`, and run it as `python /tmp/non-square-icon.py`.
2. Look at the icon in the task bar
```python
#!/usr/bin/env python
from tkinter import *
from tkinter.ttk import *
import tkinter as tk
# magick -size 64x40 canvas:khaki out.png
PNG_DATA = b'\x89PNG\r\n\x1a\n\x00\x00\x00\rIHDR\x00\x00\x00@\x00\x00\x00(\x01\x03\x00\x00\x00t\x00n\xaa\x00\x00\x00 cHRM\x00\x00z&\x00\x00\x80\x84\x00\x00\xfa\x00\x00\x00\x80\xe8\x00\x00u0\x00\x00\xea`\x00\x00:\x98\x00\x00\x17p\x9c\xbaQ<\x00\x00\x00\x06PLTE\xf0\xe6\x8c\xff\xff\xff\xb0P\xbd8\x00\x00\x00\x01bKGD\x01\xff\x02-\xde\x00\x00\x00\x07tIME\x07\xe7\t\x01\x0b\x18$\xc0t\x17\xe7\x00\x00\x00\rIDAT\x18\xd3c`\x18\x05\xf4\x00\x00\x01h\x00\x01\xd9\xb6\x15\xb4\x00\x00\x00%tEXtdate:create\x002023-09-01T11:24:36+00:00\xb9\x8e\xd4o\x00\x00\x00%tEXtdate:modify\x002023-09-01T11:24:36+00:00\xc8\xd3l\xd3\x00\x00\x00(tEXtdate:timestamp\x002023-09-01T11:24:36+00:00\x9f\xc6M\x0c\x00\x00\x00\x00IEND\xaeB`\x82'
with open("/tmp/a.png", "wb") as f:
f.write(PNG_DATA)
program = Tk()
p1 = PhotoImage(file="/tmp/a.png")
program.iconphoto(False, p1)
b = Button(program, text='Press Me!')
b.pack(side=TOP)
program.title('iconphoto() method')
mainloop()
```
### What happened
The icon shows up garbled, containing what appears to be binary data.
### What did you expect to happen
The icon, without garbled data.
### Relevant logs, screenshots, screencasts etc.
This "effect" reproduces with python tk, [SDL](https://github.com/libsdl-org/SDL/issues/8171) and glfw3.
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/2963Resuming after plugging in external monitor during suspend windows are incorrect2023-10-11T01:25:49ZPaul MenzelResuming after plugging in external monitor during suspend windows are incorrectOn the Intel Broadwell laptop Dell Latitude E7250 (i7-5600U, Intel Corporation HD Graphics 5500 [8086:1616] (rev 09)) with Debian sid/unstable with *linux-image-6.4.0-1-amd64* 6.4.4-2, *mutter* 43.6-1 and *gnome-shell* 43.7-1, GNOME is c...On the Intel Broadwell laptop Dell Latitude E7250 (i7-5600U, Intel Corporation HD Graphics 5500 [8086:1616] (rev 09)) with Debian sid/unstable with *linux-image-6.4.0-1-amd64* 6.4.4-2, *mutter* 43.6-1 and *gnome-shell* 43.7-1, GNOME is configured to use an external HiDPI Dell monitor as the only display. Now suspend the laptop, with no external monitors connected, so the the panel 1366x768 panel is used. When it is suspended, attached the 4K external monitor and resume the laptop.
Quite often, the Firefox/Nightly (formerly maximized) windows are not correctly sized for the screen but bigger. Even the title bar of the window is not shown. In this case it looks like it’s double the screen width.
![gnome-shell-and-firefox](/uploads/5f5a8ead5ee91f9590da1a4105aedb0e/gnome-shell-and-firefox.png)
Resizing the window, with for example Meta key + right arrow, and then Meta key + up arrow, the window size is correct.https://gitlab.gnome.org/GNOME/mutter/-/issues/2952Crash in get_input_event when recording with Sysprof2023-10-16T20:29:18ZIvan Molodetskikhyalterz@gmail.comCrash in get_input_event when recording with Sysprof<!--
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 38 Silverblue, Wayland, mutter-44.3-1.fc38.x86_64, gnome-shell-44.3-1.fc38.x86_64
### Bug summary
<!--
Provide a short summary of the bug you encountered.
-->
Recording with Sysprof with "Compositor Timings" enabled crashes the session after a bit.
### Steps to reproduce
1. Start a Sysprof recording with compositor timings.
2. Wait a bit.
### What happened
<!--
What did Mutter do that was unexpected?
-->
```
Stack trace of thread 26494:
#0 0x00007fa20a907bc6 get_input_event (libmutter-12.so.0 + 0x107bc6)
#1 0x00007fa20a9101ae xevent_func.lto_priv.0 (libmutter-12.so.0 + 0x1101ae)
#2 0x00007fa20a9138b5 meta_x11_event_source_dispatch (libmutter-12.so.0 + 0x1138b5)
#3 0x00007fa20af4148c g_main_context_dispatch (libglib-2.0.so.0 + 0x5c48c)
#4 0x00007fa20af9f648 g_main_context_iterate.isra.0 (libglib-2.0.so.0 + 0xba648)
#5 0x00007fa20af40a8f g_main_loop_run (libglib-2.0.so.0 + 0x5ba8f)
#6 0x00007fa20a8d526a meta_context_run_main_loop (libmutter-12.so.0 + 0xd526a)
#7 0x000055ec986d7f87 main (gnome-shell + 0x3f87)
#8 0x00007fa20a649b4a __libc_start_call_main (libc.so.6 + 0x27b4a)
#9 0x00007fa20a649c0b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x27c0b)
#10 0x000055ec986d8265 _start (gnome-shell + 0x4265)
```
### Relevant logs, screenshots, screencasts etc.
```
(gdb) bt full
#0 get_input_event (event=<optimized out>, x11_display=<optimized out>) at ../src/x11/events.c:62
input_event = 0x0
#1 get_input_event (x11_display=x11_display@entry=0x55ec999a2440, event=event@entry=0x7ffdfe50a970) at ../src/x11/events.c:62
input_event = <optimized out>
#2 0x00007fa20a9101ae in get_event_name (event=0x7ffdfe50a970, x11_display=0x55ec999a2440) at ../src/x11/events.c:537
name = 0x0
input_event = <optimized out>
name = <optimized out>
input_event = <optimized out>
#3 meta_x11_display_handle_xevent (event=0x7ffdfe50a970, x11_display=<optimized out>) at ../src/x11/events.c:1999
backend = <optimized out>
CoglTraceMetaX11DisplayHandleXevent = {begin_time = 9782564453000, name = 0x7fa20a9c3f7b "X11Display (handle X11 event)", description = 0x0}
out = <optimized out>
display = <optimized out>
modified = <optimized out>
input_event = <optimized out>
cursor_tracker = <optimized out>
wayland_compositor = <optimized out>
context = <optimized out>
bypass_compositor = <optimized out>
display = <optimized out>
context = <optimized out>
backend = <optimized out>
modified = <optimized out>
bypass_compositor = <optimized out>
input_event = <optimized out>
cursor_tracker = <optimized out>
wayland_compositor = <optimized out>
CoglTraceMetaX11DisplayHandleXevent = <optimized out>
out = <optimized out>
_topic_message = <optimized out>
cursor_tracker_x11 = <optimized out>
compositor_x11 = <optimized out>
window = <optimized out>
#4 xevent_func (xevent=0x7ffdfe50a970, data=<optimized out>) at ../src/x11/events.c:2011
x11_display = <optimized out>
#5 0x00007fa20a9138b5 in meta_x11_event_source_dispatch (source=0x55ec9bb05450, callback=0x7fa20a910010 <xevent_func>, user_data=0x55ec999a2440) at ../src/x11/meta-x11-event-source.c:64
xevent = {type = 35, xany = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, window = 42949673091}, xkey = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, window = 42949673091, root = 0, subwindow = 0, time = 0, x = 485, y = 0, x_root = 1313162578, y_root = 0, state = 0, keycode = 0, same_screen = 0}, xbutton = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, window = 42949673091, root = 0, subwindow = 0, time = 0, x = 485, y = 0, x_root = 1313162578, y_root = 0, state = 0, button = 0, same_screen = 0}, xmotion = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, window = 42949673091, root = 0, subwindow = 0, time = 0, x = 485, y = 0, x_root = 1313162578, y_root = 0, state = 0, is_hint = 0 '\000', same_screen = 0}, xcrossing = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, window = 42949673091, root = 0, subwindow = 0, time = 0, x = 485, y = 0, x_root = 1313162578, y_root = 0, mode = 0, detail = 0, same_screen = 0, focus = 0, state = 0}, xfocus = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, window = 42949673091, mode = 0, detail = 0}, xexpose = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, window = 42949673091, x = 0, y = 0, width = 0, height = 0, count = 0}, xgraphicsexpose = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, drawable = 42949673091, x = 0, y = 0, width = 0, height = 0, count = 0, major_code = 0, minor_code = 485}, xnoexpose = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, drawable = 42949673091, major_code = 0, minor_code = 0}, xvisibility = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, window = 42949673091, state = 0}, xcreatewindow = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, parent = 42949673091, window = 0, x = 0, y = 0, width = 0, height = 0, border_width = 485, override_redirect = 0}, xdestroywindow = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, event = 42949673091, window = 0}, xunmap = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, event = 42949673091, window = 0, from_configure = 0}, xmap = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, event = 42949673091, window = 0, override_redirect = 0}, xmaprequest = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, parent = 42949673091, window = 0}, xreparent = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, event = 42949673091, window = 0, parent = 0, x = 0, y = 0, override_redirect = 485}, xconfigure = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, event = 42949673091, window = 0, x = 0, y = 0, width = 0, height = 0, border_width = 485, above = 1313162578, override_redirect = 0}, xgravity = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, event = 42949673091, window = 0, x = 0, y = 0}, xresizerequest = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, window = 42949673091, width = 0, height = 0}, xconfigurerequest = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, parent = 42949673091, window = 0, x = 0, y = 0, width = 0, height = 0, border_width = 485, above = 1313162578, detail = 0, value_mask = 0}, xcirculate = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, event = 42949673091, window = 0, place = 0}, xcirculaterequest = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, parent = 42949673091, window = 0, place = 0}, xproperty = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, window = 42949673091, atom = 0, time = 0, state = 0}, xselectionclear = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, window = 42949673091, selection = 0, time = 0}, xselectionrequest = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, owner = 42949673091, requestor = 0, selection = 0, target = 0, property = 485, time = 1313162578}, xselection = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, requestor = 42949673091, selection = 0, target = 0, property = 0, time = 485}, xcolormap = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, window = 42949673091, colormap = 0, new = 0, state = 0}, xclient = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, window = 42949673091, message_type = 0, format = 0, data = {b = "\000\000\000\000\000\000\000\000\345\001\000\000\000\000\000\000REEN", s = {0, 0, 0, 0, 485, 0, 0, 0, 17746, 20037}, l = {0, 485, 1313162578, 0, 0}}}, xmapping = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, window = 42949673091, request = 0, first_keycode = 0, count = 0}, xerror = {type = 35, display = 0x24e8, resourceid = 0, serial = 94474675242960, error_code = 131 '\203', request_code = 0 '\000', minor_code = 0 '\000'}, xkeymap = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, window = 42949673091, key_vector = '\000' <repeats 24 times>, "\345\001\000\000\000\000\000"}, xgeneric = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, extension = 131, evtype = 10}, xcookie = {type = 35, serial = 9448, send_event = 0, display = 0x55ec997547d0, extension = 131, evtype = 10, cookie = 0, data = 0x0}, pad = {35, 9448, 0, 94474675242960, 42949673091, 0, 0, 0, 485, 1313162578, 0, 0, 0, 140332822071228, 0, 0, 140332822071243, 0, 0, 140332822071274, 0, 0, 140332822071288, 0}}
event_source = 0x55ec9bb05450
event_func = 0x7fa20a910010 <xevent_func>
retval = 1
#6 0x00007fa20af4148c in g_main_dispatch (context=0x55ec9949c920) at ../glib/gmain.c:3460
dispatch = 0x7fa20a913860 <meta_x11_event_source_dispatch>
prev_source = 0x0
begin_time_nsec = 9782564444462
was_in_call = 0
user_data = 0x55ec999a2440
callback = 0x7fa20a910010 <xevent_func>
cb_funcs = 0x7fa20b02c380 <g_source_callback_funcs>
cb_data = 0x55ec999a2fb0
need_destroy = <optimized out>
source = 0x55ec9bb05450
current = 0x55ec994795d0
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>
#7 g_main_context_dispatch (context=0x55ec9949c920) at ../glib/gmain.c:4200
No locals.
#8 0x00007fa20af9f648 in g_main_context_iterate.isra.0 (context=0x55ec9949c920, block=1, dispatch=1, self=<optimized out>) at ../glib/gmain.c:4276
max_priority = 0
timeout = 0
some_ready = 1
nfds = 11
allocated_nfds = <optimized out>
fds = <optimized out>
begin_time_nsec = 9782564410278
#9 0x00007fa20af40a8f in g_main_loop_run (loop=0x55ec9b2d2c50) at ../glib/gmain.c:4479
self = <optimized out>
__func__ = "g_main_loop_run"
#10 0x00007fa20a8d526a in meta_context_run_main_loop (context=context@entry=0x55ec9949acf0, error=error@entry=0x7ffdfe50ac40) at ../src/core/meta-context.c:482
priv = 0x55ec9949ac70
__func__ = "meta_context_run_main_loop"
#11 0x000055ec986d7f87 in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.c:663
context = 0x55ec9949acf0
error = 0x0
ecode = 0
```
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/2932Mutter treats the dropdown menus as windows2023-10-20T04:01:22ZDemir DeğerliMutter treats the dropdown menus as windows<!--
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
-->
OS: Fedora Linux 38 (Workstation Edition)
Mutter version: Mutter 44.2
I couldn't open the screenshot tool in XOrg with an open dropdown menu.
### Bug summary
<!--
Provide a short summary of the bug you encountered.
-->
### Steps to reproduce
<!--
1. Step one
2. Step two
3. ...
-->
1. Open any GTK4 application such as GNOME Settings.
2. Find a dropdown menu (for example the sound output selection menu in sound tab)
3. Expand the dropdown menu and open the screenshot tool.
### What happened
<!--
What did Mutter do that was unexpected?
-->
The dropdown menu appears as a seperate window.
### What did you expect to happen
<!--
What did you expect Mutter to do?
-->
The dropdown menu shouldn't be seperated from it's window.
### Relevant logs, screenshots, screencasts etc.
![2023-07-30_14-59-02](/uploads/3771009bd681481de0e7961bf8af9ad2/2023-07-30_14-59-02.mp4)
<!--
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/2920Wayland + Gnome + Nvidia + Borderless = glitches2023-09-28T19:47:19ZlgdWayland + Gnome + Nvidia + Borderless = glitches### Affected version
Arch Linux x86_64 (6.4.4-arch1-1)
mutter 44.3
Wayland
Nvidia
### Bug summary
Native and proton games glitch when in borderless window mode.
### Steps to reproduce
Have any game window run in borderless mode (and...### Affected version
Arch Linux x86_64 (6.4.4-arch1-1)
mutter 44.3
Wayland
Nvidia
### Bug summary
Native and proton games glitch when in borderless window mode.
### Steps to reproduce
Have any game window run in borderless mode (and not window fullscreen mode).
### What happened
Window content glitches and it shouldn't.
### Relevant logs, screenshots, screencasts etc.
- Glitches appear only in borderless mode.
- Windowed or window fullscreen mode is unaffected.
- Glitches won't appear on screenshots.
This is photo of the glitch:
https://imgur.com/a/FkCsa5Y
I have observed same issue with Hidamari wallpapers. I'm not sure why,
but Hidamari switches to borderless-ish mode, making top bar not visible by default.
After that happens it glitches just like borderless windows I have mentioned above
(the glitch pattern is also the same).
Perhaps this may or may not hint at something.
Of course, I don't know if mutter is responsible directly (might be an Nvidia driver),
however since it happens only in specific window mode, I assume this might be
related to display server/compositor.https://gitlab.gnome.org/GNOME/mutter/-/issues/2898clutter: x/y-expand not propagated to parent when first inserted in actor tree2024-01-04T18:02:52ZZacharie DUBRULLEclutter: x/y-expand not propagated to parent when first inserted in actor tree### Affected version
Ubuntu 23.04
GNOME Shell 44.2
The issue appears on XOrg and, although I haven't tested it, it probably also appears on Wayland
### Bug summary
Given two actors `parent` and `child`, when `child` is first added t...### Affected version
Ubuntu 23.04
GNOME Shell 44.2
The issue appears on XOrg and, although I haven't tested it, it probably also appears on Wayland
### Bug summary
Given two actors `parent` and `child`, when `child` is first added to `parent`, its x/y-expand properties will not be propagated to `parent`, but will still be applied by `parent`'s layout manager.
### Steps to reproduce
You can find [here](https://github.com/Rayzeq/clutter-bug) a gnome shell extension that shows this issue.
### What happened
(read the extension code first)
`broken_container` filled `main_container` only after removing and re-adding `expandable_container`.
### What did you expect to happen
`broken_container` should have filled `main_container` from the start because the `y-expand` property of `expandable_container` should have propagated to it.
### Relevant logs, screenshots, screencasts etc.
You can find my technical analysis of the issue in the comments on the extension code.https://gitlab.gnome.org/GNOME/mutter/-/issues/3239Unable to bind tablet ring to mouse wheel.2024-01-12T05:23:37ZbartoszekUnable to bind tablet ring to mouse wheel.### Affected version
* OS:Arch
* Gnome-shell: 44.2
* Xorg: 1.21.1.8
* Vanilla DE, no extensions.
### Bug summary
Configuration dialog for tablet button mapping prevents from assigning mouse wheel to tablet ring action.
### Steps to r...### Affected version
* OS:Arch
* Gnome-shell: 44.2
* Xorg: 1.21.1.8
* Vanilla DE, no extensions.
### Bug summary
Configuration dialog for tablet button mapping prevents from assigning mouse wheel to tablet ring action.
### Steps to reproduce
1. Open the gnome settings dialog
2. Get to the "Wacom Tablet" section
3. Click on "Map Buttons"
4. Choice ring remapping
5. There's no option for mouse event to tablet button mapping.
### What happened
The mouse wheel isn't available for tablet ring mapping.
### What did you expect to happen
Ability to map mouse events to tablet buttons.
### Relevant logs, screenshots, screencasts, etc.
![Pasted_image](/uploads/56686e20391a8f4bf5efa18ceb287623/Pasted_image.png)
Tried manually editing the gnome config in `dconf-editor` but with no effect, perhaps "WheelUp/WheelDown" isn't the correct name for the event or they aren't implemented at all.
![image](/uploads/f59a2ccf329ca5055155075805e21089/image.png)
![image](/uploads/bb0a0581b3e6efb86c33892a723a48cd/image.png)https://gitlab.gnome.org/GNOME/mutter/-/issues/2870'<App> is ready' message appears for maximized apps when center-new-windows i...2023-10-11T01:49:13Zdarkblaze69'<App> is ready' message appears for maximized apps when center-new-windows is active### Affected version
Provide at least the following information:
* Arch / GNOME 44
* Affected Mutter version: 44
* Wayland only
### Bug summary
- Option 'center-new-windows' is active.
- Any app in foreground.
- When opening maximized a...### Affected version
Provide at least the following information:
* Arch / GNOME 44
* Affected Mutter version: 44
* Wayland only
### Bug summary
- Option 'center-new-windows' is active.
- Any app in foreground.
- When opening maximized apps (Chromium in Wayland mode), the 'App is ready' message appears.
### Steps to reproduce
Good behavior:
1. Set option 'center-new-windows' to false.
2. Open any app in foreground.
3. Open Chromium in Wayland mode, maximized: `chromium --ozone-platform-hint=wayland`
4. No any 'App is ready' message appear.
Buggy behavior:
1. Set option 'center-new-windows' to true.
2. Open any app in foreground.
3. Open Chromium in Wayland mode, maximized: `chromium --ozone-platform-hint=wayland`
4. Observe 'App is ready' message appears.
'App is ready' message appeared in center-new-windows mode.
'App is ready' message should not appear.
Chromium in Xwayland mode doesn't reproduce the 'App is ready' behavior.
~~Haven't find apps other than Chromium yet, for which this is reproducible.~~
Also opening any sections in Settings from Overview are affected (3rd video)
Watch the video for illustration.
### Relevant logs, screenshots, screencasts etc.
1. Fast NVMe storage behavior (the message appears very fast and dissappears):
![Kooha-2023-06-17-11-57-41](/uploads/36b93f2804a7398c207375b0458e5dd7/Kooha-2023-06-17-11-57-41.mp4)
2. Slow USB storage behavior (seems like the message waits for chromium to load):
![Kooha-2023-06-17-13-36-57](/uploads/e4d6017655244d3ef6af4a462d789767/Kooha-2023-06-17-13-36-57.webm)
3. Opening a Settings section by search from Overview:
![Kooha-2023-06-17-15-40-09](/uploads/1fa26a1850f920f8972497ca59162a8c/Kooha-2023-06-17-15-40-09.mp4)
<!-- Do not remove the following line. -->