Bug 365455

Summary: Second external monitor of MST setup does not turn on most of the times
Product: [Plasma] KScreen Reporter: darkbasic
Component: commonAssignee: Sebastian Kügler <sebas>
Status: RESOLVED WORKSFORME    
Severity: normal CC: dion, gary.wilson, hello, kde, leonard, mgraesslin, milansport, nate, simonandric5, zhaixiang
Priority: NOR    
Version: git   
Target Milestone: ---   
Platform: Other   
OS: Linux   
URL: https://www.youtube.com/watch?v=Vhc85L2PRdI
Latest Commit: Version Fixed In:
Attachments: kscreen-console_bug
kcmshell5_kcm_kscreen
kquitapp_kded_kded5
kscreen_multimonitor
kscreen_singlemonitor
kscreen.log
qdbus_KWin_supportInformation
plasma_backtrace.log
plasma_backtrace_nomst.log
dmesg
Xorg.0.log
journalctl -b -0
journalctl -b -0 --priority=5

Description darkbasic 2016-07-12 08:11:24 UTC
https://www.youtube.com/watch?v=Vhc85L2PRdI
I made a video to demostrate the problem. I have two external monitors attached to a single mini displayport MST cable and when I turn on the laptop both monitors are turned on up to the kdm login. After the login the monitors get alternately turned off and 100% of the times the right monitors is turned off when I reach the desktop. Most of the times it is not possibile to turn on that monitor again, the video shows one of the few times when I had been able to turn it on using the disable/enable trick.

I'm using Archlinux on Intel Broadwell (DELL XPS 13 9343 +  2 x DELL U2515H on DP MST). Kernel 4.4 LTS (also tried 4.5 and 4.6). I get this issue with both xf86-video-intel and modesetting.

Reproducible: Always
Comment 1 Thomas Lübking 2016-07-12 08:50:36 UTC
kwin doesn't manage screens
Comment 2 Sebastian Kügler 2016-07-12 09:01:40 UTC
Please provide the debugging info as explained on this page: https://community.kde.org/Solid/Projects/ScreenManagement#Debugging_Information

Thanks for the help!
Comment 3 Leslie Zhai 2016-07-12 09:14:17 UTC
Hi Niccolò,

I am trying to fix the Secondray output relative issue shown as https://pbs.twimg.com/media/CnIbFaDVMAApqzM.jpg

But it is able to move a window to the right shown as https://pbs.twimg.com/media/CnIbGh3VMAAoSZR.jpg

I argue that it might be desktopcontainments' issue, please someone give me some advice, thanks a lot!

Regards,
Leslie Zhai
Comment 4 darkbasic 2016-07-12 10:10:52 UTC
Created attachment 100029 [details]
kscreen-console_bug
Comment 5 darkbasic 2016-07-12 10:11:15 UTC
Created attachment 100030 [details]
kcmshell5_kcm_kscreen
Comment 6 darkbasic 2016-07-12 10:11:31 UTC
Created attachment 100031 [details]
kquitapp_kded_kded5
Comment 7 darkbasic 2016-07-12 10:12:32 UTC
The previous attachments were made when I succesfully managed to activate the right screen using the disable/enable trick.
Comment 8 Sebastian Kügler 2016-07-12 10:44:55 UTC
Please also attach the screen configuration files in ~/.local/share/kscreen/ .
Comment 9 darkbasic 2016-07-12 11:09:27 UTC
Created attachment 100032 [details]
kscreen_multimonitor
Comment 10 darkbasic 2016-07-12 11:09:40 UTC
Created attachment 100033 [details]
kscreen_singlemonitor
Comment 11 Sebastian Kügler 2016-07-12 12:24:51 UTC
The filenames are relevant, though...
Comment 12 darkbasic 2016-07-12 13:29:56 UTC
25b4d83c8e0d644145929411d0338ae1 is kscreen_multimonitor
566c148c9eac3d523ca973e8c29a01ef is kscreen_singlemonitor
Comment 13 Sebastian Kügler 2016-07-12 13:40:54 UTC
Cool. Thanks a lot for providing the information. I'll have a look.
Comment 14 darkbasic 2016-07-21 21:13:20 UTC
Hi Sebastian, did you find anything?
Comment 15 Sebastian Kügler 2016-07-25 09:50:28 UTC
Not yet. I haven't gotten to it yet, please be more patient.
Comment 16 darkbasic 2016-07-27 08:49:48 UTC
I don't know if it may be of interest but with a Plasma Wayland Session:
1) I don't have this problem
2) Every time I move the cursor to a new screen that new screen goes black. To get back that screen I have to switch (CTRL+ALT+F1) to sddm and then switch back to wayland (CTRL+ALT+F2), sometimes I have to do it more than one time. Then I can move the cursor in the current screen without issues, but as soon as I move it to another screen that screen goes black once again. So moving from one screen to another means moving the cursor to that screen, switching to sddm and then wayland.
Comment 17 emes 2016-07-30 16:22:33 UTC
I have exactly the same problem.
Plasma 5.7.2, Linux kernel 4.7.

