SUMMARY I have a 3 screen setup, left monitor 90 degrees (ie. tall) with top aligned to other screens. Logged the bug with Telegram also here: https://bugs.telegram.org/c/10242 There is an included video of it in action. STEPS TO REPRODUCE 1. Click any picture or video in telegram 2. Usually it opens on same screen as telegram (right most) but now opens on far left. 3. Video or picture will flicker wildly. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Neon User (available in About System) KDE Plasma Version: 5.23.0 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION
Was telegram updated recently or is it a 5.23 regression?
It's hard to see on the video, but it looks like there are two copies of the video that are in sync?
Can confirm on X11. It has something to do with the output being rotated. If the output is not rotated, it's rendered fine. However, I can also reproduce this bug with compositing disabled, which points to the x server or telegram. I suggest to try wayland session.
On the other hand, with kwin 5.22, there is no flickering. Weird.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1535
Same error here, exactly the same steps to reproduce. In my case I have two monitors both in the same orientation but one at 144hz and another one in 60 Hz. If I move the telegram app to the same window where the flickering happens then there is no problem, but if I move it to the other one the problems appears again. Also I am having strange flickering starting youtube in fullscreen. Same problem when comming from sleep. With kde 5.22 no problem at all. I have disabled the compositor and the problem continues, also I have changed OpenGL and the same problem.
*** Bug 443800 has been marked as a duplicate of this bug. ***
(In reply to Bug Janitor Service from comment #5) > A possibly relevant merge request was started @ > https://invent.kde.org/plasma/kwin/-/merge_requests/1535 the patch fixes the mpv bug - https://bugs.kde.org/show_bug.cgi?id=443800 - for me
I have half of this. Telegram opens the image view window on the wrong display (opens on the primary display instead of the same display as I have the window up in; obviously it opens on the correct display if I have Telegram running on the primary display, but I usually don't), but I don't experience any flickering. I have an AMD graphics card; slightly factory-overclocked R9 290X. I use the open source AMDGPU drivers with Mesa for OpenGL and RADV for Vulkan, but I use the proprietary driver for OpenCL (for use in Blender). OpenCL is almost certainly irrelevant, but figured I should mention I do have parts of the proprietary driver installed.
Git commit 6d5fc9fd3000cf32ecb63a8252a6f50368f3604d by Vlad Zahorodnii. Committed on 18/10/2021 at 05:25. Pushed by vladz into branch 'master'. Restore old behavior of Workspace::clientArea(clientOpt, Toplevel) When geometry updates are blocked, the output doesn't get updated. This breaks Workspace::clientArea() overload that takes only the window. Previously, clientArea() would look up the output where the window is every time it's called, so the fact that the screen id or AbstractOutput is unsynchronized with the frame geometry was irrelevant. This change restores the old behavior as 5.23 is affected by the output() being out of sync with the frameGeometry(). Specifically, when kwin starts managing an X11 window, it will block geometry updates, setup the window, e.g. make it fullscreen, and unblock geometry updates. Since Workspace::clientArea(clientArea, Toplevel) uses the output(), X11Client::setFullScreen() will most likely put the X11 window at a wrong output if it's called inside X11Client::manage(). M +1 -1 src/workspace.cpp https://invent.kde.org/plasma/kwin/commit/6d5fc9fd3000cf32ecb63a8252a6f50368f3604d
Git commit 2958881264caf8d3bd83a34411e9586f8fcb7211 by Vlad Zahorodnii. Committed on 18/10/2021 at 05:26. Pushed by vladz into branch 'Plasma/5.23'. Restore old behavior of Workspace::clientArea(clientOpt, Toplevel) When geometry updates are blocked, the output doesn't get updated. This breaks Workspace::clientArea() overload that takes only the window. Previously, clientArea() would look up the output where the window is every time it's called, so the fact that the screen id or AbstractOutput is unsynchronized with the frame geometry was irrelevant. This change restores the old behavior as 5.23 is affected by the output() being out of sync with the frameGeometry(). Specifically, when kwin starts managing an X11 window, it will block geometry updates, setup the window, e.g. make it fullscreen, and unblock geometry updates. Since Workspace::clientArea(clientArea, Toplevel) uses the output(), X11Client::setFullScreen() will most likely put the X11 window at a wrong output if it's called inside X11Client::manage(). (cherry picked from commit 6d5fc9fd3000cf32ecb63a8252a6f50368f3604d) M +1 -1 src/workspace.cpp https://invent.kde.org/plasma/kwin/commit/2958881264caf8d3bd83a34411e9586f8fcb7211
*** Bug 443892 has been marked as a duplicate of this bug. ***
*** Bug 443760 has been marked as a duplicate of this bug. ***
Confirm fixed as of 5.23.1 and it also fixed another bug that had cropped up. I use Firefox on the centre monitor but only about 90% wide but vertical fully. It would show the main window correctly but the title bar was drawn the full width. The only way to get it back to responding correctly was to maximise Firefox, then unmaximixse where it would then show it to the full width of the screen, could grab the edge and resize. So related or not it got fixed along with it. Cheers folks :-)
*** Bug 444054 has been marked as a duplicate of this bug. ***
Solved for me in 5.23.1
*** Bug 444174 has been marked as a duplicate of this bug. ***
*** Bug 443854 has been marked as a duplicate of this bug. ***
*** Bug 444284 has been marked as a duplicate of this bug. ***
*** Bug 444368 has been marked as a duplicate of this bug. ***
*** Bug 444513 has been marked as a duplicate of this bug. ***
*** Bug 444026 has been marked as a duplicate of this bug. ***