"Window blinds" after performing certain window management actions

[jacobgkau]

After performing window management actions, I sometimes have the entire screen change to a repeated strip showing the top and/or bottom of the screen. Moving the mouse and/or switching workspaces causes the strips to move around and change in size a little bit.

Video of when this happened back in February after unmaximizing a Firefox window with Super-M:

https://github.com/pop-os/cosmic-comp/assets/7199422/e7929869-1038-4df8-9f40-872fa4496574

Photo of this happening just now after moving a window down several workspaces with Super-Shift-Down several times in quick succession:

It's interesting to see that the dock and panel appear to be overlapping within the strips. It's almost like the screen resolution's being set so the height is way lower than it should be.

I understand this is a tricky one since it happens somewhat infrequently, but it is fairly disruptive since it requires restarting cosmic-comp to recover. Let me know if I can get any specific logs or debugging output to help track it down. Here's my system log starting when I resumed from suspend today and ending when I rebooted from a TTY after this happened: comp-blinds.txt

[jacobgkau]

I just had this happen twice in quick succession. Before it started happening, I un-maximized a Firefox window and was attempting to pin it to one side of the screen (all with the mouse). I noticed the text in the tab bar get fuzzy/pixelated, which I initially thought was an Xwayland issue. Then the screen went to blinds.

I did discover a workaround, thankfully. After successfully switching to a TTY, switching back to TTY1 where COSMIC was running made the screen go back to normal. It almost immediately happened a second time, but after switching TTYs and back a second time, it didn't immediately happen a third time. So that makes the issue a little less critical.

[jacobgkau]

Scratch that: after using the recovered session for a few minutes, certain keyboard shortcuts stopped working (e.g. Super for opening the launcher and Esc for closing it), the keyboard eventually stopped working altogether, and finally Firefox and then everything else stopped responding to mouse inputs, so I had to hard reboot. I'm assuming that instability is related to having had the issue occur.

[burakturkerdev]

I experience this issue consistently when using my main display, but interestingly, it only occurs on my main display, not on the two external displays. Here are my two thoughts on this matter:

1- It might be related to HDPI displays, although I'm not certain if comp have any work with pixel density. 2- The issue unique to main display, as it doesn't happen on the external displays.

[ids1024]

I've also noticed this one an internal display, with 2x scaling, but not the 1x scaling external monitors. Nor does it happen without external monitors connected. So something related to mixed DPI?

Killing cosmic-panel (when starting cosmic-comp manually and not with cosmic-session, so it isn't autorestarted) fixes it.

[jacobgkau]

Every time it's happened on the serw13, it's been with the internal LoDPI screen only, but good to know what might help recreate it on other hardware.

[ids1024]

Interesting. It isn't necessarily DPI, and it isn't always with multiple monitors? But seems to only happen with the builtin monitor? While on my system, I've only noticed it with external monitors connected. Kind of odd.

I'm having trouble thinking of what might cause this, or where to look for what code would be responsible. Though having some reproducible way to cause it would definitely help.

[ids1024]

It seems I can reproduce this fairly consistently with 2 external monitors (but not with only 1?) just opening terminals on an external monitor, switching workspaces, and switching tiling. I haven't identified a specific set of steps that causes it.

I see it repeated 3 times, rather than 5. On the builtin monitor.

Interestingly I see it's using two DRM overlay planes: a 2880x88 plane and a 2880x144 plane. The sizes of the panel and dock. Seems odd, but being related to DRM direct scanout would explain why it varies by computer, monitor, and number of connected monitors...

[ids1024]

Okay, actually this seems to be reproducing it consistently for me:

• Run cosmic-comp
• Place cursor on external monitor
• Start panel in a terminal with super-t, then cosmic-panel
• Switch workspaces with super-2
• Open terminal with super-t
• Exit with exit

Edit: Maybe not entirely consistent?

[ids1024]

Setting planes.overlay = vec![] in backend/drm/kms.mod seems to prevent this, confirming it's related to overlay planes.

[ids1024]

Testing this again after https://github.com/pop-os/cosmic-comp/pull/546, it seemed to not be reproducible with the above steps, but then after rebooting it was immediately reproducible?

Interesting. Naturally DRM properties will be reset on reboot, but I wonder what changed to make it not cause issues...

[Drakulix]

Testing this again after #546, it seemed to not be reproducible with the above steps, but then after rebooting it was immediately reproducible?

Interesting. Naturally DRM properties will be reset on reboot, but I wonder what changed to make it not cause issues...

I sadly can't seem to reproduce this on any of my three machines. Did you happen to capture a drm_info log, when the issue happened?

[ids1024]

The display I'm seeing this with is 120hz, and I just noticed that I've been seeing this issue with it set to 60hz... and it doesn't seem to be reproducible (at least in the same way) at 120hz.

[ids1024]

Seems to be related to partial DRM updates, in particular those that don't update the primary plane.

And presumably some kind of bug in the i915 driver.

[Drakulix]

Should be fixed by:

• https://github.com/Smithay/smithay/commit/72b251c20ee2ff4cf85dd1c10e83df0ea8fde3fe
• https://github.com/pop-os/cosmic-comp/commit/2d0f1cbf2be311b91096b2f2332cd7bafabbfde3

Big thanks to @ids1024 and @cmeissl for debugging!