My multi monitor configuration is reset to the default configuration after every reboot, meaning I must fix the configuration every time. Reproducible: Always Steps to Reproduce: 1. Change multi monitor configuration 2. Reboot 3. Monitor config is wrong Actual Results: The monitor configuration resets to the default Expected Results: The monitor config stays the same. I am using an Nvidia graphics card.
Setting monitor using nvidia configuration module solves the problem
Same for me, on arch, plasma 5.3. Also a Nvidia card, I don't know if this is the cause.
It's been a bit more complicated for me, as kscreen insisted on 'messing up' my configuration (I think it is kscreen). I had to set the xorg.conf using nvidia settings, but I also had to do a 'qdbus org.kde.kded5 /kded org.kde.kded5.setModuleAutoloading kscreen false' to disable kscreen. If any testing is needed, I'll enable it back, of course.
Could you please back up all files from ~/.local/share/kscreen, delete them, try to configure your screens again with KScreen and see if that will persist across reboots? Logging out and back in should be enough btw. If it works please provide archives with the backed-up files and with the newly created files.
Created attachment 92465 [details] Working configuration
Created attachment 92466 [details] One old config
Created attachment 92467 [details] Other old config
Now, I don't know what those old screen configurations are, the last time i changed the screen config I did it through the Nvidia settings, and the config in kscreen looked all messed up and wasnt right at all, but the actual configuration worked fine, and was how I had it set up in Nvidia-settings.
I'm having this problem with nouveau. Deleting the kscreen config does not help. Screens are of the same make and model.
Found a workaround: What do work is removing kscreen and setting up xorg.conf like this (change the settings to fit your setup, running xrandr gives some clues): https://wiki.archlinux.org/index.php/Nouveau#Dual_Head
I'm also loosing the configuration when the notebook is undocked and docked again. In KDE4 with KScreen 2 I've found that the cause was that KScreen saved the refresh rate of the monitor with a bad approximation like "Refresh: 60.3453948" so that when the notebook were docked again it thinks it was a different configuration of monitors. Editing manually the refresh rate in the config file and set it to 60 solved the problem. In Plasma 5.2 the workaround doesn't seem to work anymore.
(In reply to Simone Gaiarin from comment #11) > I'm also loosing the configuration when the notebook is undocked and docked > again. > > In KDE4 with KScreen 2 I've found that the cause was that KScreen saved the > refresh rate of the monitor with a bad approximation like "Refresh: > 60.3453948" so that when the notebook were docked again it thinks it was a > different configuration of monitors. > Editing manually the refresh rate in the config file and set it to 60 solved > the problem. > > In Plasma 5.2 the workaround doesn't seem to work anymore. I too did see different refreshrates in different places, kscreen says 60.0 in System Settings > Display Configuration, but logs 59.9543, xrandr says 59.95. Here is what systemsettings logs while setting the output: systemsettings5 kf5.kservice.sycoca: Trying to open ksycoca from "/home/.cache/ksycoca5" LOAD kscreen: launcherDataAvailable: "org.kde.KScreen.Backend.XRandR" kscreen: Launcher finished with exit code 1 , status 0 kscreen: Service for requested backend already running Activate output 97 Activate output 98 Saving "DVI-I-1" 97 KScreen::Output(0x14a2c70) Connected: true Enabled: true Primary: false Rotation: 1 Mode: "" @ 59.9543 Hz Position: 0 x 0 "DVI-I-2" 98 KScreen::Output(0x14be730) Connected: true Enabled: true Primary: false Rotation: 1 Mode: "" @ 59.9543 Hz Position: 1680 x 0 kscreen: Requesting missing EDID for outputs (97, 98) kscreen: Requesting missing EDID for outputs (97, 98) Might the part about missing EDID info be related to this bug? I remember there was talk about it earlier as this is an old problem.
Hi, I have exactly the same problem with an Intel chipset (i915 driver on Fedora 22 - no problem with F21/KDE 4). Can't undock my laptop without messing up everything and have to painfully reconfigure.
*** Bug 346499 has been marked as a duplicate of this bug. ***
I am also seeing problems when changing monitor configuration (e.g. plugging in a second monitor into the laptop VGA port) - it does not seem to reset correctly and I often loose the shell taskbar (possibly because the monitor was configured as primary). This is on my Lenovo W541 laptop with Fedora 22.
Same problem here. Workaround making ~/.local/share/kscreen/<random named file> read-only
I am having the same issue with both my desktops. One is running and AMD GPU the other is NVIDIA. Both on the non-free driver. Same issue. Does not happen with every restart seems to be linked to a new calendar day for me.
Making the file ~/.local/share/kscreen/<hex code> has no effect. I still get 1680x1050 cloned screen. Making SDDM use the correct sizes before KDE starts has no effect. BUT Because I have made the <hex code> file read only I can at least log out and back in again. Only then it will actually acknowlege the existance of the configuration file, read it and not mess up the screen geometry. Screens are: HDMI-2 connected 1920x1080+0+0 DVI-0 connected primary 1680x1050+1920+0
I am also having this trouble. When rebooting sometimes (not sure if always), I log in, and it is just duplicating the image across both desktops. I made the suggested file read only. And so it appears that if I then log out and log back in again, it uses the correct layout. So perhaps it is ignoring the configuration file upon first logging in after reboot?
I updated to plasma-desktop 5.4.1 and kscreen 5.4.1 and it seemed to have fixed the issue.
5.4.1 fixed it on my Nvidia box, its still not working on my AMD box.
I am having similar issues here. Configuration is Fedora 23 KDE spin, plasma 5.4.3, NVidia controller, nouveau driver, 2 displays stacked vertically, "primary" screen is on the bottom. On boot the displays will generally not be set up the way they were left and saved (from the Display and Monitor settings). After reading a number of posts on these issues I have helped the problem a bit. I have manually edited /.local/share/kscreen/(hex number) to match my configuration and then set it read-only. This helped stabilize which screen it thinks is the primary. (I have noticed the system has added another file with "default" values and only 1 monitor. Not sure where that came from or why.) The next problem was that the panels, both the default and the extra one I created, would relocate from one screen to another following a reboot. Initially I was able to make multiple changes to the settings with the System Settings / Display and Monitor tool, but after a recent update that stopped working and will often just lead to a messed up display. So I manually edited .config/plasma-org.kde.plasma.desktop-appletsrc to reflect my desired configuration, then made it read-only as well. Now I sometimes get the correct display settings on boot, but if I log out and back in they will be correct. As a side note, I was previously testing F22 / plasma 5 with the nvidia drivers, and it was working just fine until about a month back when an update hit and ruined everything. So I started over with F23 and the basic nouveau driver, and it has been the same mess since. Obviously they broke something within the last month. Thankfully my F21 / KDE 4.x is still working perfectly!
I can confirm that this problem affects the first login -- if I log out and log back in, kscreen picks up my previous settings. (Some of my widgets get all jumbled up though -- this is probably related to the fact that the first login messes up screen geometry?) It may have happened rarely that the settings were right on a first login, I'm not quite sure. In any case, this looks like a race condition as different KDE services get initialized, right? And I have integrated graphics from Intel, so it doesn't seem to be specific to a particular vendor or driver.
I see similar problems (but not exactly the same as the others) with my set-up: Fedora 22, Intel graphics on motherboard, primary monitor using DVI and secondary monitor using VGA. Have set a different "wallpaper" graphic for each monitor. Works fine after initial set-up using System Settings/Display Configuration. However almost always after reboot and sometimes after just logout and back in, the wallpaper for the secondary monitor covers the primary monitor's wallpaper and the background for the secondary monitor is black (blank). However, except for no response to right-click on desktop on the secondary monitor, the secondary monitor is still working and showing programs. Also, on primary monitor, widgets there are covered by the secondary monitor's wallpaper and can't be accessed, but right click still works on primary. Usually a quick logout and back in fixes the problem, but not always. The most reliable solution is run the Display Configuration again and click the box to disable the secondary monitor and then apply. Then re-enable it and apply again. This always has fixed it. This seems to kill and restart plasmashell since a notification box pops up which I just dismiss but wallpapers are in the proper place and both monitors function correctly again after that. I tried making the VGA monitor primary and also set the frequencies in Advanced Setting to explicit values instead of auto but these didn't make a difference. Didn't try tweaking any config files.
The most reliable solution at this moment is to create an .sh script like this: $ cat ~/bin/display.sh #!/bin/bash xrandr --output HDMI1 --primary --auto --pos 0x265 --output VGA1 --auto --rotation left --pos 1920x0 And place it to autostart.
OK, a status update: in my case, purging `~/.config` (and `~/.kde` for good measure, but I think the catch was in the former) resolved the issue. It's been several reboots since and I'm getting hopeful. I had briefly used both KDE4 and Gnome on this box before settling on KDE5, which suggests that the problem (or at least my version of it) is either related to switching from KDE4 or just hotswapping DEs in general. The easiest way to verify whether that's your case too is to create a fresh user, reboot and log in with this new user. I've only copied over specific application-related files from the old config folders and put the new ones under version control, so should the issue once again rear its ugly head, I'll investigate and report back :) Conspicuously missing from the new `.config` directory is `monitors.xml` which I know is used by Unity and probably Gnome too to determine monitor setup. But if KDE just ignores it, I'm not quite sure how it could mess up its startup.
(In reply to Dmitry from comment #25) > The most reliable solution at this moment is to create an .sh script like > this: > $ cat ~/bin/display.sh > #!/bin/bash > xrandr --output HDMI1 --primary --auto --pos 0x265 --output VGA1 --auto > --rotation left --pos 1920x0 > And place it to autostart. Thanks. Putting this in autostart does seem to "fix" the problem. After restarting several times over a few days I haven't had a problem with both monitors coming up correctly.
(In reply to gene smith from comment #27) > (In reply to Dmitry from comment #25) > > The most reliable solution at this moment is to create an .sh script like > > this: > > $ cat ~/bin/display.sh > > #!/bin/bash > > xrandr --output HDMI1 --primary --auto --pos 0x265 --output VGA1 --auto > > --rotation left --pos 1920x0 > > And place it to autostart. > > Thanks. Putting this in autostart does seem to "fix" the problem. After > restarting several times over a few days I haven't had a problem with both > monitors coming up correctly. Well, guess I spoke too soon. Today the problem happened again on KDE startup. Will try it set to run script on "Pre-KDE startup" for a while and see if that makes a difference.
(In reply to gene smith from comment #28) > Well, guess I spoke too soon. Today the problem happened again on KDE > startup. Will try it set to run script on "Pre-KDE startup" for a while and > see if that makes a difference. You'right it should start as soon as possible. Also it's better to disable kscreen daemon in kde system settings / startup / services.
I'm affected by this bug as well, KDE 5.4.2 on (k)Ubunto 15.10. I also see this error in .xsession-errors: kscreen: Requesting missing EDID for outputs (67, 592) If I try to enable the second dislay in System Settings, click the "Enabled" checkbox and then "Apply", KDE disables the checkbox again.
*** Bug 350132 has been marked as a duplicate of this bug. ***
100% reproducible using kscreen-5.5.3-1.fc23.x86_64 on KF5 5.18. Is there any debug info we can provide to have this problem more precisely identified?
I have the same problem as Gene in comment #24: After updating Kubuntu Backports today (to KDE 5.5.3) I have: - my normal screen on the left - black screen on the right - cannot right click on the right screen - I was able to move a task bar to the right screen, coming from the left - I always had the task bar only show the applications on it's own screen, this doesn't seem to work any more. I looks like the applications don't know on which screen they are. Turning off this filter on both the left and right task bar shows all applications on both bars. - on the right screen I cannot add any other widgets (cannot right click, also there is not the little icon on the top left, also can not create on the left screen and then move to the right as it blocks at the screen edge) This is a regression of course.
I tried the script above and with kscreen2 disabled. That didn't work well as I have 2 1920x1200 monitors and both monitors showed the same thing, except vertically displayed on one. After I enabled kscreen2 (without logging in/out) magically all problems mentioned in #33 disappeared. Only one new thing: - click on the start icon (launcher) on the right monitor, the window unfolds on the left screen.
Just as a reference, here there is a guide to create the script via GUI using arandr: https://forum.manjaro.org/index.php?topic=25445.0
(In reply to Dmitry from comment #29) > (In reply to gene smith from comment #28) > > Well, guess I spoke too soon. Today the problem happened again on KDE > > startup. Will try it set to run script on "Pre-KDE startup" for a while and > > see if that makes a difference. > > You'right it should start as soon as possible. Also it's better to disable > kscreen daemon in kde system settings / startup / services. Have been running the autostart script with "Pre-KDE startup" and with KScreen2 turned off since my previous comment and have seen no problems with screen configuration.
I have this issue too on a dual-screen NVIDIA setup, Archlinux, KF 5.18.0. I don't know if it's related but everytime I close a window I get a lot of these lines in journalctl : > kscreen_backend_launcher[513]: kscreen: Primary output changed from KScreen::Output(Id: 654 , Name: "DVI-I-1" ) ( "DVI-I-1" ) to KScreen::Output(Id: 654 , Name: "DVI-I-1" ) ( "DVI-I-1" ) followed by > kscreen.kded: Change detected > kscreen.kded: Saving current config to file > ... Despite that nothing changed, and this happens everytime I close a window. So I wonder if that's why the config gets messed up at some point.
I am also affected by this bug. I have many different scenarios besides the expected one. Using 3 monitors (1 laptop, 2 connected to docking station), expected setup is: left: laptop center: external monitor 1 (primary output) right: external monitor 2 Scenario 1: I have all outputs placed over each other Scenario 2: Outputs are placed correctly, primary output is laptop Scenario 3: Outputs are placed correctly, primary output is ext1, widgets are on ext1, however panel after some dancing between laptop and ext1 ends up on laptop screen And after manually setting up correct configuration I need to restart plasmashell to get app launcher show up on correct screen - it often shows on left screen not center when panel is. Removing laptop from dock, assuming that kscreen detects that action, messes up all configuration - plasmashell needs to be restarted again. Placing laptop back again on dock - messed up configuration - it's easier to reboot and setup everything again from scratch. Same happens with single monitor attached directly to laptop via HDMI. Expected setup is: left: laptop (primary) right: external monitor I don't have problems with primary output then because I want it to be laptop - so no work for kscreen/kde here and nothing to mess up. However kscreen does not detect disconnecting external monitor. OS : Chakra kscreen/libkscreen version: 5.5.4
I have a setup identical to the one of #Comment 38 and I experience the same problems. Moreover sometimes in this total mess, when I disconnect the laptop plasma crash, and other times I'm logged out of the KDE session.
BTW: sometimes plasma and/or kwin crash on display configuration switch with xrandr workaround. I've just added this into the script right after the xrandr command: sleep 1 kwin_x11 plasmashell kwin and plasma works as a singleton, so this does nothing if they didn't crashed and starts if kwin or plasma crashed after switch. PS: still waiting for kscreen fixes... =(
Thanks for the tip. So probably my crash is due to the fact that I'm using xrandr workaround. I was also also restarting krunner to solve the problem that it vanishes sleep 1 kwin_x11 plasmashell sleep 2 kquitapp5 krunner kstart5 krunner
On my laptop with embedded monitor + hdmi tv it was crashing with kscreen too.
I found some strange behaviors on my part using Archlinux and plasmashell 5.6.2. When I boot usually my config will be lost and the screen will be mirrored. If I kill the kscreen2 background service and relaunch it, Kscreen now remembers I have two monitors and places them correctly. At this point my panels are always messed. By switching the primary display a few times between my two monitors they somehow end up being correct. Maybe kscreen is executed early and Nvidia or something else overrides it.
The only solution that worked for me, was uninstalling kscreen and manual create a /etc/X11/xorg.d/10-monitor.conf file. See my working setup at the ArchWiki: https://wiki.archlinux.org/index.php/Multihead#Example:_dualhead_configuration_using_relative_coordinates_with_custom_resolutions
I am also seeing the same error on fedora 23 with package kscreen-5.5.5-1.fc23.x86_64.rpm. I have 2 identical screen where the left is turned 90 degrees. As of this morning, whenever I restart, both servers are identical, and in the screen view placed on top of each other (problem 1 from comment #38). When I setup my left screen the background says unturned, and overlaps into screen the right screen.
I have the same problem. Every reboot my multi-screen configuration is lost. (Nvida-GPU GTX 970) System: Netrunner Rolling, KDE Plasma 5.6.3, KDE-Frameworks 5.21.0, QT 5.60, Kernel 4.4.8-1
Same as CDK comment 46 Netrunner rolling Ati-4350 legacy using default open drivers driving two 22" desktop screens. Happening about 30%-40% of the time at boot with monitors end up stacked ontop of each other. Manually adjusting only recourse. Use to do it once every 8-10 boots. But after recent upgrades seems to be more frequent.
I have narrowed the problem down for my system (kscreen 5.5.5). No special randr script. Whenever I actually shutdown the computer (ASUS Z87-Expert) to power off and restart with the power button the screen layout is corrupted. Right screen has no wallpaper and the panel I keep at the bottom of that screen moves to the left screen which has wallpaper. Applications "Thunderbird" and "Firefox" are restored to their original positions on the right screen. Logout of plasma 5 to lightdm and login in as the same user sets everything to original layout and wallpapers. Rebooting system (not shutdown) restores screen layout correctly on first login. Only actually shutting the machine down to power off state changes screen layout. Logout and login again fixes it. I do not have any suspend options compiled into my kernel (4.4.6-gentoo).
(In reply to Mac Michaels from comment #48) > I have narrowed the problem down for my system (kscreen 5.5.5). No special > randr script. > > Whenever I actually shutdown the computer (ASUS Z87-Expert) to power off > and restart with the power button the screen layout is corrupted. Right > screen has no wallpaper and the panel I keep at the bottom of that screen > moves to the left screen which has wallpaper. Applications "Thunderbird" > and "Firefox" are restored to their original positions on the right screen. > > Logout of plasma 5 to lightdm and login in as the same user sets everything > to original layout and wallpapers. > > Rebooting system (not shutdown) restores screen layout correctly on first > login. > > Only actually shutting the machine down to power off state changes screen > layout. Logout and login again fixes it. I do not have any suspend options > compiled into my kernel (4.4.6-gentoo). Oops... restarting has same effect of shutdown and power up.
This bug is still lingering around in Plasma 5.6.2 (Frameworks 5.21.0, Qt 5.6.0) Quite annoying that one have to rearrange the monitors each time one log in. KDE won't even honour /etc/X11/xorg.conf.d/10-Monitors.conf, where other environments do.
Here's an ugly workaround to use meanwhile: 1: Set up your monitors as you see fit with KDE's monitor settings. Apply the changes. It has to be done with KDE's own tools/settings in order for the configuration to be written. xrandrand other third party tools won't do. 2: Confirm that your setup is in order by the contents of ~/.local/kde/kscreen/* 2: Open a terminal and make the configuration immutable: "sudo chattr +i ~/.local/kde/kscreen/*" (Yes, Attributes must be set/unset by root despite ownership) 3: Relog or reboot to see that it works as intended. Only drawback is that one have to remove the immutable flag in order to rearrange/reconfigure the monitors. To reverse the immutable flag, simply unset it: "sudo chattr -i ~/.local/kde/kscreen/*"
Here's an ugly workaround to use meanwhile: 1: Set up your monitors as you see fit with KDE's monitor settings. Apply the changes. It has to be done with KDE's own tools/settings in order for the configuration to be written. xrandrand other third party tools won't do. 2: Confirm that your setup is in order by the contents of ~/.local/share/kscreen/* 2: Open a terminal and make the configuration immutable: "sudo chattr +i ~/.local/share/kscreen/*" (Yes, Attributes must be set/unset by root despite ownership) 3: Relog or reboot to see that it works as intended. Only drawback is that one have to remove the immutable flag in order to rearrange/reconfigure the monitors. To reverse the immutable flag, simply unset it: "sudo chattr -i ~/.local/share/kscreen/*"
You're going much too far. It's sufficient to remove the writable attribute.
(In reply to Mika Norén from comment #52) > Here's an ugly workaround to use meanwhile: The workaround didn't work for me. I'm using the KDE Neon unstable archives now and the issue still exists - doesn't seem as bad as it used to be for me in that much of the time the configuration remains correct.... but every now and again it's still lost. This morning I logged in and the screens were mirrored ( rather than extended over both. ) Rebooted and it was fine again. This is with the kscreen config file set to read only.
Is Daniel Vrátil dvratil@kde.org still on this? As haven't seen a post from him in a year? New to this so don't know how it all works. Like he is the only one and now ignoring? Others? How to get more info on it being addressed or not? Thanks!
Same issue here. Fedora 23 desktop setup, three monitors, one large one in the middle and two smaller ones to the left and right. On reboot, KDE always resets all three monitors to the same resolution, and stacks them (so they show the screen output mirrored). Repeatable on every reboot. I have made the config file .local/share/kscreen/ read-only and the issue still happens. This is relatively new (a few months) -- this setup used to work fine in the KDE 4.x days and early KDE 5.x days.
Running into this issue here as well. Setup - two monitors: 1) Primary -> DisplayPort (RIGHT monitor) 2) Secondary -> HDMI (LEFT monitor) Logout or reboot always resets both monitors' resolution to 1920x1080 and resets both monitors' coordinates in System Settings -> Display Configuration to "on top of each other". Disabling KScreen 2 fixed these issues but produces new ones: a) Primary display setting is lost (reverts to "No Primary Display") b) Position information is reversed: DisplayPort monitor is now on the left and HDMI monitor on the right This now happens on each logout or reboot. After disabling KScreen 2, it *is* kind of an improvement but manual display configuration intervention is still required on each login, which is a pain. Sysinfo: ------------------------------------------- KDE Plasma Version: 5.6.3 KDE Frameworks Version: 5.21.0 Qt Version: 5.6.0 Kernel Version: 4.4.9-300.fc23.x86_64
Ok, not sure if this offers any clues, or if it's something unrelated. Logged in this morning and the screen layout had been reset. After trying a few times ( normally logging out/back in fixes it now the kscreen file is ro ) it still wasn't working, so I looked in .local/share/kscreen/ and found that it had got around the ro file thing by creating a new file dated yesterday - I deleted that and things were back to normal when I logged back in. That leads me to a train of thought. Maybe, sometimes during the boot process, kscreen fails to read the kscreen directory. This has more weight because my entire /home is a luks partition mounted with pam_mount - so could it be that there's a timing issue here? pam_mount hasn't completed before kscreen tries to initialise? Is there an easy way I can test this theory ( put a delay in somewhere, force kscreen to rely on pam_mount completing, or some such? )
I too am having problems. I used this guide to install my drivers: http://www.if-not-true-then-false.com/2015/fedora-nvidia-guide/ I even downloaded a program called "beesu" that allows me to run a program as root and save configuration file. beesu nvidia-settings and then I would configure my display settings (after a fresh restart). The login screen detects my duel monitor output, but after I punch in my log credentials! KABOOM!
1.) Install NVidia Drivers 2.) Install Beesu 3.) Use Beesu to launch NVIDIA X Server Settings (run as root and not have problem overwriting config file) 4.) sudo beesu nvidia-settings (I right clicked icon in settings menu and edit application to get command) 5.) Apply your changes to layout, THAN Save to X Config File THAN Quit. 6.) Launch up Background Services 7.) Startup Services than Uncheck KScreen 2 > Apply > OK > Restart GLHF and Happy Days from Philadelphia, USA!
I discovered a new clue to this problem. Just an observation to take into account. I updated the consolekit to use the master branch "=sys-auth/consolekit-9999" (I run gentoo -- mostly stable). There is a patch that was added to fix "ck-remove-directory" which was failing to remove the "/var/run/user/<uid>" directory. The fix description is at: https://www.bountysource.com/issues/33234185-ck-remove-directory-remove-dest-dir-as-real-user This fix had an unexpected effect on my dual monitor setup: Previously the task manager bar I placed at the bottom of the screen on the right always moved to the left screen on power down and reboot. Then it previously moved back to the the right screen when I logged out and logged back in. Now, after getting the above patch, it stays where I put it in both cases.
Relevant article: http://vizzzion.org/blog/2016/05/multiscreen-in-plasma-5-7-and-beyond/ So feedback on Plasma git master or 5.7 is welcome.
You also need Qt 5.6 _branch_, neither Qt 5.6.0 (released), nor Qt 5.6.1 (not yet released), nor any Qt 5.7 (also not released) do contain important fixes for Qt's screen handling. See e.g. cdf1e67de1c462a59b71ee0b14bab73dc3391b65 and fae8ee8b428ae7a406199e504b2d0eedd5059dbd In other words, if you are not compiling from source, you will have to wait for Qt 5.6.2 or Qt 5.7.1
Git commit 17199d32f292f7c44eb8cdce5b35396d3bd19eb8 by Sebastian Kügler. Committed on 01/06/2016 at 14:55. Pushed by sebas into branch 'master'. address race condition around setoperation Summary: Use a timer to avoid catching configChanged signals after we set changes. The long version: TL;DR: We have a race condition when the kscreen daemon starts. It looks up a known config, then applies it and subsequently resaves the config. The same happens on config changes, it writes, then re-reads and then re-writes the config change. I've managed to prevent this from happening by adding a timer that does avoids saving the config as a direct reaction to our own config changes. So what happens on kded5 startup after loading the kscreen2 module: - the kscreen config is requested and received - the kscreen daemon (KD) looks into its config directory for a suitable config file (a config file is identified by a combined hash of all screen attached, so unique per connected set of outputs) - KD usually finds a config - KD ignores configChanged events before it starts ... - a KScreen::SetConfigOperation to apply the "known config" - SetConfigOperation returns after a while (say 100ms later) - we re-enable the change monitor - we receive a configChanged signal - we save the new config (usually to the existing config file) I don't think this behavior is desirable. I don't see a reason why the daemon should save its config right after applying it. I think this causes more problems than we want, since the startup may overwrite the user's config. This behavior seems to be desired by the code in KD, it's already blocking configChanged signals during the SetOperation (which, to be honest may result in nightmarish behavior in any way, so it might be a kludge which aims too short). >From libkscreen perspective, SetConfigOperation::finished cannot guarantee that all configChanged signals are already fired and that it's safe to watch for new, independent changes now. At least on X11, we simply don't know, and what we can do is wait a bit and cross fingers that we're not catching our own noise. The changed signal *may* come from a re-request of the edid information, but this is a bit hard to track down, and not too useful, anyway, since changed Edid may affect a large number of a screen's properties. In the Wayland backend, that's a different story and we can prevent this behavior at an earlier stage, so this timer is "probably not needed" (I haven't tested that). This effectively prevents KD from catching reactions to its own changes and does not trigger saving the config file on every login. It still reacts to changes from libkscreen, but will avoid re-saving the config a few times. The timer may not be the neatest of solutions for this, but it does help narrowing down the problem and may be a last resort action. Most importantly, it avoids the re-writing of the config on startup and plugging/unplugging a monitor effectively. The timer value of 100ms is also used in kwin, which should make the behavior (which is no problem in kwin) more solid. Related: bug 358011 Reviewers: graesslin Reviewed By: graesslin Subscribers: plasma-devel, #plasma Tags: #plasma Differential Revision: https://phabricator.kde.org/D1730 M +12 -1 kded/daemon.cpp M +2 -0 kded/daemon.h http://commits.kde.org/kscreen/17199d32f292f7c44eb8cdce5b35396d3bd19eb8
I have this problem at every boot. When I log in into KDE the secondary monitor is just a copy of the primary one. I'm on Manjaro Linux with Plasma 5.6.4, Qt 5.6.0, Linux 4.6.2-1 and NVidia proprietary drivers 364.19-2. I don't have this problem on the same machine with Kubuntu 16.04.
We have this problem as well. I don't know why kscreen is saving the monitors configuration state, why does it need to do this ? If it needs to for some reason, can't it save it in a separate file to the user defined configuration ? It can then use the users configuration if available overriding any other "automaticially" saved config.
also loosing multi-monitor configuration with plasma 5.6.5 / QT 5.6.1, xf86-video-intel-2.99.917_p20160518, deleting configs from local/share/kscreen and reconfigure has no effect. Individual framerate settings and secondary monitor position is not restored after reboot.
Same issue with fedora 23 each time i log to my desktop
also I have the same issue with fedora 24 :(
Had the same issue here, none of the workarounds helped. I also tried to apply the patch from comment 64 to 5.6.5, to no avail. Now I upgraded to 5.7.0 and the problem is fixed. Thanks!
Fix confirmed for 5.7.0. Closing. Thanks everybody for providing help to address this issue!
...any specific patch you could point me to in addition to https://bugs.kde.org/show_bug.cgi?id=346961#c64 that solved this issue in 5.7?
@andreas: does this patch alone not solve your problem? If it doesn't, your best bet is to upgrade to 5.7, the concertation of these events is too brittle for me to spend my time debugging which actual patches to put on top of an older release to make it work. If it doesn't work for you with 5.7, please file a separate bug so we can look into that.
I was trying to solve another user's problem since 5.6.5 is stable in Gentoo (and 5.7 won't be for some time). Luckily we found the fix in libkscreen - should anyone else come across this: https://quickgit.kde.org/?p=libkscreen.git&a=commit&h=3cd70aa1cef0b4aab8c13bba049e5b1ccd6ae1ab
If I still have the problem (same as title) in 5.7.1 should I report it here or do you encourage opening a separate bug?
In 5.7.3 have same problem( in ~/.local/share/kscreen one file, after relogin multimonitor configuration is lost((((
I am using version 5.6.2 (Kubuntu 16.04/ Nvidia driver), I had the similar issue of default monitor being switched. (including panels and wallpaper). I had previously disabled/uninstalled KScreen as suggested elsewhere: but the issue persisted. The following worked in my case: 1. With kscreen 2 installed: Configure Monitors as desired, in System Settings -> Display and Monitor -> Display Configuration 2. Make sure only one file in ~/.local/share/kscreen/ AND make it read-only 3. Enable kscreen 2 at startup under in System Settings -> Startup and Shutdown -> Background Services kscreen now reads the file ~/.local/share/kscreen/file... at startup and does not change it - resulting in correct configuration.
I tried set read-only of my ~/.local/share/kscreen/{file}. But cannot help me( When I reboot I see black screen on my second monitor. And on second monitor I see only mouse cursor(((
This bug is fixed in Plasma 5.8. If you could test against that, it would be nice.
(In reply to Sebastian Kügler from comment #79) > This bug is fixed in Plasma 5.8. If you could test against that, it would be > nice. Is KDE Neon dev unstable ok to test that? http://files.kde.org/neon/images/neon-devedition-gitunstable/current/
Yes, neon dev unstable has all these fixes.
@Sebastian: Apart from the commit I found above (I'm not sure there's still an issue beyond that), is there anything in particular that one can look at for backporting to 5.7?
I have Arch Linux with uncomment [kde-unstable] repo. But my current install version of kde is 5.7.3(
@andreas.sturmlechner Seems tricky. There is a whole range of fixes that I've done in libkscreen, the kscreen kcm and the kded module. While they all fix individual issues, backporting them isn't quite trivial. Also, there's a more intrusive change in plasmashell (plasma-workspace/shell) that fixes plasma's dealing with esp. screen changes (this is the series of bugs that make plasma not render the right containments on a given screen, including panels). To get a really useful combination, these need to go hand in hand, so you'd have to backport patch series for at least 3 repositories to make it actually useful. At that point, you're running a Frankenstein Plasma out of 5.7 and 5.8, which nobody has tested and we certainly can't guarantee to have working. If you're doing this work for a distro, I'd actually recommend spending that time and work on making sure Plasma 5.8 becomes available as soon as possible (we've already reduced the length of this release cycle by two weeks), and perhaps get our upcoming beta packaged as well to give us a bit more testing so we can iron out problems or regressions that may have been introduced and need catching before 5.8.0. If you really really really want, you could try picking libkscreen and kscreen from git master. That will still leave you with problems in plasmashell, which from a quick look at the git changes, seem quite untrivial to backport. I'm sorry I can't be of much use here...
What is the best way to try out Plasma 5.8 on current Fedora (24)?
(In reply to Sebastian Kügler from comment #81) > Yes, neon dev unstable has all these fixes. I tried neon dev unstable, and situation looked much better. I still had a problem with panel having a "dead extension" (empty grey non-clickable panel) on the non primary display, when primary display is set to external monitor, but I'll open a separate bug for that. Thanks for the improvements.
I have this same exact issues. I have tried installing KDE Neon User Stable, Dev Stable and Dev Unstable and no luck. I have a laptop HP ZBook 15 G2 on docking station and 2 DELL monitors connected to it over displayport. The 1st one is detected corectly and used but the 2nd one is only detected but disabled for no reason. After I enable it everything works fine but upon reboot or reconnect to docking station all config is lost.
@doctor78: Could you provide your ~/.local/share/kscreen/kscreen.log please, so I can have a look at what's failing? What graphics hardware do you use?
@doctor78: Could you provide your ~/.local/share/kscreen/kscreen.log please, so I can have a look at what's failing? What graphics hardware do you use? Please file a new bugreport with this information, otherwise it gets too hard to track.
Created attachment 100993 [details] MY kscreen.log This is my fresh kscreen.log after restart. I am using hybrid graphic card setup with Intel and AMD graphics.
As I said, please file a new report, this becomes too hard to track efficiently otherwise.
I am waiting to Arch Linux to get 5.8, seems that 5.7.5 broke the multi screen again for my system. The panel also now won't move to another screen no matter what screen I set as the primary display. So it seems that the change to make the primary screen also the screen that the panel will display on, that commit has been undone by someone for some reason.
I just updated to the 5.8 branch and the system with dual DP and HDMI monitors started giving issues like before again!!! . panels not in primary monitor , settings getting lost after every reboot . Its really irritating to use in production . I am sorry If i am venting my frustrations here . but imagine my situation when i have deployed it in a production environement !!! . Artist here are not able to use kde as its supposed to be used . Everytime nuking the .config . .cache .local is NOT an option!! .
@Shrinidhi Rao Could you please file a new bug-report, and add the information as outlined on: https://community.kde.org/Solid/Projects/ScreenManagement#Debugging_Information
There's not much point in repeating what's already been said apart from the fact that I acknowledge the problem. It may have been fixed in the latest code but on the freshest fedora 24 it is defo still broken. Anyways...For me the most annoying thing is that I simply loose my windows or even the ability to put the laptop to sleep/suspend or even shutdown after undocking it. Environment: OS: Fedora 24 Desired monitor setup: eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 310mm x 170mm DP2-1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 520mm x 290mm DP2-2 connected 1920x1080+3840+0 (normal left inverted right x axis y axis) 600mm x 340mm This config is 90% of times lost when I undock the laptop and dock it again or udock, suspend, dock it back and wake up. The most reliable way for me to restore my screens is to run xrandr manually and not even specified all outputs in one go but enabling the outputs one after another: xrandr --output eDP1 --auto --primary && xrandr --output DP2-1 --auto --right-of eDP1 && xrandr --output DP2-2 --auto --right-of DP2-1 I have this command in history of krunner so I can fairly easily get back to it if I loose my screens after undocking and have no way to restore windows quickly. Today I discovered a new method which seems to work for me every time I undock and redock: This one is using the feature of power management/Energy Saving settings. In particular executing scripts on Profile changes. So I have 2 scripts: $ ls -1 ~/scripts/ disable-external-monitors.sh enable-external-monitors.sh containing: $ cat scripts/enable-external-monitors.sh #!/usr/bin/env bash PATH=$PATH:/usr/bin export DISPLAY=":0" logger "$0 - run" sleep 1 xrandr --output eDP1 --auto --primary && xrandr --output DP2-1 --auto --right-of eDP1 && xrandr --output DP2-2 --auto --right-of DP2-1 and: $ cat scripts/disable-external-monitors.sh #!/usr/bin/env bash PATH=$PATH:/usr/bin export DISPLAY=":0" logger "$0 - run" sleep 1 xrandr --output eDP1 --auto --primary && xrandr --output DP2-1 --off && xrandr --output DP2-2 --off The scripts are executable (obviously). So in the settings of Energy Saving for "On AC Power" profile I have: Run script (ticked) and pointing at: /home/a.key/scripts/enable-external-monitors.sh and for "On Battery" Run script (ticked) and pointing at: /home/a.key/scripts/disable-external-monitors.sh This seems to work pretty well with the current state of things (broken KDE packages as provided by current Fedora 24). Obviously for your setups you will have to modify the outputs in xrandr calls inside the scripts. There's obviously a bit of debugging in them. The reason for 1s sleep is that I very often find that my Thinkpad T440s takes a bit of time to register h/w changes that happen during docking/undocking so allowing 1s delay is helping there. This doesn't resolve the screen setup being broken during KDE start (after reboot) but that should be as simple as adding the "enable-external-monitors.sh) script to KDE startup. Hope this helps before we get the fixed packages from vendors/distributions.
A simple killall plasmashell; plasmashell after startup seems to fix it for me. Using Kubuntu 16.10 and KDE Framework 5.26.0 (Plasma 5.7.5)
If restarting plasmashell fixes the issue, then this should work correctly with Plasma 5.8.4.