Bug 335710

Created attachment 86968 [details]
screenshot where taskmanager shows windows from the other screen

BTW, as panels where swapped on login, I moved them manually.

Do you have a primary screen set?
If you're not sure can you copy and paste the output of "xrandr -q"

Yes,

Primary screen is DVI-I-1 (and it is correct)

$ xrandr -q
Screen 0: minimum 8 x 8, current 2704 x 1280, maximum 16384 x 16384
DVI-I-0 disconnected (normal left inverted right x axis y axis)
DVI-I-1 connected primary 1680x1050+1024+115 (normal left inverted right x axis y axis) 474mm x 296mm
   1680x1050      59.9*+   60.0  
   1280x1024      75.0     60.0  
   1280x960       60.0  
   1152x864       75.0  
   1024x768       75.0     70.1     60.0  
   800x600        75.0     72.2     60.3     56.2  
   640x480        75.0     72.8     59.9  
DP-0 connected 1024x1280+0+0 left (normal left inverted right x axis y axis) 338mm x 270mm
   1280x1024      60.0*+   75.0  
   1280x960       60.0  
   1152x864       75.0  
   1024x768       75.0     70.1     60.0  
   800x600        75.0     72.2     60.3     56.2  
   640x480        75.0     72.8     59.9  
DP-1 disconnected (normal left inverted right x axis y axis)

However, I did not defined it when I rotated the screen. Screen is configured with a script in
/etc/X11/xinit/xinitrc.d/xrandr.sh

xrandr --output DP-0 --rotate left
xrandr --output DP-0 --left-of DVI-I-1

I did not used this command anywhere:

xrandr --output DVI-I-1 --primary 

I know nothing about other process that used an xrandr call to define it.

I added "xrandr --output DVI-I-1 --primary" just to make it sure. No change.

Git commit 26ac36e27d26518d3063a2f577b42f0b35374462 by Marco Martin.
Committed on 17/06/2014 at 13:21.
Pushed by mart into branch 'master'.

fire adaptToScreen only once

this makes the desktops and panels more deterministically
follow the primary screen
* adaptToScreen is useless per se in moveEvent, but what's worse will cause a recursion loop
* disconnect the geometry sync from the old screen

M  +6    -7    shell/desktopview.cpp
M  +1    -1    shell/desktopview.h

http://commits.kde.org/plasma-workspace/26ac36e27d26518d3063a2f577b42f0b35374462

Still happens with freshest build.

What I'm seeing now is that the panel is *always* moved from the bigger screen to the smaller (from left to right) on startup.

No primary in my setup.

Can you please test reverting a1a985c1f52796a95774908abc363f43d572c1f4 ?

It might have made things worse...

Doesn't seem to help - first time panel is placed properly, but next times it's always one the smaller screen (the one on the right).

I'm seeing this too. At random one or more panels are all placed on the left screen (3 screen setup).

