Bug 443787 - Multimonitor Telegram click on video/picture opens on other screen flickers wildly
Summary: Multimonitor Telegram click on video/picture opens on other screen flickers w...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: platform-x11-standalone (show other bugs)
Version: 5.23.0
Platform: Neon Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 443760 443800 443854 443892 444026 444054 444174 444284 444368 444513 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-10-15 13:16 UTC by Félim Whiteley
Modified: 2021-11-03 11:14 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.23.1


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Félim Whiteley 2021-10-15 13:16:39 UTC
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
Comment 1 Vlad Zahorodnii 2021-10-15 13:31:40 UTC
Was telegram updated recently or is it a 5.23 regression?
Comment 2 Vlad Zahorodnii 2021-10-15 13:32:21 UTC
It's hard to see on the video, but it looks like there are two copies of the video that are in sync?
Comment 3 Vlad Zahorodnii 2021-10-15 13:55:27 UTC
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.
Comment 4 Vlad Zahorodnii 2021-10-15 13:59:47 UTC
On the other hand, with kwin 5.22, there is no flickering. Weird.
Comment 5 Bug Janitor Service 2021-10-15 14:34:56 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1535
Comment 6 mileteko65 2021-10-16 15:27:14 UTC
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.
Comment 7 Vlad Zahorodnii 2021-10-17 14:29:55 UTC
*** Bug 443800 has been marked as a duplicate of this bug. ***
Comment 8 Jim Jones 2021-10-17 16:03:56 UTC
(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
Comment 9 Colin Griffith 2021-10-17 19:29:46 UTC
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.
Comment 10 Vlad Zahorodnii 2021-10-18 05:25:24 UTC
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
Comment 11 Vlad Zahorodnii 2021-10-18 05:26:09 UTC
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
Comment 12 Vlad Zahorodnii 2021-10-18 06:08:42 UTC
*** Bug 443892 has been marked as a duplicate of this bug. ***
Comment 13 Nate Graham 2021-10-18 15:48:52 UTC
*** Bug 443760 has been marked as a duplicate of this bug. ***
Comment 14 Félim Whiteley 2021-10-20 11:10:33 UTC
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 :-)
Comment 15 Nate Graham 2021-10-20 14:42:17 UTC
*** Bug 444054 has been marked as a duplicate of this bug. ***
Comment 16 mileteko65 2021-10-20 17:54:56 UTC
Solved for me in 5.23.1
Comment 17 Nate Graham 2021-10-21 14:56:36 UTC
*** Bug 444174 has been marked as a duplicate of this bug. ***
Comment 18 Nate Graham 2021-10-23 01:46:18 UTC
*** Bug 443854 has been marked as a duplicate of this bug. ***
Comment 19 Nate Graham 2021-10-25 20:44:40 UTC
*** Bug 444284 has been marked as a duplicate of this bug. ***
Comment 20 Nate Graham 2021-10-25 22:26:32 UTC
*** Bug 444368 has been marked as a duplicate of this bug. ***
Comment 21 Vlad Zahorodnii 2021-10-28 05:58:17 UTC
*** Bug 444513 has been marked as a duplicate of this bug. ***
Comment 22 Michael Weghorn 2021-11-03 11:14:37 UTC
*** Bug 444026 has been marked as a duplicate of this bug. ***