Bug 206721 - Option to automatically move panel to primary screen if screens are added/removed using xrandr
Summary: Option to automatically move panel to primary screen if screens are added/rem...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: plasma4
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Linux
: NOR wishlist
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-08 08:38 UTC by Thomas Winkler
Modified: 2018-06-08 19:59 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Winkler 2009-09-08 08:38:02 UTC
Version:            (using KDE 4.3.1)
OS:                Linux
Installed from:    Unspecified Linux

When attaching an external monitor to my laptop using xrandr I would like my panel to move to the primary screen (at the bottom using the full width of the screen). This worked nicely on KDE 3.x and is also the default behavior on Windows systems. With KDE 4.3.x the panel stays at the laptop screen and there seems to be no option to automatically move the panel to the primary screen if an external monitor is attached / removed.

The only "workaround" I could come up with was adding an additional panel for the external monitor essentially duplicating the panel running on the laptop screen. This setup however does not make much sense. Additionally I experienced a problem with the placement of the panel when using external monitors with different resolutions (at work I have 1600x1200 and at home 1920x1200). The panel does not automatically adjust to the geometry of the different external monitors.

To summarize: I hereby would like to request the addition of a configuration option that allows to automatically move the panel to the primary screen if an external monitor is attached. This would allow to have the same behavior as found in the KDE 3.x series and on all Windows systems starting from Windows 2000 up to Windows 7.
Comment 1 KarstenRBecker 2009-11-13 11:05:42 UTC
I can confirm this behaviour. I was trying to get it working the last hours, but no avail.

My notebook is right of the external monitor in my office. I'm sitting directly in front of the external monitor. If I move now my panels onto the external monitor, everything is fine - at work.

If I start after that my notebook at home, without an external monitor connected, I don't have any panel and need to create new ones.

Next day, back to office, I have the panels moved to the external monitor in the office, plus the additionally created at home on the notebook LCD.

So there's no chance to get the behaviour of KDE 3.5.x. It seems, that the "--primary" flag of xrandr is ignored by the KDE panels.
Comment 2 Martin Honermeyer 2010-01-22 12:49:32 UTC
I think this is the same bug as #183280.  How to mark this as a duplicate?
Comment 3 Michael Long 2010-02-07 14:40:41 UTC
I can also confirm this behavior, at least on one particular machine (My old IBM T40p laptop). 

When I issue xrandr --output VGA-0 --auto --right-of LVDS, on the external monitor I see an empty desktop with the default air background and no other components.

On my other laptop, a Lenovo T500, the same command (DP instead of VGA-0 used) the behavior of KDE4 is different, all my desktop components are moving to the new attached external monitor and the LVDS gets the default air-backgorund and is empty. 

As stated before, xrandr-flags like --primary or --noprimary are not respected. 

Other than the bug reporter, I would like to have the desktop components shown on the internal display (LVDS) and not on the external one.

Both tested laptops have the same KDE-version, 4.3.5, and they both use the same Xorg-version and radeon-driver.

The solution is to define which available output device (LVDS, DP, VGA, HDMI, TV etc.) is meant to be the primary one for KDE.
Comment 4 Diego 2010-03-14 12:26:13 UTC
(In reply to comment #1)
> I can confirm this behaviour. I was trying to get it working the last hours,
> but no avail.
> 
> My notebook is right of the external monitor in my office. I'm sitting directly
> in front of the external monitor. If I move now my panels onto the external
> monitor, everything is fine - at work.
> 
> If I start after that my notebook at home, without an external monitor
> connected, I don't have any panel and need to create new ones.
> 
> Next day, back to office, I have the panels moved to the external monitor in
> the office, plus the additionally created at home on the notebook LCD.
> 
> So there's no chance to get the behaviour of KDE 3.5.x. It seems, that the
> "--primary" flag of xrandr is ignored by the KDE panels.

This is really annoying: moving the main panel to the primary screen should be the default and I'm going to argue why.

At work I have a dual monitor set-up: the notebook internal LCD panel 1366x768 and an external big monitor 1920x1200. I like using the external monitor as my main screen because it's bigger, so I move the panel in that monitor. If I go out for work with the notebook and forget to move the panel to the internal monitor before disconnecting the external monitor I lose the panel and I cannot access it in any way.

This is EXTREMELY DANGEROUS because:
- you have no access at all: there doesn't exist a list of the panel or a dedicated configuration tool. You don't know how many panels there are out there and what they have in them;
- as you don't have access, you cannot remove them either. This is problematic in relation to system tray. As you know old systray protocol doesn't permit to have multiple copies of the same icon. In my case I had Gnome NetworkManager icon in the "main panel" in the external monitor, so I cannot get back the network in any way because I could not get back my "main" systray in any way. I know I had another systray opened because it was in the used object in the "add widgets", but I could not remove it;
- I cannot find anything like "Add default panel" which is something "Add a panel with vanilla settings / widgets";
- I cannot find anything like "Restore Plasma desktop to system defaults".

This is the problem. How do we get out of it?
This is the solution I propose:
- introduce the concept of "main panel", a particularly important panel which, by default it contains "vital widget" and that should be in one of the active screen AND could be moved with a configuration tool to a given screen, even if you have not access to it (es. because one of the monitors is faulty).

Thank you, regards,
Diego
Comment 5 postdoc38 2010-03-27 21:24:48 UTC
yes, I second that. IMHO, kde should respect the --primary and --noprimary arguments of xrandr, period.
Comment 6 mailing.mr 2010-04-01 08:52:45 UTC
This is without the doubt most annoying thing on new KDE, previous versions worked nicelly, but no each time I connect laptop to external device panels move to it, or not. Behaviour seems random, on my one laptop it moves to other mnitor if it's HDMI but not VGA, on my current laptop it always moves to another screen, even when it's smaller then original one.
This is annoying, there's no way to change it, xrandr --primary option is ignored.
Comment 7 postdoc38 2010-04-14 13:34:36 UTC
Since kde4 shows a popup for screen configuration when a new monitor is plugged in, why not include in the configuration options thus displayed a way of forcing the panel to be on one of the two displays?
Comment 8 Maciej Sitarz 2010-04-26 09:10:36 UTC
*** This bug has been confirmed by popular vote. ***
Comment 9 postdoc38 2010-04-30 13:41:02 UTC
Apparently there is hope that somebody will work on multi-head issues this summer:

http://jlp.holodeck1.com/blog/2010/04/28/gsoc-2010-with-kde-improving-multi-display-support/

All the best for your efforts, JLP.
Comment 10 Andrey 2010-08-15 01:00:26 UTC
On my system it is fixed.

KDE 4.5.0. + Intel 965GM:
KDE places panels and widgets to the screen which is set as --primary via xrandr.
I can actually switch their position by issuing command xrandr with '--primary'.

I think it works the same way with other Intel cards,
but I am not sure about ATI/NVidia/others...
Comment 11 postdoc38 2010-08-15 16:17:22 UTC
Doesn't work for me (ati HD 3670), --primary has no effect.

What does work is that the panel and widget now stay on the laptop screen when I place an HDMI output "to its right". Unfortunately, I suspect it is because X and/or fglrx now numbers the outputs correctly, not because of some KDE intervention.
Comment 12 Andrey 2010-08-15 20:21:33 UTC
You mean that if you set HDMI as via --primary it still 
does not move the panels to HDMI?

It seems to me that this bug title is about automatically 
detecting primary screen. So yes, KDE 'asks' XOrg, 
which screen is primary and sets its panel to it.
It is a default behavior, so no option is needed for this.
As far as I know KDE library, which handles this is called Kephal.
See this comment: https://bugs.kde.org/show_bug.cgi?id=191479#c2

If that does not work, this bug should not be closed.
If primary screen is detected and panels are move 
after setting --primary via xrandr, then everything works 
as it should and this bug should be closed.

But still GUI option for choosing which 
screen is primary without xrandr will be nice.
The bug about absence of GUI option for toggling primary screen is here:
https://bugs.kde.org/show_bug.cgi?id=241719

This is how I see it. Correct me if I am wrong.
Comment 13 postdoc38 2010-08-16 09:19:22 UTC
I can confirm it is not working. Here are my specs: kde 4.5 through opensuse rpm's, ATI HD 3670 managed by proprietary driver fglrx. Here are the issues:

1) when attaching second monitor (called DFP1 for some reason) on HDMI output, it clones LVDS by default. Hitting "configure" in the popup, and then setting DFP1 to the right of LVDS on the GUI has no effect, at all.

2) using "xrandr --output DFP1 --right-of LVDS" works: the cursor moves to DFP1 when it crosses the right edge of LVDS, good.

3) "xrandr --output DFP1 --primary --right-of LVDS" has no effect I can see. Panel, cashew and the like do NOT move to DFP1 but stay on LVDS. 

Note that I don't know whether kde is ignoring the primary set by X/xrandr, or whether X is ignoring the --primary key in the above command. Is there a way to test that?

Finally, and in contrast to the above, up to a few weeks (maybe months) ago, kde would automatically move the panel to DFP1, whatever primary was set via xrandr, so things do work better now.
Comment 14 Andrey 2010-08-16 16:08:41 UTC
(In reply to comment #13)
> 1) when attaching second monitor (called DFP1 for some reason) on HDMI output,
> it clones LVDS by default. Hitting "configure" in the popup, and then setting
> DFP1 to the right of LVDS on the GUI has no effect, at all.

That display configuration module never worked quite well for me,
neither did KRandRTray. The best result I could ever get
was configuring *one* monitor correctly.
If your layout is somewhat more complex - it fails.

If it actually worked maybe I wouldn't even know that xrandr command exists.
And there is a bug report for this:
http://bugs.kde.org/show_bug.cgi?id=180437
 
> 3) "xrandr --output DFP1 --primary --right-of LVDS" has no effect I can see.
> Panel, cashew and the like do NOT move to DFP1 but stay on LVDS. 

Maybe it would be a little bit more convenient 
to set position and resolution first. And the use shorter commands:
xrandr --output DFP1 --primary
xrandr --output LVDS --primary
xrandr --output DFP1 --noprimary
xrandr --output LVDS --noprimary
 
> Note that I don't know whether kde is ignoring the primary set by X/xrandr, or
> whether X is ignoring the --primary key in the above command. Is there a way to
> test that?

I am afraid that it is some global XOrg glitch.
I don't think that KDE is ignoring monitor order numbers.
Unfortunately, I did not find a way to check that.
Nothing interesting seems to be both in...
1) /var/log/Xorg.0.log 
(that for openSUSE, you distribution may be different)
You can use "tail -f /var/log/Xorg.0.log" to see changes "on-line".
2) xrandr -q
Does not list monitor priority/ordinal numbers

Though, that is for Intel 965GM, 
so maybe you will find something there if you have ATI.

At least KDE "asks" XOrg somehow, so I suppose there should be the way to get those numbers.

And yet another thing to chekc is: Multiple Monitors
(just type that in krunner or find that in SystemSettings->Hardware->Display and Monitor->)
Press "Identify all Displays". However, if KDE doesn't move your panels,
that means that it did not get correct numbers from XOrg. But check that anyway.
Primary should be #1.

> Finally, and in contrast to the above, up to a few weeks (maybe months) ago,
> kde would automatically move the panel to DFP1, whatever primary was set via
> xrandr, so things do work better now.

Thath's good. For me it was the other way around. 
After upgrading to 4.5.0 my panels were moved everytime 
I connected VGA monitor, so I had to find out a way to set my LVDS as primary. 
That way was the --primary switch for xrandr, because Intel drivers list LVDS 
as 2 monitor by default for some reason. 

So here goes another bug report for setting --primary to the monitor you want via GUI:
https://bugs.kde.org/show_bug.cgi?id=241719
Comment 15 Paul Fee 2010-09-01 11:52:22 UTC
I'm using a Lenovo T400, Intel integrated graphics, Fedora 13.

xorg-x11-drv-intel-2.11.0-5.fc13.x86_64
xorg-x11-server-Xorg-1.8.2-3.fc13.x86_64
kdebase-4.4.5-1.fc13.x86_64

xrandr can set the primary display:
$ xrandr --output VGA1 --primary
$ xrandr --output LVDS1 --primary

KDE Resize and Rotate systray app can pick up the primary display using "Multiple Monitors -> Identify All Displays".