I just want to add, that problem does not occurs when I unify outputs.
Comment 18 emes 2016-08-17 18:48:49 UTC
Problem looks solved after yesterday upgrade to KDE Frameworks 5.25.
Comment 19 Sebastian Kügler 2016-08-18 09:24:27 UTC
It's unlikely to be fixed by a Frameworks upgrade, libkscreen and kscreen are part of Plasma, and that's where we fixed it. :)
Comment 20 darkbasic 2016-08-18 10:39:36 UTC
If the fix is supposed to be in Plasma, then unless you're using a git version the fix still didn't land: with Plasma 5.7.3 and framework 5.24 I still experience this bug.
Comment 21 Sebastian Kügler 2016-08-18 11:14:07 UTC
It's in master and Plasma 5.8 material.
Comment 22 darkbasic 2016-08-18 14:50:35 UTC
Any chance to backport it 5.7.4? 5.8 is months ahead :(
Comment 23 Sebastian Kügler 2016-08-19 11:25:19 UTC
I thought about it, but I don't think that's an option. There's a series of patches which affect this problem, some are pretty risk-free, others change low-level functions that we can't autotest. This means that backporting some of them means that we need proper user-testing, and I don't think we can get that without a beta. I'm just not comfortable putting them all in a stable branch.

Related is also a series of fixes to plasmashell, without which this fix is quite useless (as Plasma will mess up containments), this also went into master, and it's really too invasive to backport.

So, sorry, it's not an option.
Comment 24 darkbasic 2016-08-19 14:38:27 UTC
Ok, can you please link me a live distro with Plasma git so that I will be able to at least test it before it gets released? Thanks for your efforts, this was a really annoying bug and it seems I will be finally able to advice Plasma usage in production starting from 5.8 :)
Comment 25 darkbasic 2016-08-24 19:55:17 UTC
Still not fixed with KDE Neon 24/08/2016 GIT unstable: https://www.youtube.com/watch?v=jD7jwfKATdY&feature=youtu.be
Comment 26 Sebastian Kügler 2016-08-24 23:18:55 UTC
It seems that kscreen thinks it has enabled the displays as you told it to, that would be consistent with what the kcm shows, and how kwin understands it (kwin would not place that window offscreen). The black screen seems actually switched off on the monitor side, at least that's what would kwin and kscreen do with a monitor just switched off. (If it just failed to enable it, it would not allow windows in that space.)

Could you get me the ~/.local/share/kscreen/kscreen.log after a failed attempt? This will show us what's going on at a lower level as well.

If your laptop has an HDMI port, could you hook up one of the Dell displays to that and see if it shows the problem as well?

Does this always happen with the same monitor? Could you try switching the cables around and see if it's random, or if you could pin it down to one of the connectors or displays?

Love your videos and screen setup, by the way. :)
Comment 27 Martin Flöser 2016-08-25 11:29:30 UTC
can you post the output of:
qdbus org.kde.KWin /KWin supportInformation

when having the problem? I would like to know what kwin thinks what the screens look like.
Comment 28 darkbasic 2016-08-25 13:39:02 UTC
Created attachment 100750 [details]
kscreen.log

kscreen.log after failed attempt
Comment 29 darkbasic 2016-08-25 13:40:05 UTC
Created attachment 100751 [details]
qdbus_KWin_supportInformation

qdbus org.kde.KWin /KWin supportInformation after failed attempt
Comment 30 darkbasic 2016-08-25 13:45:20 UTC
Created attachment 100752 [details]
plasma_backtrace.log

Also, did you notice the compositor settings window at the start of my previous video? Here it is: https://drive.google.com/open?id=0Bwe9Wtc-5xF1dk5JZlg5QXJuV2c
You are not supposed to get it unless something's wrong.

Also in my previous video I didn't notice the Crash Reporting Assistant after disabling the laptop's main monitor, but it seems plasma crashed. Here is the log (attached plasma_backtrace.log)
Comment 31 darkbasic 2016-08-25 14:05:49 UTC
Created attachment 100753 [details]
plasma_backtrace_nomst.log

> Does this always happen with the same monitor? Could you try switching the cables around
> and see if it's random, or if you could pin it down to one of the connectors or displays?

It always happen to the monitor on the right (DP1-1), but simply because it is the "secondary" monitor of the MST setup. The laptop's mDP cable is attached to the monitor on the left (DP1-8), the output of which is then attached to the monitor on the right (DP1-1). If I switch them nothing changes, the "black" one is always the "secondary".

