When using a laptop together with an external monitor/connector, a typical workflow involves 1) work work work 2) close lid 3) detach connectors (usb/powersupply/monitor) 4) do something else, move to another place 5) place laptop on desk, attach connectors (usb/powersupply/monitor) 6) open lid 7) work work work With this, the external monitor gets changed while the laptop is suspended. In KDE, kscreen completely misses this fact. The result is that at step 6) the presence of an external monitor different enough from the one used at point 3) or the fact that at 3) one has an external monitor and at 6) one has not or viceversa causes the system to be unusable or to crash. Kscreen should check the screen configuration when the system wakes up from sleep. Reproducible: Always
Note that whenever the system remains "usable enough" at 6) to perform some action, a workaround for the issue is to switch to a text console and to issue a killall kscreen_backend_launcher with this the kscreen backend is restarted and a subsequent visit to the systems settings lets one see the correct monitor setup (apart from the resolution that often remains messed, but that can be adjusted manually at this point). Unfortunately the killall of the kscreen_backend_launcher may cause the system settings process to segfault if it is already open.
most likely kscreen does not get any event from X-Server that the screen got (de)tached while the system was in suspend. To verify please run the tool xev from a konsole before going to suspend, do your screen (un)plugging and then after resume check in the xev output for RR* events. If there are any please paste them here. Note that xev might report many events given that it just intercepts all X11 events.
I have the same problem in Plasma 5.8.1. I attach the kscreen.log file. Is this enough or do you still need the xev output? What other information can I provide? In another bug this same problem was already discussed, and if I'm not wrong a developer said that kscreen would check the X configuration after the resume event (without waiting passively to be notified by X). Is that correct? Or if X doesn't notify there is no solution to this problem?
Created attachment 101732 [details] kscreen.log after resuming notebook in a different location
So the bug has got to 5.8.1. Sad to hear that, being on in ubuntuland that shall probably get to 5.8.1 in another 6 months. Looks like no one with kde uses laptops that dock to external monitors to realize that this is an issue ;-) On the bright side, I believe that /there should be a solution/ to this problem since plasma 4 was dealing with it just fine. For the time being, as a dirty hack I suggest just adding a script to systemd to assure that it kills the kscreen_backend_laucher on suspend/resume. Can the bug be marked as confirmed?
Here is a clue on what may be the cause of the problem: it seems that one monitor at home is named as one monitor at work, so when I wake from suspend, kscreen doesn't notice the difference. HOME: eDP1, DP1-2 WORK: eDP1, DP1-1, DP1-2 From docked at HOME > Suspend notebook > Dock at WORK > Wake it up > Wrong config In detail what happens is that the notebook screen (eDP1) is activated correctly, DP1-1 is not activated and DP1-2 is activated with a wrong resolution (the panel is on it, and it shouldn't), so DP1-2 at WORK is treated as if it's the DP1-2 at home. Moreover after waking up the notebook, none of the files in ~/.local/share/kscreen are touched and kscreen.log is not written, so it seems that kscreen doesn't perform any action at all. I attach the kscreen configuration for the HOME and WORK configuration. ----- EXTRA INFO PROBABLY IRRELEVANT ---- Working configuration: From undocked > Suspend notebook > Dock at HOME > Wake it up > OK From docked at HOME > Suspend notebook > Undock> Wake it up > OK From undocked > Suspend notebook > Dock at WORK > Wake it up > OK From docked at WORK > Suspend notebook > Undock> Wake it up > OK
Created attachment 101767 [details] Kscreen configuration HOME
Created attachment 101768 [details] Kscreen configuration WORK
The kscreen.log in comment #4 is probably irrelevant, refer to the info in comment #6 which refer to a more accurate test. @Sergio Can you please verify if you have a similar situation, where two screens in different location are named the same way? So we can try to narrow down the problem.
Created attachment 101769 [details] Kscreen configuration WORK (Correct version) This is the correct version of my WORK configuration: eDP1: Notebook screen DP1-1: DELL U2412M DP1-2: HP LA2205wg
I need to make a correction (still the considerations in comment #6 are still valid): Attachment 101767 [details] is my correct HOME configuration: DP1: Notebook screen DP1-2: Dell U2414H Attachment 101769 [details] is my correct WORK configuration: eDP1: Notebook screen DP1-1: DELL U2412M DP1-2: HP LA2205wg Attachment 101768 [details] is a WRONG configuration created by KScreen (the two DELL monitors have never been in the same place!) eDP1: Notebook screen DP1-1: DELL U2412M (my DELL screen at work) DP1-2: DELL U2414H (my DELL screen at home) Also notice that I purged all the configuration after upgrading to KDE/Plasma 5.8.1, so all the configuration have been created by that version of KScreen. I hope I have provided enough (but not too much) information, and that they are clear enough. Otherwise please ask me clarification, I really hope we can fix this bug.
I've noticed that the two problematic monitors have the same identifiers also in .config/monitors.xml. So this bug seems generated by X bad naming. Also it seems that X remembers all the monitors ever connected. How is it possible to rename/forget one of them?
@Simone > can you please verify if you have a similar situation, where two screens in different location are named the same way? This is obscure to me. They have obviously the same "name" like DP1-1, HDMI2, etc. This "name" depends on the /connection/ of the monitor. E.g. on my system anything that is connected to the hdmi port gets named HDMI2! It does not matter if I connect to the hdmi port the monitor that I have at home or the monitor that I have at work. The point is that this is not the sole information that kscreen gets. If you go to the screen setup in KDE, you'll notice that kscreen can read the /brand/ and /model/ of the screens attached to it. In fact, it can read an identifier for each external monitor (I think via edid). This is the item used to store/recover the screen setup for every possible monitor combination. And in fact, when you do not put a suspend/resume cycle in between, it works just fine: e.g. This works fine At home -> detach monitor -> suspend -> go to work -> resume -> attach monitor This does not work At home -> suspend -> detach monitor -> go to work -> attach monitor -> resume
Bit confused now, but could you get me the kscreen.log after a startup when things went wrong? (And tell me what it should have been.) The config files in ~/.local/share/kscreen/* would also be useful. Background: a configuration is unique if both, connector name and edid information produce the same hash, the connector name alone can be the same, and kscreen will still make sense of it.
What I see does in fact seem consistent with your last comment. As soon as I am in a place where I have external screens to swap, I'll collect the logs and send them to you. My feeling is that what is going on is something following these lines: * The kscreen db has 3 "configurations" stored: - Laptop screen only: connector eDP1 edid "foo" - Laptop screen with Samsung full HD monitor: eDP1 + "foo" and HDMI2 + "bar" - Laptop screen with DELL monitor (lower res): eDP1 + "foo" and HDMI2 + "baz" Suppose that I am working with the setup with the external Samsung monitor. If I: - detach the monitor, kscreen correctly moves to the configuration with the laptop screen only. - then suspend and restore the laptop, the laptop resumes with the laptop screen configuration. - now attach the dell monitor, kscreen correctly sees the new monitor and reads its edid, understands it needs to move to the config for the dell monitor. So far so good. Conversely if I: suspend the laptop, detach the external samsung monitor, attach the dell monitor, resume, then kscreen sees that I still have an external monitor attached, but keeps seeing the edid from the Samsung monitor and so does not see a new coniguration hash and does not understand that it needs to switch to the "dell" config. This seems confirmed by the fact that the kde setup screen dialog shows the Samsung model number for the external monitor. At this point, even if I detach and reattach the external monitor, kscreen seems to not re-querying the edid. The only way to have it understand that I have the dell monitor is killing kscreen_backend_launcher, that gets immediately respawn. Unfortunately, if I do so, at this point kscreen updates its database, writing in it that the default resolution to use with the dell monitor is the current one, that unfortunately is still the resolution of the Samsung monitor (too high).
Good detective work. I'll run over this theory with my debugger hat on.
I confirm the behaviour described in comment 15. I'm experiencing exactly the same. Sergio explained it in a much more clear way than me.
This bug got worse since a month or two, because now it happens even with the following sequence of operations (that was working fine before): At home -> detach monitor -> suspend -> go to work -> resume -> attach monitor So basically I need to reboot every time I go from work to home and viceversa. Is it there a way to restart kscreen without exiting the session of KDE? I don't have the process kscreen_backend_launcher suggested by @Sergio.
If you're running on X11 and you don't have that process, that will cause the issue. Can you check if it crashes, or is perhaps not or wrongly installed? It could be an integration issue.
Ok. So I tried again today and I can find the process /usr/lib/kf5/kscreen_backend_launcher, so yesterday probably it crashed. Case 1: In any case now I've tried this: - Undock from work - kill /usr/lib/kf5/kscreen_backend_launcher - Remove all the kscreen bad configurations - Run /usr/lib/kf5/kscreen_backend_launcher - Dock the notebook at home A this point the external monitor is not activated Case 2: If I do instead - Undock from work - Suspend - Unsuspend - Dock the notebook at home the external monitor is activated but a bad configuration is generated. If I do Case 1 with system settings 'display' dialog open, the notebook screen become messed up and I cannot interact with anything.
Is it there any progress on this bug?
Issue is still present on kubuntu 17.04 with the KDE PPA, that is Framework 5.35.0 QT 5.7.1 Plasma 5.10.2
Bug still present as of framework 5.37 QT 5.7.1 plasma 5.10.5
At this point, almost two years after the original report and many proud articles such as https://lwn.net/Articles/694157/ all the issues are still there. If you have a laptop, and you attach it to an external screen, then close the lid and suspend the laptop, then detach the connectors, when you eventually attach an external screen again, kscreen ends up thinking that you re-attached the former monitor. This is quite evident as the UI with the Display and Monitor Settings *name* the monitor and you get the former name. For instance if you were initially attached to a Samsung monitor, you suspend the laptop, detach the connector, work with your laptop, then one day attach a Dell monitor, kscreen identifies it as Samsung and applies the settings for the Samsung monitor. This is very bad. On some occasions with the external monitor you have the laptop screen disabled. Then, one day you need to give a presentation, you attach the projector, kscreen thinks it is the external monitor, switches off your laptop display and provides to the projector some resolution that it can't support. Et voilà, you are with no working screen at all in front of your audience. So, at this point the question is: is there a way to run plasma without the full kscreen support? I.e. only having the minimal assurance that when an external monitor is detached the display permanently goes back to the main laptop screen, with kscreen not trying to (incorrectly) guess how it should configure the screens?
You can disable the kscreen background service and it won't do any automatic configuration or reconfiguration, then you can use xrandr by hand. I may also note that, while in your situation, nothing may have changed, we have *numerous* reports that for many users, the situation has improved and kscreen just works. That's not really helping you, but your view on the situation is limited it seems, and as a result of that, you're treating developers unfairly.
Hi, thanks for your suggestion. As a matter of fact, what I would like to do is being able to configure the screen graphically, having the system making only the safe choice of re-enabling the laptop screen when the external monitor is detached, without making automatic choices based on a wrong understanding of what external monitor is attached (as it was in the KDE 3 and 4 times). I understand that the kscreen situation has improved for many users. In some sense, it has for me too: for instance, I am now able to use the GUI to unify the screens, something that I was not able to to until a few months ago. I am also *sorry if some felt treated unfairly by my previous comment* and I would like to apologize. At the same time I also would like to make this point: I may belong to a minority of users who (i) have a laptop, (ii) prefer to use it attached to an external monitor and keyboard when possible, and (iii) happens to give lectures and presentations with the laptop attached to a projector which may make my issue less evident than others. Still, (a) it is a serious issue because it may happen to leave all your screens black; (b) it is a regression with respect to Plasma 4 and it is still there more than 3 years after the release of plasma 5 and at the 11 major versions of the project. Let me detail why my limited view may propagate to hundreds of people in a second. When you want to do a presentation in front of a big audience, you attach the projector and *all* your screens turn black. What do you do at this point? The only way I have found to get out of this without a reboot is: 1. detach the projector and get the image back on the laptop 2. kill kscreen_backend_launcher 3. prepare a line on the konsole saying 'xrandr --output HDMI2 --auto` without pressing enter 4. reattach the projector. As the laptop screen goes black, press enter, to exec the previous command line. Get some image on the projector 5. open the system settings on the projector screen, go to display and monitor, re-enable the laptop screen too and make it primary, so that the kde menu is back on it. (note that at 3-4 you cannot merely prepare the xrandr line to switch on the laptop screen, as kscreen may want the kde menu and taskbar to be on the external screen). All this is a bit cumbersome, non-intuitive and would be prohibitive hard to many (points 3 and 4 more than the others). Most important, in front of an audience, it ridicules you for your choice of Linux. The audience won't likely be able to understand what is going on and will merely think that Linux and KDE are poor choices. Which is also a bit unfair to all the other Linux and KDE developers. Unfortunately, this bug is not a "private" bug that sits just on your screen. This bug is a bug that typically gets projected to an audience. In some occasions, this happens while you may be trying to promote something you have developed for Linux. Also please see that having celebrative articles about kscreen before regression s like this are solved may appear weird.
Dear Sebastian, I think no one here wants to blame you of anything. I know that the resources in terms of people and time are limited and some bugs may be particularly nasty to solve or have low priority compared to others. Nonetheless I understand the frustration of Sergio, given that I suffer from the same bug. Everyday when I arrive at work I have to reboot the system and again when I go home at evening, thus disrupting my "working setup" of open windows and applications. I agree that the multi-screen situation improved for many, which from your point of view is good, but from our point of view nothing changed in these years and we face this every day. After Sergio did an excellent job in providing as much as debug info as possible your last message regarding the bug has been posted one year ago and it was "Good detective work. I'll run over this theory with my debugger hat on." I hoped in an update at some point but I heard nothing in a year. What I would like to know is: Have you ever tried to debug this? What else can we do to help to solve this? Should stop hoping this will be solved? I love so much KDE that I do not want to give up on this and at some point I would like to debug myself this problem, but I know that it is going to take a lot of time for me to understand the code given that I know nothing about xorg or screen management. Again, I am not criticizing you in any way and I can only thank you for your excellent job.
I just want to add that with Plasma 5.12 in a Wayland session this will all work 100 % correct. So if this is an issue to you, I highly suggest to switch to Wayland starting with 5.12. Even in 5.11 right now the situation you describe is impossible to hit, but screen management overall is still limited and properly not suited for you.
I have tried to switch to wayland multiple times for this exact reason but I always found it unusable. The last time I've tried it with plasma 5.11 was fairly decent but there is still bug #372789 that makes wayland a no-go.
As I have no experience at all with Wayland (either on the reference composer or on kwin), I'd like to take the occasion to ask a few questions on it. I have read that some forms of network operation are now available with wayland, but supported at the composer level. Will kwin support something like that in 5.12? Will something roughly equivalent to using xpra with X11 be available (namely delivering a single app remotely)?
Seems OK or at least very much improved now!!! I'll do some more checking and report. In the meanwhile, thanks for having worked on this.
No, unfortunately it was just a couple of lucky cases. Still I have situations in which I attach an external monitor and kscreen thinks it is the same monitor that was attached in some previous occasion until you manually kill kscreen_backend_launcher. For instance, right now I have a Samsung monitor attached, but kscreen thinks it is a Dell one. Even detaching and reattaching the monitor does not change this perception. I hoped that the "Clear EDID data when monitor is disconnected from an output." fix in libkscreen with plasma 5.11.4 could have helped, but no (or not always).
Do you see the improvements on X or wayland?
I work uniquely in X because single window network operation with xpra is essential in our setup.
Hi, I've just registered only for connect to this topic. It still exists since 3-4 years in my environment too (a notebook, what I every day connect to a docking station at work, and use it at home without docking station). I'm a KDE (Kubuntu) fan, I try to solve this problem time by time (in every half year I spend a half day with it) - but nothing (same wrong behavior in all version)... When I dock the notebook, what is not turned on, and later turn on, the monitor setting confused. (So I every day have to turn on (or wake up) my notebook, and after it have to connect to the docking station - that works, but I hate it..) So the problem exists, the multiple monitor handling in KDE not stable enough. I'm sure we are lot more than this several user, who took the tiredness and wrote a message here and trying to push the topic to be solved...
In KScreen 5.11.5 (maybe also in previous versions) the situation is slightly improved for me. If I wakeup the notebook before docking it, once I dock it the correct configuration is applied. Before, even doing this was loading the configuration of the first docking station see after boot.
As Simone Gaiarin said in comment 34, in KScreen 5.11.5 the situation was improved. However, in plasmashell 5.13.2 the only way I have found to dock and undock is to do it while logged into plasma. If I dock or undock while at the sddm screen or while suspended, kscreen will not restore a proper screen configuration. Sometimes things become so bad that a forced restart is required.
Thank you for the bug report. Unfortunately we were not able to get to it yet. Can we ask you to please check if this is still an issue with Plasma 5.25 or 5.26? If it is, please change the status to CONFIRMED when replying. If not, or if you can't because you no longer use this setup, you can change the status to RESOLVED WORKSFORME. 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!