Bug 363093 - Tearing prevention (vsync) settings lost when monitor turns on/off
Summary: Tearing prevention (vsync) settings lost when monitor turns on/off
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: multi-screen (show other bugs)
Version: 5.5.5
Platform: Kubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-15 07:41 UTC by Amichai Rothman
Modified: 2021-12-06 04:38 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
xrandr -q output (without TV) (1.41 KB, text/plain)
2016-05-15 08:31 UTC, Amichai Rothman
Details
xrandr -q output (with TV) (1.72 KB, text/plain)
2016-05-15 08:32 UTC, Amichai Rothman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Amichai Rothman 2016-05-15 07:41:48 UTC
Since the upgrade to Kubuntu 16.04, every time I turn on my TV (third monitor) there is lots of tearing when viewing videos. This is with an Intel i7 Haswell integrated GPU (no dedicated graphics card). The workaround is to go to System Settings -> Compositor and re-apply the Tearing prevention ("vsync") setting manually every time - it is set to "Full screen repaints", which is the correct option, but in order to re-apply it I need to select a different option and then "Full screen repaints" again and then click Apply, and everything is back to normal (no tearing) as long as the TV stays on. I have to do this every single time I turn on the TV for video to be watchable. This was not an issue in previous versions, where the setting always remained in effect and I never had to touch it regardless of turning anything on or off.


Reproducible: Always
Comment 1 Thomas Lübking 2016-05-15 08:17:50 UTC
Can you please post the outputs of "xrandr -q" w/ and w/o the Tv?
I assume simply suspending and resuming the compositor would achieve the same result?

Please notice that you can only sync to one output, so it really matters which output is synced (usually the primary one) and which you want to be synced. Notably if the tv runs at 50Hz and your other outputs at 60Hz.
Comment 2 Amichai Rothman 2016-05-15 08:31:53 UTC
Created attachment 98983 [details]
xrandr -q output (without TV)
Comment 3 Amichai Rothman 2016-05-15 08:32:15 UTC
Created attachment 98984 [details]
xrandr -q output (with TV)
Comment 4 Amichai Rothman 2016-05-15 08:36:57 UTC
Attached xrandr outputs as requested.

How do I suspend/resume the compositor? under compositor settings I only see a "Enable compositor on startup" option.

Everything you say about sync may be true. As a user all I know is that it worked and I never had to think about it, and now it's broken and requires annoying configuration changes before every use.
Comment 5 Thomas Lübking 2016-05-15 08:46:05 UTC
SHIFT+Alt+F12

All outputs run at approx.  60Hz, but interestingly none is tagged primary.
Which one do you expect to be synced (don't say "all", your HW cannot do that ;-)
Comment 6 Amichai Rothman 2016-05-18 18:36:02 UTC
The TV (HDMI1) should be synced.

It appears that suspending and resuming the compositor actually fixes the problem (temporarily). Here's my full experiment (all tests are with VLC playing full screen video on one of the monitors):

I started off with all 3 monitors on, and applied the vsync from the settings, so that the video runs on the TV without tearing. Then I turn off the TV and move the video to the first screen and second screen - both of them have tearing. Then I turn on the TV again - now there's tearing on all 3 screens. I then press SHIFT+ALT+F12 to suspend the compositor, and the tearing on the TV is gone - everything is ok again. If I press SHIFT+ALT+F12 again to resume the compositor, everything stays the same - there video is still ok with no tearing. That brings me back to the initial state of this test.

At least now I have a shorter workaround - instead of fiddling with settings, I can just press SHIFT+ALT+F12 twice, so it's a little more bearable.
Comment 7 Thomas Lübking 2016-05-19 08:12:13 UTC
try "xrandr --output HDMI1 --primary", in doubt restart the compositor (I'm not sure whether that generates a randr event caught by kwin)
Comment 8 Amichai Rothman 2016-05-19 09:05:01 UTC
I can see in both kscreen and xrandr that DP1 is primary. If I change it to HDMI1 then the KDE panel moves to the TV (which is NOT what I want), but it doesn't affect the tearing. As I stated above, if I restart the compositor it fixes the problem temporarily anyway, so I'm not sure what to look for with regards to the primary display change.

btw, thanks a lot for the quick responses and troubleshooting suggestions!
Comment 9 jon 2017-03-02 16:44:35 UTC
Same problem here with KDE neon 5.9.2
When I connect TV through HDMI cable to my notebook, "Full screen repaints" stops woking in the two screens and tearing appears.
Then to fix it, I have to run kwin and select again "Full screen repaints" (which was already selected!) and tearing disappears from both screens.

This problem is not present in other desktops (for example MATE, which I tested), so I'm quite sure it is Kwin and/or compositor related.

This is a BIG bug for me, as I'm plugging and unpluggin TV very often.

Any ideas?
Comment 10 August Rydberg 2017-03-11 16:15:09 UTC
I have the exact same problem and it is very annoying. It doesn't happen every time for me but that's probably due to some other bug that doesn't always recognize the external screen being disconnected at all, since all windows are still on the disconnected screen area.

Yoga 2 Pro with Intel i7 Haswell.
Kubuntu 16.04
KDE Plasma 5.8.5 (backported, but same problem on "vanilla" 16.04 plasma)
Comment 11 kde.org 2021-11-06 18:16:00 UTC
This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?
Comment 12 Bug Janitor Service 2021-11-21 04:39:15 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 13 Bug Janitor Service 2021-12-06 04:38:36 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!