| Summary: | Can't drag windows on the first screen in a multi-desktop setup when the second screen is in rotated mode | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Lingxiao Fu <flyshowflx> |
| Component: | multi-screen | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | kde.org, ShengGe.Ding |
| Priority: | NOR | ||
| Version First Reported In: | git master | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
The one-single-desktop-one-rotated-SLD setting
strut Screensize debugger (QDesktopWidget dump) |
||
|
Description
Lingxiao Fu
2012-09-13 07:26:02 UTC
Created attachment 73880 [details]
The one-single-desktop-one-rotated-SLD setting
http://standards.freedesktop.org/wm-spec/wm-spec-1.5.html#id2578550 "_NET_WM_STRUT_PARTIAL [blablablahh] Struts MUST be specified in root window coordinates, that is, they are not relative to the edges of any view port or Xinerama monitor. [blablablahh]" -> please post the outputs of "xwininfo -root -display :0.0" and "xwininfo -root -display :0.1" I changed the category since i understood you're not really using a multihead setup (ie. two separate servers and two different kwin instances) but just xinerama multiscreens, correct? To me it looks like a multi-head setup as it mentions DISPLAY 0.0 and DISPLAY 0.1. This needs to be clarified. Especially as it's to be expected that one cannot move a window from 0.0 to 0.1. don't know how this works on fglrx, but
> the desktop geometry is the union of the 2 screens, which is (0, 0, 1919, 3839)
does not sound like mulithead (and does not look like the screenshot setup either, btw. - should be 3000x3840+0+0, shrug)
To my knowledge, fglrx disables Xinerama as default when multiple (physical) screens are connected to the ASIC since Xinerama migh conflict with Xrandr. As for the screenshot setup, the X server sees 2 (logical) screens, Monitor 1 as a single desktop and Monitor 2 and 3 as a whole large rotated desktop. So there is only 1 Xorg process but 2 kwin and 2 plasma-desktop processes corresponding to the 2 screens. I'm not trying to drag window from DISPLAY :0.0 to DISPAY :0.1 cuz Xinerama is disabled. The problem I encountered is that no windows are able to be dragged within DISPLAY :0.0; when I grab the window's the titlebar I can see the transluscent window effect and the cursor turns to a hand, but the window just dose not move as I move the cursor. I'll post the xwininfo output when I get back to my setup. (In reply to comment #2) > don't know how this works on fglrx, but
> > the desktop geometry is the union of the 2 screens, which is (0, 0, 1919, 3839)
> does not sound like mulithead (and does not look like the screenshot setup
> either
This value is what Kephal::ScreenUtils::desktopGeometry() says for the screenshot setup.
changing back to multi-head according to comment #5 Let me recap. You have three screens A, B, C A is running one X Server B and C are running another X Server and are rotated After re-reading it sounds like you want to move a window from screen a to screen B or C. Is that correct? With the setup as described you can only move windows between screens B and C, but not between A and other screens. From Comment #5 > I'm not trying to drag window from DISPLAY :0.0 to DISPAY :0.1 cuz Xinerama is disabled. From OP: > 3. Simply killing plasma-desktop on DISPLAY :0.0 would enable window dragging again. > 4. Remove the bottom panel holding the task manager on DISPLAY :0.0 would also enable window dragging. it's not that, the problem is that: (from OP) > 3. When the panel holding task manager is being instantiated, the desktop geometry is used in void PanelView::updateStruts() to calculate the panel's strut. Here strut.bottom_width is evaluated to 2795 (desktop height 3840 - this screen height 1080 + panel height 35 = 2795). The PanelView sets a bottom strut of 2795 pixels, because it believes the screen is 3840px high but that is :0.1 while :0.0 is just an ordinary FullHD screen. Netwm spec talks about "logical screen" in context of struts, what -at first thought- i'd not apply to multi-head. There're two logical screens DISPLAY :0.0 (x1:0, y1:0, x2:1919, y2:1079) DISPLAY :0.1 (x1: 0, y1: 0, x2: 1079, y2: 3839) Which would obviously overlap if they were one "logcal screen" what is of course not the case, since it's a multihead setup. I would not bet around, but carefully claim the PanelView to be wrong. @Lingxiao Since this is a pretty exotic setup, could you try how other NETWM compliant WMs treat the struts (eg. openbox, compiz, metacity)? Since Lingxiao delivers this issue to me, I test compiz under Ubuntu 12.04.: 1. the single display desktop is white screen.(another issue for compiz...) 2. windows on it can be dragged. 3. Sorry for that I'm not familiar with compiz and can't tell how it treats struts. I agree with Thomas(In reply to comment #9) > I would not bet around, but carefully claim the PanelView to be wrong. the attachment is my point of view. So the windows on monitor 1 can't be dragged at all. Created attachment 76300 [details]
strut
none
That cause more questions then answers ^^ (In reply to comment #10) > Since Lingxiao delivers this issue to me, I test compiz under Ubuntu 12.04.: ok, you're using *compiz*, NOT *kwin* (those are different windowmanagers, each with integrated compositor) > 1. the single display desktop is white screen.(another issue for compiz...) i assume this is an unreelated issue. > 2. windows on it can be dragged. so you say if you use compiz & plasma on this setup, windows on panel 1 can be dragged around, correct? If you maximize one, does it respect the panel strut (is the panel overlapped?) > 3. Sorry for that I'm not familiar with compiz and can't tell how it treats > struts. no need of familarity, using it or another WM is sufficient ^^ (In reply to comment #12) > so you say if you use compiz & plasma on this setup, windows on panel 1 can > be dragged around, correct? > If you maximize one, does it respect the panel strut (is the panel > overlapped?) because the monitor 1 is white screen, i'm not sure there is a panel or not. windows can be dragged, and maximize one will cause it hiding behind the white screen... > no need of familarity, using it or another WM is sufficient ^^ i will try my best if i can help:) (In reply to comment #0) > 5. Similar issue can be observed in a > two-display(one-single-desktop-one-rotated-desktop) setting as long as the > shorter screen is DISPLAY :0.0, only that the window is not unable to be > dragged at all but in a limited area(the upper 200-or-so-pixel-high-area > according to actual height of the bottom panel). what does this mean? Any idea if the bug is in Plasma or KWin? (In reply to comment #14) > Any idea if the bug is in Plasma or KWin? From the NETWM spec i'd say the panel is wrong - but the NETWM spec is not known for being "explicit". What is mostly required at this moment is information about how other WMs treat such "weird" struts - if every major WM but KWin deals them more "gracefully" then, NETWM words be as they want, KWin should as well. If not, the panelView needs to be fixed (because there's no point in KWin working around a client bug which the next WM will then expose) Comment #13 seems to suggest that compiz allows to drag (as kwin would in uncontrolled, ie. alt+lmb mode) but behind a white space (what's not a reasonable behavior either) The "problem" here is the exotic setup with two panels in one and a third panel in another screen. The layout as suggested in https://bugs.kde.org/attachment.cgi?id=76300 does not exist because screen 1 is completely independent from screen combo 2&3 Both screens start at (0,0) and QApplication on Screen 1 has no access to screen combo 2&3, so i wonder whether QDesktopWidget on screen 1 would indeed figure a height of 3840 @Lingxiao or ShengGe Do you need some test code to figure the dimensions reported by QDesktopWidget? (In reply to comment #15) > The "problem" here is the exotic setup with two panels in one and a third > panel in another screen. > The layout as suggested in https://bugs.kde.org/attachment.cgi?id=76300 does > not exist because screen 1 is completely independent from screen combo 2&3 > Both screens start at (0,0) and QApplication on Screen 1 has no access to > screen combo 2&3, so i wonder whether QDesktopWidget on screen 1 would > indeed figure a height of 3840 since i believe you are totally right, it's odd that the dimensions actually seems to be calculated in that way. following comment also proves it. (In reply to comment #0) 5. Similar issue can be observed in a two-display(one-single-desktop-one-rotated-desktop) setting as long as the shorter screen is DISPLAY :0.0, only that the window is not unable to be dragged at all but in a limited area(the upper 200-or-so-pixel-high-area according to actual height of the bottom panel). > @Lingxiao or ShengGe > Do you need some test code to figure the dimensions reported by > QDesktopWidget? i remember that LingXiao has debugged into source code and verify the dimensions, while i'd like to figure them with your tools for double check. Created attachment 76635 [details]
Screensize debugger (QDesktopWidget dump)
Please try the attached program on either screen (0.0 and 0.1) and share the output.
(In reply to comment #17) > Created attachment 76635 [details] > Screensize debugger (QDesktopWidget dump) > > Please try the attached program on either screen (0.0 and 0.1) and share the > output. the out put is as following: primary screen: 0 the desktop is virtual: false desktop geometry: QRect(0,0 1080x3840) Screen 1 (geometry/available): QRect(0,0 1920x1080) / QRect(0,0 1920x3840) Screen 2 (geometry/available): QRect(0,0 1080x3840) / QRect(0,0 1920x3813) Sorry for the delay. (In reply to comment #18) > Screen 1 (geometry/available): QRect(0,0 1920x1080) / QRect(0,0 1920x3840) So, Qt believes there's 1920x3840px available space on a 1920x1080px screen.... aaaa-haaa. Is this with or without the oversized panel (ie. plasma-desktop on that screen) sorry for late response. let's simply talk the case in the first attachment, the display 1(monitor 1) has panel, the display 2 ( monitor 2+3) has no panel:)
> Is this with or without the oversized panel (ie. plasma-desktop on that
> screen)
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone! Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone! This issue report is quite old. Can you please confirm, that it still persists with Plasma 5.23? Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |