SUMMARY New KDE 5.27 has no Primary Display setting, KDE Menu/Taskbar Panel does not adhere to Primary Display set by KDE System or Nvidia Settings, behaves erratically when moved around otherwise. STEPS TO REPRODUCE 1. Boot Laptop with single display. 2. Connect a (Thunderbolt 4) dock with an additional 3 displays. 3. Launch KDE System Settings, enable all displays, set resolution/speed, align the displays in the setting UI, and set the priorities in the new 5.27 UI. 4. At this point the intention is to move the main KDE Panel from Display 1 to Display 3, but no matter of adjustment of the priorities of 4 displays moves the panel or docks. 5. Launch nvidia-settings, and in "X Server Display Configuration", choose the 3rd display, click "Make this the primary display", and click apply. 6. At this point the Panel and Docks should move to Display 3, where the Docks (cairo-dock) move, however the KDE Panel does not. 7. Clicking on the Panel and Edit, moving the display to the 3rd Display now moves the Panel and Dock on Display 3. This is now ideally configured. 8. Hard disconnect the Thunderbolt dock, all external displays go offline, KDE Panel and Docks should move back to Display 1, only the Dock moves back to Display 1, but KDE Panel isn't present or displayed at all. 9. Reconfigure desktop in KDE Settings again to reactivate displays, reorder them as needed, and apply settings. 10. Observe once all 4 displays are back active, now the Docks move back to Display 3, but the KDE Panel is actually on Display 2. 11. Adjustment with nvidia-settings for the Primary Display moves the Docks again, but not Panel. OBSERVED RESULT 1. New KDE 5.27 System Settings for Displays does not allow for primary display to be set in multi-monitor configurations respective of priority or order, requiring nvidia-settings to do so 2. Main KDE Panel does not follow primary display any longer as it had in 5.26, and does not behave and move with the docks as expected. 3. Each reset of external displays or dock disables all displays and resets settings, forcing manual reconfiguration each time. 4. Each reset of the displays also grossly reset open windows at the same height, but now only 1-10px wide, making them difficult to find as well as having to resize each window tediously each time. EXPECTED RESULT 1. KDE System Settings needs a method of setting the Primary Display to expect the Panel and Docks to follow that with 2 or more displays. 2. KDE Main Panel should respect the *Primary Display* as the Docks do relative to display settings. 3. KDE Settings should also remember the display type to system port/quantities to reapply resolution/refresh/alignment, and Primary Display ownership between cable detachments. 4. KDE should NOT change window widths to any less than sane amount if needed at all, and certainly not when all the displays are at the same resolution despite 1 or 4 displays. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux, 6.1.12 kernel, nvidia 525.89.02 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION KDE not remembering display settings each time and grossly resizing windows has been broken for a long time, but seems even more exaggerated now. Perhaps also not using the new Screen Priorities settings, but not really sure how these are intended to work either as nothing seemed to affect the primary display anyways., but hard to show with screen shots of 4x 4k displays at a time.
There's a few different topics in your expected results, so lets try to focus on just one. >1. KDE System Settings needs a method of setting the Primary Display to expect the Panel and Docks to follow that with 2 or more displays. That should be happening. Please verify not by where the docks and panels are, but through the output of "kscreen-doctor -o" and "xrandr -q" What we should see is: - kscreen-doctor shows `priority 1` `priority 2` on screens 1-4 each time you plug them in - xrandr -q shows the screen with priority 1 as top priority. If this does not match the expected result, please attach relevant outputs after plugging in the dock or configuring settings. If this all looks correct, we can then start to look at the panels.
Edit, I meant > - xrandr -q shows the screen that had priority 1 as "primary"
Thanks for the response, here's the output of those: http://pastie.org/p/2vbKRktRNna6sX0AKTjdLx Looking at the output, priority one shows the 3rd display on DP-5.2, which is proper, and my dock lands there, but the panel itself lands on the 4th display, or DP-5.1.5/Priority 3. Display 1 - DP-4 Display 2 - DP-5.1.6 Display 3 - DP-5.2 (set primary in nvidia, dock is here) Display 4 - DP-5.1.5 (panel is here, as is a plasma widget I had set on the primary before) Looking in KDE System Setting/Display, it seems to show the right monitor nvidia settings show primary (can't tell, it doesn't show the port here). but I couldn't set that until I did it in nvidia-settings. That is another problem actually, the system settings in display really need to show the actual port (ie. DP-5.1.5) in the device and change screen properties. All my displays show up the same with only the device name and no port, and I can't tell them apart, which is frustrating. Thanks again!
Here's what this looks like currently from kde settings and nvidia-settings. https://pasteboard.co/dZxEOWGPCE1M.png
Actually, here's one of the whole screen setup with the settings and the panels as they are weirdly right now. Had to scale the image quality down some to fit on a pastebin, but here you go. https://pasteboard.co/Prf0B3yvjj5u.jpg
So some more on this random behavior, yesterday I went through and disconnected my dock, reconnected them in left-to-right ordering, reset them up manually, then without any real work, both the panel/plasma widget and dock items landed on the 3rd display as intended. Finally. It's a bit painful to setup each of 4 displays in either nvidia or kde gui (latter far more painful with odd snapping), so I wrote a quick one-liner shell script to use xrandr to activate, set the res/refresh, place them sequentially, and set primary in far less time than it took to reset it manually each time, which testing the script seemed to keep the panel and dock in the same place even when I accidentally moved them out of order. Solid, maybe a fluke? Nope, so I woke up today, and my dock had glitched somehow, losing the 3x external displays again, so I use my trusty xrandr script to put things back, and now the panels are amiss again with dock on display 3, and panel/plasma widget on 4. Ugh. So yes, this seems oddly random the main panel if sticking to random-ish displays where at least the dock is following standard directives consistently still. If there is a commonality, I'm missing it thus far.
Created attachment 156725 [details] kscreen-doctor -o output Output taken while displays active, 3rd set to primary with dock there, but main panel and widgets on 4th.
Created attachment 156726 [details] kscreen-console output Output taken while displays active, 3rd set to primary with dock there, but main panel and widgets on 4th.
Created attachment 156727 [details] kscreen settings and nvidia-settings image Output taken while displays active, 3rd set to primary with dock there, but main panel and widgets on 4th.
Created attachment 156728 [details] full desktop low-res showing dock/panel disparities on far right 3/4th displays Output taken while displays active, 3rd set to primary with dock there, but main panel and widgets on 4th.
Created attachment 156729 [details] desktop-appletsrc file data Output taken while displays active, 3rd set to primary with dock there, but main panel and widgets on 4th.
Sorry, I didn't realize the pastbin links expired, I attached the output and some images of the desktop properly here. I added some other information requested from your blog as well. Not sure if this should be here or plasma/multi-screen, but seems a bit of both. Tinkering with this some more after reboots and reconfiguration, the main panel always seems to stick to display 4 now while 3rd is still set to primary (via nvidia).
Thanks. If you stop `nvidia-settings` from running, use System Settings > Display & Monitor to configure your screens, and reboot, does the issue go away?
Thanks Matt, I will try that when I can reboot a bit later, but as of upgrading to 5.27, I was still almost always using kde settings alone, and tried until I couldn't get the panel and primary display to end up on the right monitor, that's when I finally broke down to use nvidia-settings at all finally. I don't think the problem is with nvidia-settings as I only put it in the middle of things after kde failed in the setup portion to get a proper primary display and then the panel tracking primary. The root it seems to me is I can't get xrandr to get "primary" on the right display with kscreen settings, so getting lost in translation further when I push primary with nvidia-settings around it, which I presume why the panel is misbehaving. The really wacky thing lately is my dock occasionally seems to glitch and lose the displays, resetting things back to the primary laptop display only blanking the others, but my main panel doesn't come back, only cairo-dock there. Occasionally even worse is my windows don't move back to the primary display now either, meaning I have neither settings nor a terminal to reset my displays to the full 4-monitor setup and find my missing windows! I've had to use cairo-dock to close konsole, and relaunch it there (luckily it was pinned) to use my xrandr script before I'd just have to drop to a tty and reload sddm. Very ugly, and only ever seen this since 5.27, but seems all related to this panel and primary display behavior.
Ok, so for debugging purposes, let's forget about both nvidia-settings and xrandr and focus only on what happens when you use the Display & Monitor page in System Settings. Once we can quantify exactly what the issue is there, we can try to fix it, and then you hopefully won't have to use workaround scripts anymore. :) In general it's best to submit bug reports only on behavior in KDE software when not using any workarounds for bugs. Let's start here: > Looking at the output, priority one shows the 3rd display on DP-5.2, which is proper, and my dock lands there, but the panel itself lands on the 4th display, or DP-5.1.5/Priority 3. If you manually move the panel from the 4th display (priority 3) to the 3rd display (priority 1), does it thereafter follow changes to which screen has priority 1?
Sorry for the delay, was sick or busy, so first chance I had to futz with the desktop more. > Ok, so for debugging purposes, let's forget about both nvidia-settings and > xrandr and focus only on what happens when you use the Display & Monitor > page in System Settings. I spent some time on this over the weekend recabling things, both under xorg and wayland, resetting all the display properties up manually a display at a time using only KDE settings, and found mostly the same behavior on either. The main panel and widgets simply will not follow the primary display regardless of what KDE thinks is the primary display. Short of wiping the whole .config directory, is there a better way to selectively purge current display settings to let KDE refactor things or remove any legacy fragments there might be? > If you manually move the panel from the 4th display (priority 3) to the 3rd > display (priority 1), does it thereafter follow changes to which screen has > priority 1? Any time I move the panel, it will only stay on the one marked primary as long as the display geometry doesn't change, but ANY reset or change for me had the panel jumping back to whatever it *thought* should be primary at the moment despite where I moved it. Past few days I've seen that be any of the displays, it's almost random what one it picks to think is primary, but usually until I restart the DE, it'll always stick to one in particular, but never predictably. Because Cairo-Dock doesn't work in Wayland, I was attempting to use Latte Dock as well, and what I found was where Cairo would follow what the system thought was primary reliably, anything KDE, including Latte or any desktop-placed widgets/panels followed whatever KDE thought was primary where the panels would end up. This seems to indicate all the KDE-y things alone seem busted. This seems to be not helped by the fact that KDE doesn't seem capable of ever putting my monitors back to the way there were between any forced hot-plug events or reconfiguration events alone. Not sure if this is a bug or feature that it will do this, but when KDE keeps restarting and jumbling my entire display, it certainly can't be helping. I went so far as to put in EDID spoofers to stop the madness of KDE forgetting my order/resolution/refresh every time as bad behavior when I shut off displays, such was the recabling.
One other thing of note I forgot to mention, I tried change screen priorities in Ksettings, moving around displays and reordering, trying to get the kde panels tracking primary to move, but still would not, again under wayland or xorg sessions. Cairo-dock will seem to move with reordering the priority in Ksettings, and verified xrand/nvidia-settings seeing the primary change, so that is working for non-KDE things, just whatever aspect is tracking the panels in plasma isn't respecting those. Now the weird part is in Ksettings, if I move the primary display using xrandr or nvidia-settings, it will see that I made a change and forcibly refresh, but the ordering in new option still shows the old display as primary, even though it knows it's not from the refresh. The ordering concept doesn't seem to be getting updated fully when changes happen outside its control such as a dock disconnect or another application deciding to move the primary display from its preferences, but I suspect this all ties into the weird behavior of the "primary" panels not tracking properly for KDE-based services.
(In reply to Michael Butash from comment #16) > Short of wiping the whole .config directory, is there a better way to > selectively purge current display settings to let KDE refactor things or > remove any legacy fragments there might be? Screen arrangement data is saved in ~/.local/share/kscreen, which can be moved aside for testing purposes or deleted. Containment and panel data is stored in a combination of ~/.config/plasma-org.kde.plasma.desktop-appletsrc and ~/.config/plasmashellrc. Those files too can be moved aside for testing, but you might not want to delete them or else you'll lose all your Plasma customizations). > Any time I move the panel, it will only stay on the one marked primary as > long as the display geometry doesn't change, but ANY reset or change for me > had the panel jumping back to whatever it *thought* should be primary at the > moment despite where I moved it. Past few days I've seen that be any of the > displays, it's almost random what one it picks to think is primary, but > usually until I restart the DE, it'll always stick to one in particular, but > never predictably. > > Because Cairo-Dock doesn't work in Wayland, I was attempting to use Latte > Dock as well, and what I found was where Cairo would follow what the system > thought was primary reliably, anything KDE, including Latte or any > desktop-placed widgets/panels followed whatever KDE thought was primary > where the panels would end up. This seems to indicate all the KDE-y things > alone seem busted. Can you try with a standard Plasma panel? Using 3rd-party panels is definitely not helping. :) > This seems to be not helped by the fact that KDE doesn't seem capable of > ever putting my monitors back to the way there were between any forced > hot-plug events or reconfiguration events alone. Not sure if this is a bug > or feature that it will do this, but when KDE keeps restarting and jumbling > my entire display, it certainly can't be helping. I went so far as to put > in EDID spoofers to stop the madness of KDE forgetting my > order/resolution/refresh every time as bad behavior when I shut off > displays, such was the recabling. This seems like a root cause. If the screen arrangement itself is not being remembered properly, then that's going to bubble up and nothing else will work properly too. I would propose that we start with that issue. For testing purposes, please remove all EDIT spoofers and other manual workarounds you may have applied. The goal is to get the system into a clean state where we can reproduce bugs without local configurations or workarounds interfering. It's often the case that workarounds for old bugs actually prolong those bugs once the bugs get fixed, which is what I suspect may be happening here.
(In reply to Nate Graham from comment #18) > (In reply to Michael Butash from comment #16) > Screen arrangement data is saved in ~/.local/share/kscreen, which can be > moved aside for testing purposes or deleted. > > Containment and panel data is stored in a combination of > ~/.config/plasma-org.kde.plasma.desktop-appletsrc and > ~/.config/plasmashellrc. Those files too can be moved aside for testing, but > you might not want to delete them or else you'll lose all your Plasma > customizations). Odd, there are a lot (34!) of different setups it seems under .local's kscreen directory, which I'm presuming it's trying to pick one to use each time. I'll try clearing out that lot and the other two as well, not much I didn't reset already recently accidentally. > Can you try with a standard Plasma panel? Using 3rd-party panels is > definitely not helping. :) I have been the whole time, the docks are just contrast to the main default panel of KDE which I normally use on the right side of a screen that tracks primary, as well as a widget at the time I had on a non-primary display. Once it started bouncing around with 5.27, both the default panel and the widget will move or stay together on whatever random display it chose that time, vs cairo-dock that isn't QT based or KDE-aligned, but goes to the right "primary" display as reported. I can add a second kde panel to test with or some more widgets, but my money is they'll stick like the current panel/widget when it roams. > This seems like a root cause. If the screen arrangement itself is not being > remembered properly, then that's going to bubble up and nothing else will > work properly too. Since I last reconfigured things going between wayland and xorg testing both, I made sure to use the "Save displays' properties" to "For only this specific display arrangement", and it's been adhering to this the past few times the dock has glitch reset or logged out/in. It had not before reliably to ever retain settings. This has always been a bit confusing the intended use case of these options to save display properties to restore the right geometry/order each time. I need a bit of a mix of both. Namely: 1) Saving global resolution/refresh per display (assuming they get out of order in any capacity) AND 2) If/when it does see that magical combination of reported devices on the proper ports, to restore the geometry AND order to the devices. This is complicated by my 3x displays all reporting the same, but at least seeing any x|y|z device, apply this setting, and if all of them in the right place, also set an order. Some of my odd corner case is that any one display can do 4k/60, and individually should. However IF all 4 displays at the same time, on the right ports, then the external displays need explicitly set to ONLY 4k/30, or the dock/gpu tend to freak out. I'd be happy if they just always mod down to 30hz always as a common denominator, but it's never a good time if they decide to all try to come up at 60hz. Tall order yes, and don't expect an immediate fix, but something to consider when folks like me are griping about exotic multi-monitor setups. > I would propose that we start with that issue. For testing purposes, please > remove all EDIT spoofers and other manual workarounds you may have applied. > The goal is to get the system into a clean state where we can reproduce bugs > without local configurations or workarounds interfering. It's often the case > that workarounds for old bugs actually prolong those bugs once the bugs get > fixed, which is what I suspect may be happening here. I would agree normally, but keep in mind I just literally added the EDID spoofers 3 days ago, when this was posted weeks ago then using direct DP-to-HDMI adapter cables for 2x DP out on the dock, and 1x native HDMI ports/cable end-to-end each display here, so the weirdness I'm certain isn't related to them now. Their intention was to help stabilize KDE from freaking out every time I shut my displays off at night and have to spend the first part of my day coaxing KDE to work again and moving all my 50 windows back in the right places. Even with a clean boot, all displays coming up cleanly, and the primary display on monitor 3 as intended, the kde panels/widgets (and latte dock) still ignore this - that is the problem, I just don't know if bad settings or bad panel. Ksettings also visually does a poor job of showing what displays are on what physical port, which is my only way of differentiating them in settings, and today I never know which display is actually which (always fun shell game with 3!), and doesn't under "Change screen priority" either... I'm not sure if this is also confusing core plasma somehow to figure out which display is actually which when they're all named the same vs name+port tuple. You had mentioned complication as well around this somewhere as well. Let me see with a clearing of the local/config files and see how that behaves and will report back. Thank you again for the advice and help here!
I got to do some testing on my desktop over the weekend kscreen and plasma, removing the configuration settings as you'd indicated, and does seem to be working that the panel and widgets track the primary display once regenerating those two plasma files and the kscreen directory. Most certain it seems I'd accumulated something that made it bonkers, this is not an old installation, so it would seem somewhere before and after was fighting itself. I did test the "change screen priorities" as well, and yes, those do seem to work as well now that the topmost display in priority becomes primary. It is still difficult to tell the displays with all the same models without a clear reflection of the associated port they are on, and really needs to be added to make that feature less frustrating. So yes, I think rebuilding those files resolved this now, I'm going to upload the before and after sets of those files in zips here if you'd like diff between them, it'll probably make more sense to you why these these might have been in conflict to ensure this doesn't happen for others with multiple monitors. Thanks for the input on this everyone!
Created attachment 157657 [details] Before kscreen/plasma config files includes: ~/.local/share/kscreen ~/config/plasma-org.kde.plasma.desktop-appletsrc ~/config/plasmashellrc
Created attachment 157658 [details] After kscreen/plama config files - WORKING includes: ~/.local/share/kscreen ~/config/plasma-org.kde.plasma.desktop-appletsrc ~/config/plasmashellrc
Oh, such good news! And thank you so much for attaching the old broken configs to compare with the new working ones. That's gold right there.
I don't see anything suspicious in the Plasma config files, which leaves KScreen as the culprit. Unfortunately KScreen configs are basically impossible to diff so I suspect we'll never truly know what weird old config data was causing this. Thanks so much anyway!
(In reply to Nate Graham from comment #24) > I don't see anything suspicious in the Plasma config files, which leaves > KScreen as the culprit. Unfortunately KScreen configs are basically > impossible to diff so I suspect we'll never truly know what weird old config > data was causing this. Thanks so much anyway! Agreed, I did the same, and other than a bunch of application specific windowing parameters, I didn't see much. What was odd was under the plasmascreenrc was the [ScreenConnectors] portion, that wasn't present under the last, but didn't seem suspect otherwise, just don't know what those definitions were used by or for. This laptop is only about 6mo old, I doubt it began with too old of plasma to pick up too much cruft along the way. I think some of it is the collection too of all the various "what if's" that collect over time, such my plethora of kscreen variations in that folder that likely I would venture conflict with one another. Now that I understand from your guidance more about how kde stores display params, I can diagnose this more, otherwise I know at least to purge those settings. Now my next biggest challenge is why the kwin script for restoreToScreen never works for restoring window placements working randomly, less often than more. With 4 displays, it's maddening when my dock glitches, and moves ALL my 50-some windows away from my 3x 50" TV's to my 15" laptop screen, forcing me to manually move stuff around back where I want them. KDE really should handle this natively better than a script plugin. Thanks again Nate and David!