However plasma does not appear to honour the primary setting. When both LVDS1 and VGA1 are enabled, the default panel is always on LVDS1.
Comment 16 Diego 2010-11-25 09:53:36 UTC
Ok, this is sort of fixed seeing bug #2417199 is closed for 4.6.
Unfortunately an issue remains: panel should always be on the primary monitor, elseway when you disconnect the secondary display the panel will be lost.

Suppose that you set internal laptop display to primary, but you move panel to an external monitor. Then when you will detach the external monitor internal laptop screen will remain primary, and will retain it plasma properties (background, plasmoids etc.). Unfortunately the panel is in the other "plasma screen", the one you just detached. This means you've lost you panel settings until you attach another screen.

There should be a way one can see all the "screens" (not appropriate term, but I hope plasma hackers understand me) tied to an activity, even if physical monitor is not actually attached. I hope I've explained the problem clearly. If not, please just ask.
Comment 17 Diego 2010-11-25 09:55:29 UTC
(In reply to comment #16)
> Ok, this is sort of fixed seeing bug #2417199 is closed for 4.6.

meant bug #241719 obviously.
Comment 18 Andrey 2010-11-25 13:44:20 UTC
(In reply to comment #16)
> Unfortunately an issue remains: panel should always be on the primary monitor,
> elseway when you disconnect the secondary display the panel will be lost.
> 
> Suppose that you set internal laptop display to primary, but you move panel to
> an external monitor. Then when you will detach the external monitor internal
> laptop screen will remain primary, and will retain it plasma properties
> (background, plasmoids etc.). Unfortunately the panel is in the other "plasma
> screen", the one you just detached. This means you've lost you panel settings
> until you attach another screen.

Hmm, I think it is expected behavior. Let me try to explain this.

1) You have primary screen, with 'primary' panels.
2) You have secondary screen with 'secondary' panels.

When you disconnect your monitor, you end up just with one monitor, which becomes primary and all your 'primary' panels are moved there. If this monitor is primary in both 1-monitor and 2-monitor modes 'primary' panels just sit on one screen and don't move anywhere. This is how it works, right?

But if you had also 'secondary' panels, they just disappear. And, as I think, it is the way it should work, because in 1-screen mode you now have different configuration with less screen real estate.

But maybe you still may want to have all that panels (you laptop screen is big enough or panels small enough). But here comes the problem: it is not clear where should 'secondary' panels land on the primary screen. Should they land on top of the 'primary' panels or cover them or move to some other part of the primary screen, when secondary screen is disconnected?
Comment 19 Diego 2010-11-25 14:17:03 UTC
(In reply to comment #18)
> When you disconnect your monitor, you end up just with one monitor, which
> becomes primary and all your 'primary' panels are moved there. If this monitor
> is primary in both 1-monitor and 2-monitor modes 'primary' panels just sit on
> one screen and don't move anywhere. This is how it works, right?
>

I think this is the problem: in plasma you can have multiple panels, and there's no concept of "main panel" (see comment #4). While this is good in the world of "you can do whatever you want", this is bad in the world of "I really don't want to lose my panel if I power down my laptop and bring it to a place where I don't have another monitor".

Let's find a solution with sane defaults.
Comment 20 Kai Uwe Broulik 2010-11-25 18:00:30 UTC
Can‘t this somehow be connected to Activities? So at work you have your notebook connected to your beamer and you want to have another panel on the second screen (I tend having a panel on each screen and set the window list to just show windows that actually are on that screen) or move different widgets over there because you don‘t really need them or want to have more space.
Then at home your notebook is running alone and you have all your widgets (or a few you don‘t need at all removed) on your notebook.
This could be a really good case for using activities I think. It should occurr automatically and configurable.
Or have an activity being able to handle multiple screen configurations, like notebook only -> have my set of widgets on the notebook only. Second monitor attached -> move some widgets over to the other screen and have a panel there and such.
Comment 21 Oded Arbel 2016-08-30 06:54:37 UTC
Likely related to Bug 356225
Comment 22 Nate Graham 2018-06-08 19:59:02 UTC
Hello!

This feature request was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this feature request is already implemented in Plasma 5, or is no longer applicable.

Accordingly, we hope you understand why we must close this feature request. If the requested feature is still desired but not implemented in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting

If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging

Thanks for your understanding!

Nate Graham