| Summary: | plasmoid.screen returns -1 in multiscreen setup | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Martin Klapetek <mklapetek> |
| Component: | generic-multiscreen | Assignee: | Aleix Pol <aleixpol> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | lbeltrame, mail, mgraesslin |
| Priority: | NOR | ||
| Version: | master | ||
| Target Milestone: | 1.0 | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/plasma-framework/e1051994addfc174b4919fdc12231957ad578177 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Bug Depends on: | |||
| Bug Blocks: | 328593 | ||
|
Description
Martin Klapetek
2014-05-08 09:32:00 UTC
Looking into it Git commit 2052b811403e52bb80d1abdaf87f91ae257e0e9c by Aleix Pol. Committed on 08/05/2014 at 13:38. Pushed by apol into branch 'master'. Remove hack for early initialization of PanelView This broke screenForContainment because the Panel didn't know where it would be placed when the panel is being set. This shouldn't be the case anymore. Related: bug 334502 M +3 -22 shell/panelview.cpp M +1 -1 shell/panelview.h M +4 -3 shell/shellcorona.cpp http://commits.kde.org/plasma-workspace/2052b811403e52bb80d1abdaf87f91ae257e0e9c This now returns the other screen --> I have this setup [Screen0 - 1920x1200][Screen1 - 1440x900] When the panel is at Screen0, I'm getting plasmoid.screen == 1, when the panel is on Screen1, I'm getting plasmoid.screen == 0 As such the notification popup now appears on the opposite screen than it's supposed to (which is where the panel with the applet is). Interesting. I'll investigate further. I've been trying to reproduce. I installed the hello world plasmoid and changed the text displayed into plasmoid.screen. I always get 0 on the primary screen and 1 in the not-primary. Note that I don't have a primary screen (xrandr below), I also still kinda experience the wrong panel placement, now it's just random. As you can see from the xrandr output, the position of the screen is known (1920x1200+0+0 vs 1440x900+1920+300), so I think this should not be as much about primary screen, but rather iterating the screens from left? That's the same as QScreen works I think. I'd like Martin G's input on this tho. Finally, this was working before, so it's a regression. --- DVI-I-1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 60.0*+ 1920x1080 60.0 1680x1050 60.0 1600x1200 60.0 1440x900 59.9 1280x1024 75.0 60.0 1280x800 59.8 1024x768 75.0 60.0 1024x576 60.0 800x600 75.0 60.3 640x480 75.0 59.9 HDMI-0 disconnected (normal left inverted right x axis y axis) DP-0 disconnected (normal left inverted right x axis y axis) DVI-D-0 connected 1440x900+1920+300 (normal left inverted right x axis y axis) 408mm x 255mm 1440x900 59.9*+ 75.0 1280x1024 76.0 75.0 72.0 60.0 1152x864 75.0 1024x768 75.0 70.1 60.0 800x600 75.0 72.2 60.3 640x480 75.0 72.8 59.9 640x350 70.1 DP-1 disconnected (normal left inverted right x axis y axis) You don't have any primary screen set there, then it randomly takes a primary screen. You should set a primary. You can do so by, for example: xrandr --output DVI-D-0 --primary KScreen daemon is responsible of doing this, I'm working on the KF5 port at the moment. I still don't think that plasmoid.screen == 0 should be the primary screen as the concept of screen numbers everywhere else is basically an iteration from top-left corner, so eg. screen 0 is the most top-left screen. I might be wrong though. Martin? To be honest: numbering screens doesn't make much sense. If one wants to properly do it, it would need to be a QString and the output name. That said: in KWin we use numbering with left to right. (In reply to comment #9) > That said: in KWin we use numbering with left to right. and is broken as I just noticed in our screens sub-menu :-) So yes, numbering sucks ;-) In plasma, 0 means primary, the rest is just how they're internally set up. We might want to predictably sort them, but it hasn't happened yet. Right, that's what the bug is about now - it used to be sorted as it was based on QScreen, now it's not -> it's a regression from the previous behavior. Actually, the bigger probelm which I forgot to mention is that now plasmoid.screen does not correspond with the panel it is in - the notification popup is on the *opposite* screen than the panel is at, while it should be the same. Can you point me to the usage of this API? It will be easier, otherwise I feel like I'm shooting randomly. Or a test, that would work too :). ping. plasma-workspace/applets/notifications - qml sets the plasmoid screen, the plugin then gets the screen size by the number. You can simply trigger a notification by notify-send. Enabling the 2nd screen here causes the following behaviour of plasmashell/kwin: - all windows remain on the secondary screen - the primary screen shows no wallpaper (black background, a wallpaper is configured for this containment), needs restart of plasmashell - plasmashell on the primary screen doesn't allow any interaction: - no reaction on right-clicking on the desktop - dragging applets to it just "swallows" them… they disappear when they're dragged there - the panel configured for the primary screen doesn't show up until I restart plasmashell, but then it shows up on the 2nd screen Does this sound like something for a separate bug or should I better wait for this one being resolved first? Enabling the 2nd screen using: /usr/bin/xrandr --output eDP1 --primary --auto --pos 528x1440 --output DP1 --auto --pos 0x0 "xrandr -q" output: Screen 0: minimum 320 x 200, current 2560 x 2520, maximum 32767 x 32767 eDP1 connected primary 1920x1080+528+1440 (normal left inverted right x axis y axis) 294mm x 165mm 1920x1080 60.0*+ 40.0 1400x1050 60.0 1280x1024 60.0 1280x960 60.0 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm 2560x1440 60.0*+ 1920x1200 59.9 1920x1080 60.0 60.0 50.0 59.9 24.0 24.0 1920x1080i 60.1 50.0 60.0 1600x1200 60.0 1680x1050 60.0 1280x1024 75.0 60.0 1280x800 59.8 1152x864 75.0 1280x720 60.0 50.0 59.9 1024x768 75.1 60.0 800x600 75.0 60.3 720x576 50.0 720x480 60.0 59.9 640x480 75.0 60.0 59.9 720x400 70.1 VIRTUAL1 disconnected (normal left inverted right x axis y axis) I would open a new bug report, it's unrelated to the issue discussed here, still sounds like an important issue. On the other hand, it sounds like a bug in Qt, but we can investigate it further in a separate bug report. Git commit e1051994addfc174b4919fdc12231957ad578177 by Aleix Pol. Committed on 17/06/2014 at 14:02. Pushed by apol into branch 'master'. Ensure that the containment's corona is properly calculated. The used corona is either the containment's parent or, in case the parent is an applet, it's containment's corona. With this change we ensure the proper corona is always found. This change requires screenContainment to be able to walk through the object tree in case it's not a containment directly managed by it. M +14 -11 src/plasma/containment.cpp http://commits.kde.org/plasma-framework/e1051994addfc174b4919fdc12231957ad578177 Git commit b5589fe3da15b486e26e4b21ca72537ca51136e1 by Aleix Pol. Committed on 17/06/2014 at 13:57. Pushed by apol into branch 'master'. Recursively figure out the screen a containment is in If a containment is in an applet, then recursively ask for the screen until we get to an actual root containment that can tell us the screen. M +9 -0 shell/shellcorona.cpp http://commits.kde.org/plasma-workspace/b5589fe3da15b486e26e4b21ca72537ca51136e1 |