mutter issueshttps://gitlab.gnome.org/GNOME/mutter/-/issues2023-11-22T18:11:48Zhttps://gitlab.gnome.org/GNOME/mutter/-/issues/3162Flickering when creating 2 wl_buffer's for the same dmabuf2023-11-22T18:11:48ZBenjamin OtteFlickering when creating 2 wl_buffer's for the same dmabufWhen an application creates 2 wl_buffers for the same dmabuf fd via `zwp_linux_buffer_params_v1::create()` and attaches it to a subsurface, that subsurface starts flickering.
The flickering does not happen with (nested) Weston.
To rep...When an application creates 2 wl_buffers for the same dmabuf fd via `zwp_linux_buffer_params_v1::create()` and attaches it to a subsurface, that subsurface starts flickering.
The flickering does not happen with (nested) Weston.
To reproduce, you can get GTK main and revert https://gitlab.gnome.org/GNOME/gtk/-/commit/010ff81b2f3d8b52f7cb90835712b9a826b771e3 and then run `build/tests/testdmabuf XR24 ~/some-image.png` and interactive-resize the window.
(You want to either build with Vulkan or `sudo chmod 666 /dev/dma_heap/system` or that tool can't create dmabufs)
It will look something like this:
![Screencast_from_2023-11-17_01-38-42](/uploads/2176c67d867651b959eb9695404c0164/Screencast_from_2023-11-17_01-38-42.webm)https://gitlab.gnome.org/GNOME/mutter/-/issues/3157Support CRTCs with multiple encoders/connectors2023-11-13T16:07:42ZThomas ZimmermannSupport CRTCs with multiple encoders/connectors
### Affected version
Linux 6.6 with
Mutter 45
Both Xorg and Wayland are affected
### Bug summary
Aspeed graphics chips are mostly used in servers and some embedded systems. The chips are combined with a BMC that allows to watch the ...
### Affected version
Linux 6.6 with
Mutter 45
Both Xorg and Wayland are affected
### Bug summary
Aspeed graphics chips are mostly used in servers and some embedded systems. The chips are combined with a BMC that allows to watch the display's output remotely. In Linux 6.6, we've added a second encoder/connector for Aspeed hardware.
That newly added second output represents the BMC. It is always a mirror/clone of the first output.
Mutter does not work with the second output. It starts, but it is then impossible to change resolution on any of the outputs, or do anything at all in the Settings' display dialog.
### Steps to reproduce
<!--
1. Step one
2. Step two
3. ...
-->
1) Happens on Aspeed hardware.
2) You need Linux 6.6
3) In Gnome, go to Settings and try to configure the display.
### What happened
Mutter does allow to change the output's configuration. It permanently shows a warning that the configuration is incompatible.
### What did you expect to happen
I would expect to at least be able to configure the VGA/DP/DVI configuration as usual.
### Relevant logs, screenshots, screencasts etc.
The affected system is in drmdb at https://drmdb.emersion.fr/snapshots/4c406f948ee9
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3155mpv with dmabuf in mirror screen mode shows videos in green tint2023-12-15T14:55:52Zdarkblaze69mpv with dmabuf in mirror screen mode shows videos in green tint* OS: Arch Linux
* GNOME 45.1, `main`, with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177 patches
* iGPU Intel Tigerlake (Gen12)
Though it's great to watch in mpv dmabuf especially with 3177 patch even in multimon join mod...* OS: Arch Linux
* GNOME 45.1, `main`, with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177 patches
* iGPU Intel Tigerlake (Gen12)
Though it's great to watch in mpv dmabuf especially with 3177 patch even in multimon join mode, it fails in mirror screen mode and shows videos in green tint. Not sure maybe it's mpv's fault.
<details><summary>Click to expand</summary>
```
mpv --hwdec=vaapi --vo=dmabuf-wayland --fs --sid=0 ~/Videos/BigBuckBunnyFULLHD60FPS/Big\ Buck\ Bunny\ -\ FULL\ HD\ 60FPS.mp4
(+) Video --vid=1 (*) (h264 1920x1080 60.000fps)
(+) Audio --aid=1 (*) (aac 2ch 44100Hz)
Cannot load libcuda.so.1
Using hardware decoding (vaapi).
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [dmabuf-wayland] 1920x1080 vaapi[nv12]
[ffmpeg/video] h264: get_buffer() failed
[ffmpeg/video] h264: decode_slice_header error
[ffmpeg/video] h264: no frame!
Error while decoding frame (hardware decoding)!
[ffmpeg/video] h264: get_buffer() failed
[ffmpeg/video] h264: decode_slice_header error
[ffmpeg/video] h264: no frame!
Error while decoding frame (hardware decoding)!
[ffmpeg/video] h264: get_buffer() failed
[ffmpeg/video] h264: decode_slice_header error
[ffmpeg/video] h264: no frame!
Error while decoding frame (hardware decoding)!
Attempting next decoding method after failure of h264-vaapi.
[ffmpeg/video] h264: co located POCs unavailable
[ffmpeg/video] h264: co located POCs unavailable
[autoconvert] HW-uploading to vaapi
[hwupload] upload yuv420p -> vaapi[yuv420p]
VO: [dmabuf-wayland] 1920x1080 vaapi[yuv420p]
Exiting... (Quit)
```
</details>
![PXL_20231112_180522481.TS-small](/uploads/820120fd97579d88a32200ec14c58441/PXL_20231112_180522481.TS-small.mp4)https://gitlab.gnome.org/GNOME/mutter/-/issues/3154Manually moving a window in a multi-monitor setup does not stick to some scre...2023-11-11T09:53:30ZAdoa CoturnixManually moving a window in a multi-monitor setup does not stick to some screen edges### Affected version
* Arch Linux
* gnome-shell version 1:45.1-1 as packaged by archlinux
* only tested on wayland
* I do not use gnome extensions
### Bug summary
I love the feature that when you move windows manually via Super + drag...### Affected version
* Arch Linux
* gnome-shell version 1:45.1-1 as packaged by archlinux
* only tested on wayland
* I do not use gnome extensions
### Bug summary
I love the feature that when you move windows manually via Super + drag left mouse button, they stick to the screen edges. However, this sticking is inconsistent in a multi-monitor setup. Some screen edges are not sticky – without obvious reason.
### Steps to reproduce
I can reproduce it in at least two variants:
Two monitor setup A: moving a window across the *lower* edge of the smaller screen on the right-hand side does not stick.
```
+–––––––––––––––––––+––––––––––––+
| | |
| | |
| | |
| |––––––––––––+
| |
| |
+–––––––––––––––––––+
```
Two monitor setup B: moving a window across the *upper* edge of the smaller screen on the right-hand side does not stick.
```
+–––––––––––––––––––+
| |
| |
| |––––––––––––+
| | |
| | |
| | |
+–––––––––––––––––––+––––––––––––+
```
In both cases, when trying to move a window between the monitors, the sticking is as expected.
However, when trying to move a *small* window from the big screen into the space *below* the secondary screen in setup A or *above* the secondary screen in setup B does not stick either. The latter effect is only reproducible if the window you try to move does not "hit" the secondary screen while moving.
### What happened
Manually moving a window sticks to some screen edges, yet not to others.
### What did you expect to happen
Manually moving a window should stick to all screen edges, irrespective of virtual screen arrangement.https://gitlab.gnome.org/GNOME/mutter/-/issues/3153Switching windows of an application (partly) doesn't work anymore2024-01-31T09:40:26ZBaby GnuSwitching windows of an application (partly) doesn't work anymoreHi :) Since GNOME 45 (Fedora), I cannot always (see below) switch between windows of the same application using Super+^ ("dead circumflex" / "Above_Tab"). In the settings / dconf-editor, I see it correctly configured, the default in dcon...Hi :) Since GNOME 45 (Fedora), I cannot always (see below) switch between windows of the same application using Super+^ ("dead circumflex" / "Above_Tab"). In the settings / dconf-editor, I see it correctly configured, the default in dconf-editor is `['<Super>Above_Tab', '<Alt>Above_Tab']` and that is activated. Switching with Alt+^ works reliably. Switching with Super+^ only works if there is no active input in the current window. So when I have two windows of the Files app, for example, it works. But when I'm typing something in gnome-terminal and then want to switch to another gnome-terminal window, it doesn't work. Instead, I just type the character ^ in my current command line / open editor / whatever I have in the terminal.https://gitlab.gnome.org/GNOME/mutter/-/issues/3151crash/freeze on GPUs related to preempt in KMS GPU driver/module2024-01-19T11:10:54ZEwout van Mansomcrash/freeze on GPUs related to preempt in KMS GPU driver/moduleCurrently, the released GNOME 45.1 as shipped in Ubuntu 23.10, Fedora 39 and other distros has broken out-of-the-box behavior for certain GPUs. **This leads to a bad user experience where the shell fully freezes and crashes.** Resulting ...Currently, the released GNOME 45.1 as shipped in Ubuntu 23.10, Fedora 39 and other distros has broken out-of-the-box behavior for certain GPUs. **This leads to a bad user experience where the shell fully freezes and crashes.** Resulting in loss of work, frustration and avoidance of GNOME itself.
Not sure if this affects only AMD GPUs or only a certain set of AMD GPUs or Intel+AMD or all GPUs, **but at least for some AMD and some Intel multiple people are reporting to experience sudden crashes during some certain kinds of interactions** in the Shell.
Also, unsure if it is related to the experimental RT scheduler in Mutter or not. As I had it enabled when the crashes/freezes happened frequently, I now run it with it disabled just to be sure.
Creating this issue as a collection of other issues to coordinate and track the **user facing issue: GNOME 45.1 crashing, disrupting work**. Please let me know if this should be somewhere else or if there is already an issue somewhere to track this.
I can get the Shell on my AMD Polaris RX 550 to crash reliably with experimental RT scheduler enabled, running on kernel 6.6-rc7. The way I can trigger this in a few seconds is with an N-key rollover keyboard smash spamming the switch workspace shortcut back and forth (**Ctrl** + **Alt** + **<** or **>**), then opening the overview while an overview transition animation is still going. It also sometimes happened while Alt-Tabbing or switching overviews, and while switching to full-screen on a video/image in either Telegram or Firefox.
**Temporary workaround for AMD GPUs that seems to work for my AMD Polaris RX 550 card**:
Thanks to the comment to disable AMDGPU kernel module's Mid-command buffer preemption (MCBP) feature from @daenzer in !3037 I now have a stable GNOME experience once again, haven't experienced any crashes thus far since disabling MCBP yesterday (2023-11-09).
To configure this workaround @daenzer recommended to pass `amdgpu.mcbp=0` as a command line argument to the kernel via the bootloader.
![Schermafdruk_van_2023-11-10_08-13-29](/uploads/4029d5dcc3c3db035d5eed71125514fe/Schermafdruk_van_2023-11-10_08-13-29.png)
To be completely sure I also configured a drop-in modprobe config on the filesystem:
`/etc/modprobe.d/amdgpu-no-mcbp.conf`
```
options amdgpu mcbp=0
```
Possibly related to:
#3037
#3054
#3065
#3150
gnome-shell#7177
gnome-shell#7158
https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2034619
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2039045
!3308
!3291
!3324
!3293https://gitlab.gnome.org/GNOME/mutter/-/issues/3149Regression: The Talos Principle can not go back to fullscreen mode after swit...2023-11-09T23:30:48ZWill Campbellwcampbell@nvidia.comRegression: The Talos Principle can not go back to fullscreen mode after switching to windowed mode<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
Ubuntu 23.04 or newer, on X.
Issue appeared when mutter swit...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
Ubuntu 23.04 or newer, on X.
Issue appeared when mutter switched to the frames client: https://gitlab.gnome.org/GNOME/mutter/-/commit/39942974.
<!--
Provide at least the following information:
* Your OS and version
* Affected Mutter version
* Does this issue appear in XOrg and/or Wayland
-->
### Bug summary
<!--
Provide a short summary of the bug you encountered.
-->
The game launches in fullscreen mode. It lets me switch to windowed mode, but cannot return to fullscreen.
This is with an Nvidia system and drivers. I've heard that the game crashes when first switched to windowed mode on AMD, not sure if that's related.
### Steps to reproduce
<!--
1. Step one
2. Step two
3. ...
-->
1. Run GNOME/mutter standalone
2. Download and launch The Talos Principle via Steam
3. Once in-game, switch from fullscreen to windowed mode
4. Now attempt to switch back to fullscreen mode
5. Observe game is stuck in windowed mode
I've reprod in mutter standalone. The issue appeared in 39942974, this functionality worked fine before then.https://gitlab.gnome.org/GNOME/mutter/-/issues/3147invisible pen tablet cursor while moving mouse in GNOME452024-01-12T08:32:31ZRocketRideinvisible pen tablet cursor while moving mouse in GNOME45### Affected version
Provide at least the following information:
* Your OS and version: F39
* Affected Mutter version: mutter 45.1
* gnome wayland session
### Bug summary
pen tablet cursor is invisible while mouse is moving. i didn't...### Affected version
Provide at least the following information:
* Your OS and version: F39
* Affected Mutter version: mutter 45.1
* gnome wayland session
### Bug summary
pen tablet cursor is invisible while mouse is moving. i didn't encounter this bug in f38
### Steps to reproduce
1. Plug in your pen tablet
2. Move stylus near the tablet while also moving your mouse or using touchpad
### What happened
pen tablet cursor is invisible
### What did you expect to happen
both mouse cursor and pen tablet cursor are visible like in f38
### Relevant logs, screenshots, screencasts etc.
I tried to capture this bug on screencast but both cursors are visible there
![Kooha-2023-11-09-12-55-08](/uploads/bfd306303f05aafac0c0df4492ad7c3b/Kooha-2023-11-09-12-55-08.mp4)
Video taken by my phone
![IMG_E3116](/uploads/5fa54e5c48e57824197c2e5ba8f725c1/IMG_E3116.MOV)https://gitlab.gnome.org/GNOME/mutter/-/issues/3146Cursor stutters if nothing else is animating (since Mutter 45)2024-03-04T11:55:19ZDaniel van Vugtdaniel.van.vugt@canonical.comCursor stutters if nothing else is animating (since Mutter 45)Using both GNOME 45 and building from main, my hardware cursor stutters if I use the touchpad. The stuttering stops if something else is animating on screen.
It's an unusual combination:
Display: **90Hz** (OLED)
Touchpad: **145Hz** ...Using both GNOME 45 and building from main, my hardware cursor stutters if I use the touchpad. The stuttering stops if something else is animating on screen.
It's an unusual combination:
Display: **90Hz** (OLED)
Touchpad: **145Hz**
If I switch to a 1000Hz mouse then it doesn't stutter.
Workaround: `MUTTER_DEBUG_FORCE_KMS_MODE=simple`
https://launchpad.net/bugs/2040977https://gitlab.gnome.org/GNOME/mutter/-/issues/3139Telegram image/media viewer is behind Telegram's window in Wayland when anoth...2023-11-05T22:20:45Zdarkblaze69Telegram image/media viewer is behind Telegram's window in Wayland when another app is 'always on top'* Arch, Fedora
* GNOME 44/45
* Only in Wayland session (not reproduced in x11)
Telegram image/media viewer is behind it's main window in Wayland when another app is 'always on top'.
**Steps to reproduce:**
* Open an app (Files, gedit e...* Arch, Fedora
* GNOME 44/45
* Only in Wayland session (not reproduced in x11)
Telegram image/media viewer is behind it's main window in Wayland when another app is 'always on top'.
**Steps to reproduce:**
* Open an app (Files, gedit etc.), make it's window 'Always on top'.
* Open Telegram
* Open an image in Telegram so it should be opened full screen.
The image appears behind the main Telegram window, but it should cover the main Telegram window and be behind the 'Always on top' window.https://gitlab.gnome.org/GNOME/mutter/-/issues/3138Mouse cursor stutter when video is playing in browser on Wayland2024-02-21T10:24:03ZRocco CicconeMouse cursor stutter when video is playing in browser on Wayland<!--
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
-->
# System Details Report
---
## Report details
- **Date generated:** 2023-11-05 17:40:42
## Hardware Information:
- **Hardware Model:** Micro-Star International Co., Ltd. MS-7D70
- **Memory:** 64.0 GiB
- **Processor:** AMD Ryzen™ 9 7950X × 32
- **Graphics:** AMD Radeon™ RX 6900 XT
- **Disk Capacity:** 1.0 TB
## Software Information:
- **Firmware Version:** 1.80
- **OS Name:** EndeavourOS
- **OS Build:** rolling
- **OS Type:** 64-bit
- **GNOME Version:** 45.1
- **Windowing System:** Wayland
- **Kernel Version:** Linux 6.5.9-arch2-1
### Bug summary
I have noticed that when playing a video in any browser in a Wayland session causes the cursor to stutter. Oddly enough this can be fixed temporarily by unplugging and re-plugging the monitor. This fixes until the next reboot.
<!--
Provide a short summary of the bug you encountered.
-->
### Steps to reproduce
1. Launch a Gnome Wayland session
2. Start a browser
3. Play a YouTube video
4. Move mouse cursor, it should exhibit some stuttering.
<!--
1. Step one
2. Step two
3. ...
-->
### What happened
Considering mutter handles the cursor and when it is rendered, it seems like it misses some kind of deadline leading to some frame pacing issues related to the cursor.
<!--
What did Mutter do that was unexpected?
-->
### What did you expect to happen
I expect the cursor to not stutter when playing a video. On Xorg this does not happen so I expect this behaviour on Wayland.
<!--
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/3137Incorrect desktop panning since fractional scaling was implemented for x11. (...2023-11-08T22:55:29ZYo Soy FreemanIncorrect desktop panning since fractional scaling was implemented for x11. (All distros)<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
Seems to happen on all Distros using gnome on x11. Tested in: ...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
Seems to happen on all Distros using gnome on x11. Tested in: Fedora 39, Ubuntu 23.10, Vanilla OS 22.10 Kinetic.
All of the versions affected by this problem include "Fractional scaling" as a new option in the displays app.
### Bug summary
The new method of fractional scaling will scale the smaller monitor to be equal to the bigger one, causing problems with application scaling. Instead of this, I always set my 4k monitor to work as a 1080p monitor in this way:
![image](/uploads/1ef6e43a0c45524ee64349b0b8f62a10/image.png)
This always worked perfectly, but now, even with fractional scaling disabled, the resulting screen is not 3840x1080 as it should, but 5760 x 2160 as shown by xrandr. This causes you to pan the view out of the 1080p desktop, going out of bounds (It can be seen better opening the image in another tab, as the part out of the desktop is shown as white/transparent on the screenshot):
![image](/uploads/4d90c777a8ee8511c158b1f96e8a979f/image.png)
Note that this only happens if scale the 4k monitor to be of a smaller resolution and use viewportout to be 3840x216, making them align.
### Steps to reproduce
- Open displays.
- Disable fractional scaling.
- Open nvidia settings and scale the 4k monitor to be 1080 but out to 4k to fill the monitor.
- You can now pan outside the desktop. and the xscreen size is wrong.
### What happened
Mutter ignores the correct setup, the xcreen size do not match, and i can pan outside the desktop.
### What did you expect to happen
As always, I expected to have a simple 1080 dual setup, without panning outside the desktop.
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3134Fullscreen unredirection broken since introduction of the mutter frames client2024-03-02T17:49:13ZWill Campbellwcampbell@nvidia.comFullscreen unredirection broken since introduction of the mutter frames client<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce t...<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce the
bug
-->
This issue appears on a standard Ubuntu 23.04 install, running GNOME with X. It is a regression introduced by commit 39942974.
You can reproduce this easily with `glmark2 --fullscreen`. On my system the FPS is roughly halved by this issue. To confirm the behavior on an nvidia system you can first run `nvidia-settings` and enable the graphics visual indicator. In the top left of your window it will display 'BLIT' when it is being redirected and 'FLIP' when properly unredirected.
Many other fullscreen apps/games hit this too.
<!--
You should try and reproduce with the demos applications available
under the `demos` directory, or the test programs in the `tests` directory.
Alternatively, please attach a *small and self-contained* example
*written in C* that exhibits the issue.
-->
## Current behavior
<!--
Please describe the current behaviour
-->
Fullscreen games/apps are being redirected. In other words they aren't being scanned out directly. This significantly reduces performance and breaks features such as VRR and G-Sync. It's a fundamental driver agnostic issue, though the exact effects may be different depending on your platform.
Mutter's frame client adds decoration windows to applications, even fullscreen ones. The decoration window uses a visual with transparency for features like drop shadows, but this breaks unredirection since the root and application windows use a different visual without transparency. Since the visuals don't match we can't scanout directly.
Note that not all applications end up with a decoration window created by mutter. Some of these applications can still unredirect.
There are other issues filed for this: #2794, #2915.
## Expected outcome
<!--
Please describe the expected outcome
-->
Fullscreen apps should unredirect. FLIP will be displayed if you enable the `nvidia-settings` graphics visual indicator.
## Version information
<!--
- Which version of GTK you are using
- What operating system and version
- For Linux, which distribution
- If you built GTK yourself, the list of options used to configure the build
-->
I've seen this on Ubuntu 23.04 and newer, running GNOME+X. You don't need to run all of GNOME, you can repro running mutter standalone. You'll need a mutter version including https://gitlab.gnome.org/carlosg/mutter/-/commit/2a600ac9.https://gitlab.gnome.org/GNOME/mutter/-/issues/3133Windows without explicit minimum size can get pushed out of the screen when u...2023-11-12T13:26:57ZLarina LoriaselWindows without explicit minimum size can get pushed out of the screen when using tiled resizing<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
#### Software Information:
- **Firmware Version:** ...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
#### Software Information:
- **Firmware Version:** 68IRR Ver. F.68
- **OS Name:** Fedora Linux 39.20231102.n.0 (Silverblue)
- **OS Build:** (null)
- **OS Type:** 64-bit
- **GNOME Version:** 45.0
- **Windowing System:** Wayland
- **Kernel Version:** Linux 6.5.6-300.fc39.x86_64
- This is on a 1366x768 display.
- All extensions are disabled.
<!--
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.
-->
### Bug summary
You can push a window out of view when resizing.
<!--
Provide a short summary of the bug you encountered.
-->
### Steps to reproduce
1. Download Firefox and Telegram Desktop from Flathub
2. Open them, tile them side-by-side so Firefox is in the left and Telegram is on the Right. (Using the window snapping/tiling function of GNOME)
3. Grab the tiling adjustment/resizing line between them and keep tiling to the right until neither firefox nor telegram window move anymore.
4. You will see that firefox and telegram window overlap with eachother a little, focus firefox window and resize the window to the right again, this time telegram window will move out of view.
<!--
1. Step one
2. Step two
3. ...
-->
### What happened
1. Windows overlapped when tiling/resizing, they shouldn't have.
2. Telegram window moves out of view.
<!--
What did GNOME Shell do that was unexpected?
-->
### What did you expect to happen
1. The resizing/tiling stopping when Telegram window was at it's minimum width
2. telegram window to NOT move out of view.
<!--
What did you expect GNOME Shell to do?
-->
### Relevant logs, screenshots, screencasts etc.
![Screencast_from_2023-11-03_18-38-45](/uploads/994acf1b4ed18940a98d2ba167d1b5ee/Screencast_from_2023-11-03_18-38-45.webm)
I did the test again but this time with GNOME Calculator, as you can see this issue does not happen with GNOME calculator and Firefox.
![Screencast_from_2023-11-03_18-41-11](/uploads/5d0e003b36ccf6b6c8cf02258c50eefe/Screencast_from_2023-11-03_18-41-11.webm)
<!--
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/3129Tag pipelines build the wrong code2023-11-01T00:05:24ZFlorian Müllnerfmuellner@gnome.orgTag pipelines build the wrong codeWe started to handle the git checkout ourselves, but fail to handle tags correctly. As a result, the pipeline ends up checking out the main branch as a fallback, see for example https://gitlab.gnome.org/GNOME/mutter/-/jobs/3263857 for th...We started to handle the git checkout ourselves, but fail to handle tags correctly. As a result, the pipeline ends up checking out the main branch as a fallback, see for example https://gitlab.gnome.org/GNOME/mutter/-/jobs/3263857 for the 45.1 tag.https://gitlab.gnome.org/GNOME/mutter/-/issues/3128[regression 45?] '<Super>eacute' keybinding is sometimes sent to windows inst...2024-03-28T13:09:31ZRémi Cardona[regression 45?] '<Super>eacute' keybinding is sometimes sent to windows instead of triggering shortcut actionI have the following keybindings set up through the settings panel and they have been working just fine for close to a decade:
```
$ dconf read /org/gnome/desktop/wm/keybindings/switch-to-workspace-1
['<Super>ampersand']
$ dconf read /or...I have the following keybindings set up through the settings panel and they have been working just fine for close to a decade:
```
$ dconf read /org/gnome/desktop/wm/keybindings/switch-to-workspace-1
['<Super>ampersand']
$ dconf read /org/gnome/desktop/wm/keybindings/switch-to-workspace-2
['<Super>eacute']
$ dconf read /org/gnome/desktop/wm/keybindings/switch-to-workspace-3
['<Super>quotedbl']
$ dconf read /org/gnome/desktop/wm/keybindings/switch-to-workspace-4
['<Super>apostrophe']
$ dconf read /org/gnome/desktop/wm/keybindings/switch-to-workspace-5
['<Super>parenleft']
$ dconf read /org/gnome/desktop/wm/keybindings/switch-to-workspace-6
['<Super>minus']
```
(FTR these symbols are the first row of keys above the letters on a standard France/French AZERTY PC keyboard; numbers 1-6 need the shift key)
The issue I have is that `<Super>eacute` no longer works all the time. If the mouse focus is in a gtk3 or 4 app (gedit, gnome-terminal), they capture the `é` and print it out. No such issue in a Qt (vlc), electron (discord) or gtk2 (verbiste) programs.
Also, when in gnome-control-center's "keyboard shortcuts" modal window:
- the keybinding shows as "Super+É" (capital e acute), not sure if "Super+é" should be shown instead
- if I try to re-enter the keybinding, it then shows up as "Super+2" (which would make sense on a US QWERTY keyboard but not on a French AZERTY keyboard)
Since not all programs/libraries are impacted, I originally thought this bug to be linked to https://gitlab.gnome.org/GNOME/mutter/-/issues/3058, hence my comment over there, but reverting the patch does nothing to fix this current issue.
It seems to me that gnome-shell 45 is the culprit, whereas 44.4 was ok.https://gitlab.gnome.org/GNOME/mutter/-/issues/3127libinput's open_restricted should return a negative errno2024-01-04T08:47:29ZPeter Huttererlibinput's open_restricted should return a negative errno### Affected version
mutter-45.0-9.fc39.x86_64 and git as of (45.0-127-g2c4968fb4)
### Bug summary
The `open_restricted()` that libinput uses to open device files should return the fd or *a negative errno* on failure (see [the documen...### Affected version
mutter-45.0-9.fc39.x86_64 and git as of (45.0-127-g2c4968fb4)
### Bug summary
The `open_restricted()` that libinput uses to open device files should return the fd or *a negative errno* on failure (see [the documentation](https://wayland.freedesktop.org/libinput/doc/latest/api/structlibinput__interface.html#ae445aaa330e4eb7df6650fbc6428022a)). Currently it always returns -1 (Operation not permitted).
This is a cosmetic issue only, the only use of this return value is for a log message in libinput.
See [`src/backends/native/meta-seat-impl.c#2689`](https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/backends/native/meta-seat-impl.c#L2689)https://gitlab.gnome.org/GNOME/mutter/-/issues/3126steam client glitches exiting big picture mode2024-01-30T18:06:16ZTed Changsteam client glitches exiting big picture mode<!--
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
-->
Gnome Shell Wayland: 45.0
Steam Version: 1698260427
Steam Client Build Date: Wed, Oct 25 11:40 AM UTC -08:00
Steam Web Build Date: Wed, Oct 25 11:37 AM UTC -08:00
Steam API Version: SteamClient020
lsb_release -a
LSB Version: n/a
Distributor ID: openSUSE
Description: openSUSE Tumbleweed
Release: 20231028
Codename: n/a
Linux steamdeck.lan 6.5.9-1-default #1 SMP PREEMPT_DYNAMIC Wed Oct 25 10:31:37 UTC 2023 (29edc7c) x86_64 x86_64 x86_64 GNU/Linux
zypper info steam
Loading repository data...
Reading installed packages...
Information for package steam:
------------------------------
Repository : openSUSE-Tumbleweed-Non-Oss
Name : steam
Version : 1.0.0.78-2.2
Arch : x86_64
Vendor : openSUSE
Installed Size : 3.7 MiB
Installed : Yes (automatically)
Status : up-to-date
Source package : steam-1.0.0.78-2.2.src
Upstream URL : https://www.steampowered.com/
Summary : Installer for Valve's digital
Repository : openSUSE-Tumbleweed-Oss
Name : mutter
Version : 45.0+45-1.1
Arch : x86_64
Vendor : openSUSE
Installed Size : 4.7 MiB
Installed : Yes (automatically)
Status : up-to-date
Source package : mutter-45.0+45-1.1.src
Upstream URL : https://www.gnome.org
Summary : Window and compositing manager based on Clutter
Description :
Mutter is a window and compositing manager based on Clutter, forked
from Metacity.
------------------------------------
Repository : openSUSE-Tumbleweed-Oss
Name : gnome-shell
Version : 45.0-4.1
Arch : x86_64
Vendor : openSUSE
Installed Size : 8.4 MiB
Installed : Yes (automatically)
Status : up-to-date
Source package : gnome-shell-45.0-4.1.src
Upstream URL : https://wiki.gnome.org/Projects/GnomeShell
Summary : GNOME Shell
Description :
### Bug summary
<!--
Provide a short summary of the bug you encountered.
-->
Steam client glitches after exiting big picture mode. Ignore the obvious bug where the cursor is invisible in wayland where xtest emulation doesn't exist.
### Steps to reproduce
1. Open steam
2. View -> Big Picture Mode
3. Power -> Exit Big Picture mode
### What happened
The shell seems to be glitching
### What did you expect to happen
Exit without visual glitching
<!--
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.
-->
[2023-10-30_01-14-29.mkv](/uploads/aa71131e5f4ac80ad3271602e9d433fd/2023-10-30_01-14-29.mkv)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/3125Variable Refresh Rate - Roadmap2024-03-06T10:06:49ZGeorges Basile Stavracas NetoVariable Refresh Rate - RoadmapThis roadmap is an attempt to unblock the work done by @doraskayo, and to centralize and document the various conversations that have been happening around this subject.
As per Dor's assessment, there are problems with the VRR branch th...This roadmap is an attempt to unblock the work done by @doraskayo, and to centralize and document the various conversations that have been happening around this subject.
As per Dor's assessment, there are problems with the VRR branch that need to be fixed at some point. Of all these tasks, it was agreed that none should be blockers, as long as VRR is an off-by-default experimental feature.
Here's the current action plan:
### GNOME 46
* [x] The Merge Rush
* [x] Rebase https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154 (@doraskayo)
* [x] Adjust the patchset to enable VRR on monitors that support it, if the experimental flag is activated (@doraskayo)
* [x] Another code review pass (@jadahl?)
* [x] Merge it
* [x] New UI for GNOME Settings and approval from the Design team (@doraskayo)
* [x] Sane handling for "empty" frames (frames committed without a new buffer). Should help Firefox. (@doraskayo)
* [x] Integration with dynamic frame scheduling (@doraskayo)
* [x] Disabling cursor deadlines in the KMS thread when VRR is active. (or the ability to control the deadline)
### Future
* [ ] Attempt to use deadlines in the KMS thread for cursor updates between client frames. (@doraskayo)
* [ ] Experiment with frame clock changes and simplifications. (@doraskayo/@daenzer?)https://gitlab.gnome.org/GNOME/mutter/-/issues/3124CAPS LOCK input causes keyrepeat in ibus-pinyin, Reproducible in OSK and phys...2023-10-30T00:23:44ZTed ChangCAPS LOCK input causes keyrepeat in ibus-pinyin, Reproducible in OSK and physical keyboard.<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
I reproduce this behavior with on Trackpoint II with either b...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
I reproduce this behavior with on Trackpoint II with either bluetooth or usb dongle. The system is a steam deck.
zypper info gnome-shell
Loading repository data...
Reading installed packages...
Information for package gnome-shell:
------------------------------------
Repository : openSUSE-Tumbleweed-Oss
Name : gnome-shell
Version : 45.0-4.1
Arch : x86_64
Vendor : openSUSE
Installed Size : 8.4 MiB
Installed : Yes (automatically)
Status : up-to-date
Source package : gnome-shell-45.0-4.1.src
Upstream URL : https://wiki.gnome.org/Projects/GnomeShell
Summary : GNOME Shell
Description :
The GNOME Shell redefines user interactions with the GNOME desktop. In
particular, it offers new paradigms for launching applications, accessing
documents, and organizing open windows in GNOME.
lsb_release -a
LSB Version: n/a
Distributor ID: openSUSE
Description: openSUSE Tumbleweed
Release: 20231026
Codename: n/a
zypper info ibus-libpinyin
Loading repository data...
Reading installed packages...
Information for package ibus-libpinyin:
---------------------------------------
Repository : openSUSE-Tumbleweed-Oss
Name : ibus-libpinyin
Version : 1.15.3-1.3
Arch : x86_64
Vendor : openSUSE
Installed Size : 2.6 MiB
Installed : Yes
Status : up-to-date
Source package : ibus-libpinyin-1.15.3-1.3.src
Upstream URL : https://github.com/libpinyin/ibus-libpinyin
Summary : Intelligent Pinyin engine based on libpinyin for IBus
Description :
It includes a Chinese Pinyin input method and a Chinese ZhuYin (Bopomofo)
input
method based on libpinyin for IBus.
zypper info mutter
Loading repository data...
Reading installed packages...
Information for package mutter:
-------------------------------
Repository : openSUSE-Tumbleweed-Oss
Name : mutter
Version : 45.0+45-1.1
Arch : x86_64
Vendor : openSUSE
Installed Size : 4.7 MiB
Installed : Yes (automatically)
Status : up-to-date
Source package : mutter-45.0+45-1.1.src
Upstream URL : https://www.gnome.org
Summary : Window and compositing manager based on Clutter
Description :
Mutter is a window and compositing manager based on Clutter, forked
from Metacity.
Intelligent Pinyin 1.15.3
<!--
Provide at least the following information:
* Your OS and version
* Affected Mutter version
* Does this issue appear in XOrg and/or Wayland
-->
```
SHELL=/bin/bash
SESSION_MANAGER=local/localhost.localdomain:@/tmp/.ICE-unix/1566,unix/localhost.localdomain:/tmp/.ICE-unix/1566
COLORTERM=truecolor
XDG_CONFIG_DIRS=/etc/xdg:/usr/local/etc/xdg:/usr/etc/xdg
LESS=-M -I -R
XDG_MENU_PREFIX=gnome-
MACHTYPE=x86_64-suse-linux
G_BROKEN_FILENAMES=1
HISTSIZE=1000
HOSTNAME=localhost.localdomain
FROM_HEADER=
MINICOM=-c on
JAVA_ROOT=/usr/lib64/jvm/jre-openjdk
JAVA_HOME=/usr/lib64/jvm/jre-openjdk
AUDIODRIVER=pulseaudio
JRE_HOME=/usr/lib64/jvm/java-11-openjdk-11
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
CPU=x86_64
JAVA_BINDIR=/usr/lib64/jvm/jre-openjdk/bin
XMODIFIERS=@im=ibus
DESKTOP_SESSION=default
GPG_TTY=/dev/pts/0
PWD=/home/doof
QEMU_AUDIO_DRV=pa
XDG_SESSION_DESKTOP=default
LOGNAME=doof
XDG_SESSION_TYPE=wayland
MANPATH=/usr/local/man:/usr/share/man
SYSTEMD_EXEC_PID=1597
XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth.7I2LD2
LS_OPTIONS=-N --color=tty -T 0
XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB
XNLSPATH=/usr/share/X11/nls
HOME=/home/doof
USERNAME=doof
LANG=en_US.UTF-8
LS_COLORS=no=00:fi=00:di=01;34:ln=00;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=41;33;01:ex=00;32:*.cmd=00;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tgz=00;31:*.arc=00;31:*.arj=00;31:*.taz=00;31:*.lha=00;31:*.lz4=00;31:*.lzh=00;31:*.lzma=00;31:*.tlz=00;31:*.txz=00;31:*.tzo=00;31:*.t7z=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.dz=00;31:*.gz=00;31:*.lrz=00;31:*.lz=00;31:*.lzo=00;31:*.xz=00;31:*.zst=00;31:*.tzst=00;31:*.bz2=00;31:*.bz=00;31:*.tbz=00;31:*.tbz2=00;31:*.tz=00;31:*.deb=00;31:*.rpm=00;31:*.jar=00;31:*.war=00;31:*.ear=00;31:*.sar=00;31:*.rar=00;31:*.alz=00;31:*.ace=00;31:*.zoo=00;31:*.cpio=00;31:*.7z=00;31:*.rz=00;31:*.cab=00;31:*.wim=00;31:*.swm=00;31:*.dwm=00;31:*.esd=00;31:*.asf=01;35:*.avi=01;35:*.bmp=01;35:*.cgm=01;35:*.dl=01;35:*.emf=01;35:*.flc=01;35:*.fli=01;35:*.flv=01;35:*.gif=01;35:*.gl=01;35:*.jpeg=01;35:*.jpg=01;35:*.m2v=01;35:*.m4v=01;35:*.mjpeg=01;35:*.mjpg=01;35:*.mkv=01;35:*.mng=01;35:*.mov=01;35:*.mp4=01;35:*.mp4v=01;35:*.mpeg=01;35:*.mpg=01;35:*.nuv=01;35:*.ogm=01;35:*.pbm=01;35:*.pcx=01;35:*.pgm=01;35:*.png=01;35:*.ppm=01;35:*.qt=01;35:*.rm=01;35:*.rmvb=01;35:*.svg=01;35:*.svgz=01;35:*.tga=01;35:*.tif=01;35:*.tiff=01;35:*.vob=01;35:*.webm=01;35:*.webp=01;35:*.wmv=01;35:*.xbm=01;35:*.xcf=01;35:*.xpm=01;35:*.xwd=01;35:*.yuv=01;35:*.ogv=01;35:*.ogx=01;35:*.aiff=00;32:*.ape=00;32:*.aac=00;32:*.au=00;32:*.flac=00;32:*.m4a=00;32:*.mid=00;32:*.midi=00;32:*.mka=00;32:*.mp3=00;32:*.mpc=00;32:*.ogg=00;32:*.ra=00;32:*.voc=00;32:*.wav=00;32:*.wma=00;32:*.wv=00;32:*.oga=00;32:*.opus=00;32:*.spx=00;32:*.xspf=00;32:
XDG_CURRENT_DESKTOP=GNOME
PYTHONSTARTUP=/etc/pythonstart
VTE_VERSION=7401
WAYLAND_DISPLAY=wayland-0
OSTYPE=linux
GNOME_TERMINAL_SCREEN=/org/gnome/Terminal/screen/e6e5821d_8d10_4805_b93a_ebbc9bc681f8
LESS_ADVANCED_PREPROCESSOR=no
MOZ_GMP_PATH=/usr/lib64/mozilla/plugins/gmp-gmpopenh264/system-installed
GNOME_SETUP_DISPLAY=:1
LESSCLOSE=lessclose.sh %s %s
XDG_SESSION_CLASS=user
TERM=xterm-256color
G_FILENAME_ENCODING=@locale,UTF-8,ISO-8859-15,CP1252
HOST=localhost.localdomain
XAUTHLOCALHOSTNAME=localhost.localdomain
LESSOPEN=lessopen.sh %s
USER=doof
GNOME_TERMINAL_SERVICE=:1.204
MORE=-sl
CSHEDIT=emacs
DISPLAY=:0
SHLVL=1
WINDOWMANAGER=/usr/bin/gnome
PAGER=less
QT_IM_MODULE=ibus
XDG_RUNTIME_DIR=/run/user/1000
DEBUGINFOD_URLS=https://debuginfod.opensuse.org/
MANPATHISSET=yes
GTK3_MODULES=lunar-calendar-module
XDG_DATA_DIRS=/home/doof/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/
VENDOR=suse
PATH=/home/doof/.local/bin:/home/doof/bin:/usr/local/bin:/usr/bin:/bin
GDMSESSION=default
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
PROFILEREAD=true
MAIL=/var/mail/doof
HOSTTYPE=x86_64
LESSKEY=/usr/etc/lesskey.bin
_=/usr/bin/env
```
Wayland Gnome
### Bug summary
Typing any ascii with caps lock enabled into the Intelligent pinyin causes character repeat into the textfield. This behavior happens regardless independent of a physical keyboard. You can reproduce this behavior with the onscreen keyboard.
### Steps to reproduce
<!--
1. Setup libpinyin and ibus
2. Optional: Enable Onscreen keyboard
3. Enable "Intelligent Pinyin"
4. Enable Caps Lock
5. Type "jia1"
-->
### What happened
You will see the last char to repeat
### What did you expect to happen
The last character should not repeat.
### 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. -->
![Screenshot_from_2023-10-29_16-47-01](/uploads/6927a44e4c4d2895b9bf973adc37340f/Screenshot_from_2023-10-29_16-47-01.png)
![Screenshot_from_2023-10-29_16-47-23](/uploads/163ec23f13bf3f2094658944409a9974/Screenshot_from_2023-10-29_16-47-23.png)
![Screenshot_from_2023-10-29_16-47-28](/uploads/e00fbea99dd473e766301a3b80ce18db/Screenshot_from_2023-10-29_16-47-28.png)
![Screenshot_from_2023-10-29_16-47-31](/uploads/c59114af95be301261eb7021b4f6633c/Screenshot_from_2023-10-29_16-47-31.png)
![Screenshot_from_2023-10-29_16-47-34](/uploads/e67b2e6c7c8d8b482d64c6885d2a3119/Screenshot_from_2023-10-29_16-47-34.png)
![Screenshot_from_2023-10-29_16-47-37](/uploads/e3e043d6d3d6e846466497e37e1a2105/Screenshot_from_2023-10-29_16-47-37.png)
![Screenshot_from_2023-10-29_16-47-41](/uploads/2a3808a9deed045917a416f4c6231af7/Screenshot_from_2023-10-29_16-47-41.png)