I'm trying to run Plasma on Lenovo T460s (Skylake CPU, a different thing from T460). Multiscreen setup works fine when using laptops HDMI/DP outputs. However when using Lenovo Ultradock, docking station, external displays are not recognized properly. They are either not seen; seen but can not be activated; or screen becomes garbled. Booting with laptop plugged into docking station makes external displays work, but after unplugging / sleeping / connecting external monitors through cables - docking displays do not come back most of the times. I've tested this with Kubuntu 16.04.1 + Plasma 5.6.5 and also with KDE Neon Live CD 5.7.2 This is not hardware issue IMHO, since with stock Ubuntu 16.04.1 (Unity) everything works flawless and it's the same kernel as Neon. I'll be happy to provide more details if someone can guide me on how (i.e. booting from Neon developer edition, etc.) Reproducible: Always
Thanks for the report! Good news, just last night, I reproduced this issue. Working on a fix. I'll let you know once a patch is in Neon, it would be nice if you could test it then to confirm that we're looking at the same problem.
Great news! I'll be glad to test this. Please let me know right away.
Git commit c2e1becccec9a2cccc80701535733c784f318e5d by Sebastian Kügler. Committed on 02/08/2016 at 13:48. Pushed by sebas into branch 'master'. update CRTCs before enabling an output Summary: When connecting the docking station (Lenovo OneLink+), which has a VGA connected monitor attached, enabling a display usually fails. It complains about no CRTC being available (and indeed the available CRTCs don't have our output as possible output). Updating the CRTC before enabling an output makes this work for me. Note: it's not a problem when connecting via HDMI, this seems to be either unique to VGA or to the docking station. (Other dock users report similar behaviour). I'm being fairly liberal with update calls here, probably just doing it in enableOutput will work as well -- but I haven't extensively tested it. I don't know how expensive these calls are. On boot, my setup is still not restored, but at least with this patch manually enabling an output works reliably now. Test Plan: * rebooted with dock disconnected, can enable an output with this patch, would reliably fail without * rebooted with dock connected, still works * connected/disconnected/connected dock with output attached, works well Reviewers: dvratil, graesslin Reviewed By: graesslin Subscribers: graesslin, plasma-devel, #plasma Tags: #plasma Differential Revision: https://phabricator.kde.org/D2336 M +1 -0 backends/xrandr/xrandrconfig.cpp M +2 -0 backends/xrandr/xrandrcrtc.cpp http://commits.kde.org/libkscreen/c2e1becccec9a2cccc80701535733c784f318e5d
Would be nice if you could re-test once Neon has Plasma 5.7.4 (or use the dev edition, which should have this fix by tomorrow).
Git commit 5ad4370cce960c5b5192a47169b353ed94414815 by Sebastian Kügler. Committed on 02/08/2016 at 13:49. Pushed by sebas into branch 'Plasma/5.7'. update CRTCs before enabling an output Summary: When connecting the docking station (Lenovo OneLink+), which has a VGA connected monitor attached, enabling a display usually fails. It complains about no CRTC being available (and indeed the available CRTCs don't have our output as possible output). Updating the CRTC before enabling an output makes this work for me. Note: it's not a problem when connecting via HDMI, this seems to be either unique to VGA or to the docking station. (Other dock users report similar behaviour). I'm being fairly liberal with update calls here, probably just doing it in enableOutput will work as well -- but I haven't extensively tested it. I don't know how expensive these calls are. On boot, my setup is still not restored, but at least with this patch manually enabling an output works reliably now. FIXED-IN:5.7.4 Test Plan: * rebooted with dock disconnected, can enable an output with this patch, would reliably fail without * rebooted with dock connected, still works * connected/disconnected/connected dock with output attached, works well Reviewers: dvratil, graesslin Reviewed By: graesslin Subscribers: graesslin, plasma-devel, #plasma Tags: #plasma Differential Revision: https://phabricator.kde.org/D2336 M +1 -0 backends/xrandr/xrandrconfig.cpp M +2 -0 backends/xrandr/xrandrcrtc.cpp http://commits.kde.org/libkscreen/5ad4370cce960c5b5192a47169b353ed94414815
Created attachment 100415 [details] attachment-27652-0.html I'd be happy to test the dev edition. Just to verify tomorrow's (GMT+3) build will have it? On 2 August 2016 at 16:51, Sebastian Kügler via KDE Bugzilla < bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=366346 > > --- Comment #4 from Sebastian Kügler <sebas@kde.org> --- > Would be nice if you could re-test once Neon has Plasma 5.7.4 (or use the > dev > edition, which should have this fix by tomorrow). > > -- > You are receiving this mail because: > You reported the bug. >
Just tried neon-devedition-gitstable-20160806-1047-amd64.iso The problem is still there unfortunately. Tested setup: 1. Lenovo UltraDock with VGA and Display Port (-> HDMI) 1080p displays attached to it. 2. Lenovo t460s laptop, BIOS 1.13. Symptoms: 1. Upon first docking, the external displays recognized, but with unknown resolution (small boxed). Enabling displays makes KDE to recognize the resolution and displays light up. 2. Undocking and docking back, does not bring up the displays. Opening display settings shows that only one display was recognized, but disabled. (doesn't have recognized resolution). 3. After several, usually 3 or so, Plug/Enable displays/Unplug cycles screen becomes garbled.
Could you delete ~/.local/share/kscreen/kscreen.log, then reproduce the issue, and then attach said kscreen.log to this bugreport? Thanks!
Created attachment 100490 [details] kscreen config 1
Created attachment 100491 [details] kscreen config 2
Created attachment 100492 [details] xsession-errors
Created attachment 100493 [details] resolution-less screens
I don't have such file. After rerunning test, attached are .xsession-errors, configuration files from ~/.local/share/kscreen, and screenshots of resolution-less displays screen config.
Which version of libkscreen are you testing exactly? (On debian-like systems, dpkg -l|grep libkscreen should give you a hint.)
Ah, I see. You have to test with the neon Git unstable developer edition. This bug is not fixed in the stable branches.
Created attachment 100494 [details] kscreen.log
OK, tested with the latest gitunstable. Exactly the same behaviour. Attached is kscreen.log.
I sunny see in the log where you are enabling one of the dysfunctional displays. The log seems consistent.
"don't", sorry.
Created attachment 100496 [details] attachment-8307-0.html Oh, I thought you want to see how these displays are detected when I plug into docking. The exact flow was: 1. Plug into docking after boot. 2. Displays are detected with proper sizes, but are disabled. Enable them. 3. Unplug from docking. 4. Wait for displays to disappear from screen config tool. 5. Move kscreen.log aside 6. Plug into docking - displays are a detected, but shown small with unknown resolution (as in my previous screenshot) At this point I've grabbed the new kscreen.log and posted it. Enabling displays later on was unsuccessful - configuration utility showed error dialog saying something like "Can not apply your screen configuration due to incorrect resolution" (Don't remember the exact wording and I'm not near the computer right now). I'll retest tomorrow and will send you the updated log file. P.S. The last line in the current log is saying QSize(-1, -1). Is this normal? Shouldn't KDE recognize the size properly even-though the screen is disabled? On 8 August 2016 at 19:16, Sebastian Kügler via KDE Bugzilla < bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=366346 > > --- Comment #19 from Sebastian Kügler <sebas@kde.org> --- > "don't", sorry. > > -- > You are receiving this mail because: > You reported the bug. >
Thanks a lot for the detailed information, it's very useful. Interestingly, the clue is in the log lines that are missing in your kscreen.log. :) The kscreen daemon (kded module) loads a list of outputs on startup and starts watching these for the Output::isConnectedChanged signal. What's happening when you plug in the dock after the session was started (and these outputs initialized) is that new output "connectors" appear -- these are initially disconnected. Then a configChanged signal arrives, and kscreen saves the config -- with disabled outputs. This means the configuration from this point won't work anymore until you manually enable the output again. You can check which outputs are known at all, and which are connected easily with "kscreen-doctor -o" (kscreen-doctor is a small debugging/testing tool I've been working on lately.) I can reproduce this behaviour on my laptop when plugging in a Lenovo Onelink+ docking station. Completely new outputs appear when the docking station is plugged in. The fix is pretty simple: we hook up Config::outputAdded as well, and make apply a known configuration (this was exactly what was omitted in case the docking station appears after startup). I've posted this fix for review on phabricator: https://phabricator.kde.org/D2374 . Once this (or a variation of it) is merged, it would be cool if you could give it another try and see if the change fixes the problem for you.
Created attachment 100508 [details] attachment-32278-0.html Great. I'll watch this bug for updates and test the fix properly. Many thanks for making Plasma better. On 9 August 2016 at 04:15, Sebastian Kügler via KDE Bugzilla < bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=366346 > > Sebastian Kügler <sebas@kde.org> changed: > > What |Removed |Added > ------------------------------------------------------------ > ---------------- > Version|5.7.2 |git > Keywords| |multiscreen > > --- Comment #21 from Sebastian Kügler <sebas@kde.org> --- > Thanks a lot for the detailed information, it's very useful. > Interestingly, the > clue is in the log lines that are missing in your kscreen.log. :) > > The kscreen daemon (kded module) loads a list of outputs on startup and > starts > watching these for the Output::isConnectedChanged signal. > > What's happening when you plug in the dock after the session was started > (and > these outputs initialized) is that new output "connectors" appear -- these > are > initially disconnected. Then a configChanged signal arrives, and kscreen > saves > the config -- with disabled outputs. This means the configuration from this > point won't work anymore until you manually enable the output again. > > You can check which outputs are known at all, and which are connected > easily > with "kscreen-doctor -o" (kscreen-doctor is a small debugging/testing tool > I've > been working on lately.) > > I can reproduce this behaviour on my laptop when plugging in a Lenovo > Onelink+ > docking station. Completely new outputs appear when the docking station is > plugged in. > > The fix is pretty simple: we hook up Config::outputAdded as well, and make > apply a known configuration (this was exactly what was omitted in case the > docking station appears after startup). > > I've posted this fix for review on phabricator: > https://phabricator.kde.org/D2374 . > > Once this (or a variation of it) is merged, it would be cool if you could > give > it another try and see if the change fixes the problem for you. > > -- > You are receiving this mail because: > You reported the bug. >
Git commit 68423ccdf3f89e4bbaa53117aff067471455c0a3 by Sebastian Kügler. Committed on 09/08/2016 at 12:20. Pushed by sebas into branch 'master'. [kded] fix monitoring for newly appearing outputs Summary: This patch makes the kded daemon monitor also newly connected outputs, and leads to correctly initialize outputs from a docking station plugged in after session start. For "internal" display connector ports (HDMI, DisplayPort, etc. integrated in the system, we know from the start that they exist. These are marked disconnected. When plugging in a docking station, new outputs (that aren't previously known as disconnected) appear. daemon.cpp only monitors outputs that change connection state, so it doesn't consider newly added outputs. By listening to KScreen::Config::outputAdded, we can detect new output (connectors) as well, so we can trigger the applyConfig code path, which leads to restoring the config. Test Plan: * Reproduced the issue in https://bugs.kde.org/show_bug.cgi?id=366346 and confirmed it fixes the problem on my system (Lenovo Onelink+ docking station which shows the same behaviour). * Added debug calls and confirmed the new outputs are correctly set up. auto-testing this seems to be close to impossible. :/ Reviewers: #plasma, davidedmundson, graesslin Reviewed By: #plasma, davidedmundson, graesslin Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D2374 M +10 -0 kded/daemon.cpp http://commits.kde.org/kscreen/68423ccdf3f89e4bbaa53117aff067471455c0a3
Patch is in master now, and devunstable packages have been built. The next neon gitunstable image will have this change included.
Tested on neon-devedition-gitunstable-20160810-0806-amd64.iso There is a good progress, but it's still not perfect. When replugging, displays are recognized and lit up, but one of them has wrong resolution. After going to screen settings, I'm able to set the right resolution and it works, but after another unplug/plug cycle, the resolution is not recognized properly once again. The exact flow: 1. Plug into docking after boot. 2. Displays are detected with proper sizes and ARE ENABLED automatically (in previous version they were not) 3. Unplug from docking. 4. Wait for displays to disappear from screen config tool. 5. Grab kscreen.log.before-plug 6. Plug into docking - displays are detected and enabled (lit up). However the one that is connected through DP->HDMI cable is configured with wrong (smaller) resolution. Grab kscreen.log.after-plug-wrong-resolution Again, adjusting resolution after step 6 through config tool fixed it, but step 6 reproduces through another unplug/plug cycle.
Created attachment 100549 [details] kscreen.log.after-plug-wrong-resolution
Created attachment 100550 [details] kscreen.log.before-plug
Could you give me the output of the following commands: kscreen-doctor -j kscreen-console bug xrandr -q and the files in ~/.local/share/kscreen/* There's something weird going on with the resolution, I have some questions: - You have two displays connected, next to your laptop screen? - Are both connected to the docking station? - Are these identical displays? If you could test this with the latest available dev/unstable image, that would be useful. There were some vaguely related changes which might not have made it into the above tested image.
Setting to waitingforinfo until it's tested with the latest changes.
Tested on Neon unstable release from Aug 21. The screens resolution is detected properly now - verified on two slightly different docking setups. The only issue, though not sure if it's related, is with visual positioning of screens in kscreen UI - after re-plug, the second screen always jumps to the top. Note that his is only a visual representation issue - the actual desktop is positioned just fine, i.e. if I pass mouse cursor from left to right, it passes all of the three screens on the same height. See the before/after screenshots. Many thanks for fixing this! These changes will make it only to Plasma 5.8, right? P.S. I've sent you email with couple of questions on the future of HIDPI in KDE couple of weeks ago - chances are it got to spam. I'll truly appreciate if you'll have a look.
Created attachment 100708 [details] kscreen-ui-before.png
Created attachment 100709 [details] kscreen-ui-after.png
Hai, thanks for testing and confirming it's fixed. I've seen your email and started replying, but got interrupted and haven't picked it up again. I'll do so this week. As to the visual bug in systemsettings, I've fixed some glitches there, but the code is kind of convoluted and I don't want to poke too much in there in its current state. We're planning a redesign of that particular UI, so likely, any time spent on it now may well be wasted. I suggest we'll look into this level of problems once we got the new design implemented. Again thanks for your help in nailing down the problems.
Created attachment 100843 [details] attachment-3622-0.html Will this fix land into 5.8 only? No plans to backport to 5.7, right? On 22 August 2016 at 14:06, Sebastian Kügler via KDE Bugzilla < bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=366346 > > Sebastian Kügler <sebas@kde.org> changed: > > What |Removed |Added > ------------------------------------------------------------ > ---------------- > Status|NEEDSINFO |RESOLVED > > --- Comment #33 from Sebastian Kügler <sebas@kde.org> --- > Hai, thanks for testing and confirming it's fixed. > > I've seen your email and started replying, but got interrupted and haven't > picked it up again. I'll do so this week. > > As to the visual bug in systemsettings, I've fixed some glitches there, > but the > code is kind of convoluted and I don't want to poke too much in there in > its > current state. We're planning a redesign of that particular UI, so likely, > any > time spent on it now may well be wasted. I suggest we'll look into this > level > of problems once we got the new design implemented. > > Again thanks for your help in nailing down the problems. > > -- > You are receiving this mail because: > You reported the bug. >
Unfortunately not, there have been too many changes to test different patchset combinations, so I'm not taking the risk to backport. It's all 5.8 material.
I'm also seeing something similar with plasma-desktop 5.7.4 on Debian Sid with a Thinkpad X1 Carbon 4th Gen, a Thinkpad Onelink+ dock, and a few different DisplayPort displays plugged into the dock. KDE doesn't auto-enable the desktop display after the OneLink+ dock has been plugged in. Checking kscreen-doctor -o I see the port is still disabled with no listing of geometry. I have to either open up the display settings panel and enable it there (and yes it's listed there) or do something like xrandr --output DP-2-2 --auto --right-of eDP-1 to bring it up (and also yes, the display is listed under xrandr -q without any other tickling). When I unplug the OneLink+ dock, I can still move my mouse past the edge of my laptop screen and go into the part of the desktop that was created for the 2nd display. The display settings panel only shows the laptop display, and xrandr -q shows the port as being displayed but shows the last known geometry for that port. Doing an xrandr --output DP-2-2 --off will remove the ghost portion of the desktop. And yes I acknowledge the fixes listed here are being pushed out to 5.8. Just figured documenting my experiences might be good.