> If your laptop has an HDMI port, could you hook up one of the Dell displays to that and see
> if it shows the problem as well?

It doesn't have HDMI, but I have an mDP->HDMI adapter if you want. Anyway I think the problem is MST, so I can simply disable it in the monitor on the left and the right monitor will be a duplicate, not seen by the system.

This is how I disable MST on the left monitor:
1) https://drive.google.com/open?id=0Bwe9Wtc-5xF1dU5qU0RYQ2ZiT28
2) https://drive.google.com/open?id=0Bwe9Wtc-5xF1eFVqMERfTlVlNms

Here is the video with MST turned off: https://www.youtube.com/watch?v=a2hgzNzo8PM&feature=youtu.be

First thing to notice: there is no compositor settings window anymore at startup! This is a good sign, because you are not supposed to see it unless there are troubles with compositing.

Second thing to notice: no back screens.

Third thing to notice: Crash Reporting Assistant still pops up after disabling the laptop's main monitor (see attached plasma_backtrace_nomst.log)

> Love your videos and screen setup, by the way. :)

Thanks, I both love and hate my multi-screen setup. I love it because it's awesome to code with it and a mechanical keyboard. I hate it because I had lots of multi-screen troubles with Plasma and I love to use Plasma as well :)
Comment 32 Martin Flöser 2016-08-26 07:39:04 UTC
> qdbus org.kde.KWin /KWin supportInformation after failed attempt

it has two screens shown correctly so from xrandr information it looks correct.

Just sharing something I observed this morning on Wayland: a page flip failed turning one screen off. I waited for power management setting both screens into dpms mode, then moved the mouse to exit dpms and look there, both screens are on again.

Which brings me to a theory: maybe the modesetting fails on the screen and that's why it goes off? Can you have a look into the xorg log and into dmesg whether there are any messages related to that?
Comment 33 Sebastian Kügler 2016-08-26 15:33:14 UTC
Just an observation: The kscreen.log looks completely fine as well. Would be interesting indeed if you can trigger switching the display on by going through a dpms cycle, as Martin asked.
Comment 34 darkbasic 2016-08-26 22:35:12 UTC
Created attachment 100793 [details]
dmesg
Comment 35 darkbasic 2016-08-26 22:37:56 UTC
Created attachment 100794 [details]
Xorg.0.log

> Would be interesting indeed if you can trigger switching the display on by going through a dpms
> cycle, as Martin asked.

After the dpms cycle the right monitor turned on as Martin said! I wouldn't be surprised if it ends up being yet another Intel bug.
Comment 36 emes 2016-08-27 13:12:37 UTC
Hmm, so maybe that why I thought upgrading to KDE Frameworks 5.25 solved to problem but it was truly solved by upgrading Intel drivers:

Started emerge on: aug 14, 2016 22:41:57 
upgrade ~75 KDE Frameworks 5.25 packages

Started emerge on: sie 16, 2016 21:03:10
1471374481:  >>> emerge (5 of 6) x11-drivers/xf86-video-intel-2.99.917_p20160812 to /
1471374481:  === (5 of 6) Cleaning (x11-drivers/xf86-video-intel-2.99.917_p20160812::/usr/portage/x11-drivers/xf86-video-intel/xf86-video-intel-2.99.917_p20160812.ebuild)
1471374481:  === (5 of 6) Compiling/Merging (x11-drivers/xf86-video-intel-2.99.917_p20160812::/usr/portage/x11-drivers/xf86-video-intel/xf86-video-intel-2.99.917_p20160812.ebuild)
1471374530:  === (5 of 6) Merging (x11-drivers/xf86-video-intel-2.99.917_p20160812::/usr/portage/x11-drivers/xf86-video-intel/xf86-video-intel-2.99.917_p20160812.ebuild)
1471374532:  >>> AUTOCLEAN: x11-drivers/xf86-video-intel:0
1471374532:  === Unmerging... (x11-drivers/xf86-video-intel-2.99.917_p20160803)
1471374534:  >>> unmerge success: x11-drivers/xf86-video-intel-2.99.917_p20160803
1471374537:  === (5 of 6) Post-Build Cleaning (x11-drivers/xf86-video-intel-2.99.917_p20160812::/usr/portage/x11-drivers/xf86-video-intel/xf86-video-intel-2.99.917_p20160812.ebuild)
1471374537:  ::: completed emerge (5 of 6) x11-drivers/xf86-video-intel-2.99.917_p20160812 to /
Comment 37 emes 2016-08-27 13:18:14 UTC
Sorry I forgot to translate "sie" for you in the second date. "sie" means August of course.
The second upgrade was 2 days later anyway :)
Comment 38 Sebastian Kügler 2016-08-27 13:54:58 UTC
@darkbasic: could you try upgrading your Intel drivers?