Sometimes even desktops are swapped (but this is likely a different bug, which I'll report later separately).

Git commit fa3126f716f3940f46f6ede09d2c24caed27c63a by Aleix Pol.
Committed on 20/06/2014 at 17:47.
Pushed by apol into branch 'master'.

Improve how we figure out the screenGeometry for a screen

Leverage on the vector position rather than looking through it, this way
it works even before the containment is set.

M  +7    -7    shell/shellcorona.cpp

http://commits.kde.org/plasma-workspace/fa3126f716f3940f46f6ede09d2c24caed27c63a

I created this test plasmoid:
kde:scratch/apol/plasma-screentest

Can somebody add it to all their views and panels and tell me if they find any kind of mismatch? When you do,  I'd need the steps it took to get there, so I can reproduce finally.

In data lunedì 23 giugno 2014 15:21:12, hai scritto:

> Can somebody add it to all their views and panels and tell me if they find
> any kind of mismatch? When you do,  I'd need the steps it took to get

I will be doing so tonight: I'll report back once I do.

In data lunedì 23 giugno 2014 15:21:12, hai scritto:

> any kind of mismatch? When you do,  I'd need the steps it took to get
> there, so I can reproduce finally.

At first startup screen IDs do not match the layout.

I have this script which sets the layout at the display manager level:

xrandr --output DisplayPort-0 --mode 1280x1024 --pos 1280x0 --rotate normal \ 
--primary --output DVI-1 --mode 1280x1024 --pos 2560x0 --rotate normal \
--output DVI-0  --mode 1280x1024 --pos 0x0 --rotate normal \
--output HDMI-0 --off

And the layout is 

Left: DVI-0
Center: DisplayPort-0
Right: DVI-1

Under *normal* operations, using this plasmoid and placed both in the panel 
and on the screen itself, the IDs are

Center: 0
Left: 1
Right : 2

What I did:

- log out
- log back in

At login, the situation is as follows, compared to the expected:

Left: 0
Center: 1
Right :2

Upon quitting and restarting plasmashell, *sometimes* (it doesn't always 
happen) the screen numbers are then correctly positioned (see above).

The mismatch always happens between the left and the center screen. The right 
screen is unaffected.  Panels OTOH always end on screen number 0 (on the 
left).

Additionally, plasmashell startup shows

requesting unexisting screen 2
[...]
requesting unexisting screen 2

repeated for a while.

In data lunedì 23 giugno 2014 15:21:12, hai scritto:

> Can somebody add it to all their views and panels and tell me if they find
> any kind of mismatch? When you do,  I'd need the steps it took to get

A close/restart of plasmashell can get the wrong screen IDs without logging 
off and on. After a restart, screen IDs were swapped again.

Just got the same swap as in Comment 15

Will try an test it with 3 screens...

Ok, been playing with it, managed to reproduce. The problem is that Qt is calling QWindow::screenDestroyed that goes crazy and starts to move screens around so that they don't end up floating in the screenless space.

I pushed new API to keep track of this problem [1], meanwhile I'll push a workaround.

[1] https://codereview.qt-project.org/#/c/88351/

Git commit d299e849ba8480b0ee1ae4cbd7664a6078b46534 by Aleix Pol.
Committed on 25/06/2014 at 14:48.
Pushed by apol into branch 'master'.

Make sure we get to decide where our panels go

Workaround a lack of API from Qt where it will decide to move the panels
around without us being able to control it.
This patch overrides the QWindow::screenDestroyed slot to be able to decide
where to move the Panel or whether it needs to be removed. This is
considered a workaround and should be removed once the new API is in and
released.

See also: https://codereview.qt-project.org/#/c/88351/

M  +14   -0    shell/panelview.cpp
M  +1    -0    shell/panelview.h
M  +14   -10   shell/shellcorona.cpp
M  +3    -1    shell/shellcorona.h

http://commits.kde.org/plasma-workspace/d299e849ba8480b0ee1ae4cbd7664a6078b46534

In data mercoledì 25 giugno 2014 14:50:10, hai scritto:
> https://bugs.kde.org/show_bug.cgi?id=335710

I don't feel like reopening this because this may be just me, but at least at 
the moment this commit does not fix the issue. At startup panels are still 
arranged randomly (and so are desktops). 

Restarting plasma-framework does keep the randomness.

I'm not sure I'm fully up to date so I'll follow up later to make sure this 
persists, or I was not up to date enough (hopefully the latter).

I've done more tests and the behavior is not deterministic, still.

At first startup: 

- panels set on screens, but on wrong order (desktops aren't in the right order)

Closing and restarting plasmashell:

- panel position is random, often all stacked on the leftmost screen

Thanks for testing, I'll try again tomorrow.

Just for reference, the revision I tested this with was e70aa21 in plasma-workspace.

Git commit 5fae6f76d30f10ebc5c3e757f61874bcd27b1668 by Aleix Pol.
Committed on 08/07/2014 at 00:07.
Pushed by apol into branch 'master'.

Simplify screen change reaction

Only let the containment store the last screen when the screen changes or
the view is shown.
Only listen to screenChanged once.

M  +7    -8    shell/panelview.cpp

http://commits.kde.org/plasma-workspace/5fae6f76d30f10ebc5c3e757f61874bcd27b1668

There seems to be a commit after you last commented. Luca is it still problematic?

There seems to be a commit after you last commented. Luca is it still problematic?

On 06 agosto 2014 13:26:56 CEST, David Edmundson <kde@davidedmundson.co.uk> wrote:
>
>--- Comment #26 from David 
>There seems to be a commit after you last commented. Luca is it still
>problematic?

I will check again shortly (on my phone), the behavior is now slightly different.
 It doesn't look solved but I will check again.

In data mercoledì 06 agosto 2014 11:26:56, hai scritto:

> There seems to be a commit after you last commented. Luca is it still
> problematic?

Panels still appear randomly (and never on the third screen) on startup, but 
the behavior has now changed.

By "changed" I mean that if I bring up the panel controller for one of the 
misplaced panels, said controller appears on the *right* screen, unlike the 
panel it refers to.

Example:

panel that should be on screen 3 appears on screen 1. Click on the icon to 
bring up the panel controller -> panel controller appears on the correct 
screen (screen 3).

I use it to quickly workaround the issue, as dragging the screen edge control 
on the panel controller will instantly move the panel to the right position.

But as far as the bug goes, panel placement is still semi-random:

- Never appears on screen 3
- The third panel is often overlapping either on screen 1 or screen 2
- The primary panel (screen 1) sometimes still ends up on screen 2.

Except for the third panel/screen, I can confirm that behaviour. Especially the part that the control for the panel appears on the correct screen, but the panel itself does not.

Just got it swapped. Sometimes, a panel disapears, I create a new one and it appears back on a following session (showing the old previously missing one and the new one).

In my multiscreen setup, the current master behavior is that one of my two screens is disabled after login and I have no panel. After I enable the second screen through kscreen, the panel then appears on the first screen (where it should be).

Git commit 9da8d520d2624985d9a027d255c94722173eb0a7 by Aleix Pol.
Committed on 18/08/2014 at 15:56.
Pushed by apol into branch 'master'.

Loop through the outputs to figure out what is the primary output

The primaryOutput method in KScreen is not consistent with Output::isPrimary
and made plasma shell become a bit inconsistent too.
Loop through the outputs for now, until we've got a better solution.
Related: bug 338109

M  +21   -11   shell/shellcorona.cpp
M  +1    -0    shell/shellcorona.h

http://commits.kde.org/plasma-workspace/9da8d520d2624985d9a027d255c94722173eb0a7

FYI, today, on login, I got everything swapped. Kickoff does not appear in the screen I clicked (but the other), panels where swapped, fullscreen size on the "taller" screen is limited to the shorter screen height. Task manager in panel shows the other screen windows. I'll post a screenshot.

I'm not using the "today patch by apol" yet. As I'm using OpenSuSE OBS packages, I'll wait a day or two to get new packages with the patch.

Created attachment 88308 [details]
New screenshot with everything swapped

BTW, the left screen is always started offline on login. After some seconds, with no intervention, it just turns on. Anyway, for the window manager, the screen was on (as I can move the mouse and windows to and from it).

FYI, I still have the same problem. All panels move to the left most screen on login.

Also, the panel sizes match the screen width they supposed to be. The right screen panel shown in the left screen has the same width of right screen. This way, I cannot see the end of the panel. I still can open the panel config menu using popup menu.

I can move the misplaced panel after login without problem and it works flawlessly until next boot.

I'm running plasma plasma-framework-5.4.0git-48.1.x86_64 from OpenSuSE OBS

Just as a heads up: I no longer see this in master, after Aleix's latest patch 
for panels.

This still happens to me, more often after having KScreen5 installed. After login both panels are on the left (primary) monitor, overlapping each other.

I'm on openSUSE 13.1 with the Frameworks repository.

In data venerdì 24 ottobre 2014 06:56:49, hai scritto:

> This still happens to me, more often after having KScreen5 installed. After
> login both panels are on the left (primary) monitor, overlapping each other.

To be clear: the issue is no longer present (for me) using git *master* - 
which means Plasma 5.2 when it'll be out - , because that is where the changes 
were committed. 

– 
Luca Beltrame - KDE Forums team
KDE Science supporter
GPG key ID: 6E1A4E79

Ah, I see, the openSUSE repository is using Plasma 5.1.0 at the moment.

@Dainius, 

You can try the unstable repo at:

http://download.opensuse.org/repositories/KDE:/Unstable:/Frameworks/openSUSE_13.1/x86_64/

Should be fixed now, closing for now, re-open if appears after getting Plasma >=5.1.1.

I keep getting that the panel keeps going to the left most monitor of my 3 monitors, no matter which one I set as the primary output. If I remove the left panel and create on on the middle screen and reboot, the panel will always move to the left screen. I am on plasma-desktop 5.6.0-1 (arch linux)