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
kwin doesn't manage screens
Please provide the debugging info as explained on this page: https://community.kde.org/Solid/Projects/ScreenManagement#Debugging_Information Thanks for the help!
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
Created attachment 100029 [details] kscreen-console_bug
Created attachment 100030 [details] kcmshell5_kcm_kscreen
Created attachment 100031 [details] kquitapp_kded_kded5
The previous attachments were made when I succesfully managed to activate the right screen using the disable/enable trick.
Please also attach the screen configuration files in ~/.local/share/kscreen/ .
Created attachment 100032 [details] kscreen_multimonitor
Created attachment 100033 [details] kscreen_singlemonitor
The filenames are relevant, though...
25b4d83c8e0d644145929411d0338ae1 is kscreen_multimonitor 566c148c9eac3d523ca973e8c29a01ef is kscreen_singlemonitor
Cool. Thanks a lot for providing the information. I'll have a look.
Hi Sebastian, did you find anything?
Not yet. I haven't gotten to it yet, please be more patient.
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.
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.
Problem looks solved after yesterday upgrade to KDE Frameworks 5.25.
It's unlikely to be fixed by a Frameworks upgrade, libkscreen and kscreen are part of Plasma, and that's where we fixed it. :)
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.
It's in master and Plasma 5.8 material.
Any chance to backport it 5.7.4? 5.8 is months ahead :(
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.
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 :)
Still not fixed with KDE Neon 24/08/2016 GIT unstable: https://www.youtube.com/watch?v=jD7jwfKATdY&feature=youtu.be
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. :)
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.
Created attachment 100750 [details] kscreen.log kscreen.log after failed attempt
Created attachment 100751 [details] qdbus_KWin_supportInformation qdbus org.kde.KWin /KWin supportInformation after failed attempt
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)
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 :)
> 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?
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.
Created attachment 100793 [details] dmesg
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.
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 /
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 :)
@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.
(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.
> @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.
Upstream bug @Intel: https://bugs.freedesktop.org/show_bug.cgi?id=97531
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.
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).
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.
Created attachment 102295 [details] journalctl -b -0
Created attachment 102296 [details] journalctl -b -0 --priority=5
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!
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!
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!