We most likely can't do anything in KDE about this problem, as it's a driver / hardware problem.
Comment 39 Martin Flöser 2016-08-27 14:02:12 UTC
(In reply to Sebastian Kügler from comment #38)
> @darkbasic: could you try upgrading your Intel drivers?

or try switching to the modesettings xorg driver. All major distributions are currently in the process of doing so due to the quality of the Intel driver.
Comment 40 darkbasic 2016-08-27 15:15:06 UTC
> @darkbasic: could you try upgrading your Intel drivers?

I already have a recent snapshot on my main system with Plasma 5.7.3: extra/xf86-video-intel 1:2.99.917+697+g12c14de-1
I don't know about KDE NEON with 5.7.90 git anyway.

> or try switching to the modesettings xorg driver. All major distributions are currently in the 
> process of doing so due to the quality of the Intel driver.

I will quote myself about modesetting:
> I get this issue with both xf86-video-intel and modesetting

I already tried modesetting since the beginning because I know about the Intel driver being shit.  I'm talking about my main system with Plasma 5.7.3, I didn't try modesetting on KDE NEON with Plasma 5.7.90 git.

It there is an Intel bug it must be somewhere else in their stack because modesetting has the very same problem. Kernel 4.4 and 4.7 both are affected. mesa git is affected too.

P.S.
Crossing my fingers for Zen being great, I really hope to buy an AMD laptop next time.
Comment 41 darkbasic 2016-08-29 10:18:32 UTC
Upstream bug @Intel: https://bugs.freedesktop.org/show_bug.cgi?id=97531
Comment 42 darkbasic 2016-10-27 09:29:44 UTC
Things got worse with Plasma 5.8, now if I start my PC with my external monitors attached there is no panel anymore. So I have to start the PC with the mini displayport connector detached, then attach it after Plasma started. Such a way the panel doesn't disappear.
Comment 43 darkbasic 2016-10-27 16:59:53 UTC
Intel developers think the issue is not on their end. I'm reopening because I just noticed that such problem doesn't happen with Gnome on Fedora 25 beta (at least on Xorg, I didn't manage to use more than two monitors with Wayland because the button to enable the third one is always grayed out).
Comment 44 darkbasic 2016-11-18 13:11:16 UTC
While debugging a multi-monitor issue in both colord-kde and argyllcms I noticed something weird in the logs:

$ journalctl -b -0 --priority=5 | grep kwin
[...]
nov 18 13:49:00 arch-laptop kwin_x11[998]: Freeze in OpenGL initialization detected
nov 18 13:49:05 arch-laptop kwin_x11[1077]: kwin_core: Compositing is not possible
nov 18 13:49:06 arch-laptop kwin_x11[1077]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 1243, resource id: 41943044, major code: 18 (ChangeProperty), minor code: 0
[...]


$ journalctl -b -0 --priority=5 | grep kscreen
nov 18 13:48:43 arch-laptop kdeinit5[949]: kf5.kded: No X-KDE-DBus-ServiceName found in "/usr/lib/qt/plugins/kf5/kded/kscreen.so"
nov 18 13:48:45 arch-laptop kdeinit5[949]: kscreen.kded: PowerDevil SuspendSession action not available!
nov 18 13:48:45 arch-laptop kdeinit5[949]: kscreen.kded:         Failed to find a matching mode - this means that our config is corruptedor a different device with the same serial number has been connected (very unlikely).Falling back to preferred modes.
nov 18 13:49:23 arch-laptop systemsettings5[1458]: file:///usr/share/kcm_kscreen/qml/Output.qml:54:5: QML MouseArea: Binding loop detected for property "width"
[...]


I don't know if it may have something to do with this bug or not, but I'm attaching a full "journalctl -b 0" and a "journalctl -b -0 --priority=5".

I also noticed that the "disappearing panel" bug introduced with Plasma 5.8 is intermittent.
Comment 45 darkbasic 2016-11-18 13:13:26 UTC
Created attachment 102295 [details]
journalctl -b -0
Comment 46 darkbasic 2016-11-18 13:13:47 UTC
Created attachment 102296 [details]
journalctl -b -0 --priority=5
Comment 47 Nate Graham 2022-11-08 18:54:03 UTC
Thank you for the bug report. Unfortunately we were not able to get to it yet. Can we ask you to please see if you can reproduce the issue with Plasma 5.25 or 5.26?

If you can, please change the status to CONFIRMED when replying. Thanks a lot!
Comment 48 Bug Janitor Service 2022-11-23 05:14: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 49 Bug Janitor Service 2022-12-08 05:13:50 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!