| Summary: | In xinerama mode, kwin doesn't respect the panel (and maximizes windows so that they overlay the panel) | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Bernd Steinhauser <linux> |
| Component: | xinerama | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Bernd Steinhauser
2008-01-05 22:47:26 UTC
Forgot to add: The panel on the second screen doesn't work for "smart moving or resizing". (It won't snap to the panel, so resizing is completely manual work.) But maybe that is more related to the other bug I reported, see bug 155159. bug 155159 has been resolved, but this issue remains (the second taskbar was just a fake bar, that shouldn't have been there at all). One note, that might be helpful. I can drag items (windows, applets) through the taskbar. On a non-xinerama screen they get dropped. (Meaning, that when on a non-xinerama computer I drag sth. below the taskbar, the cursor will release it and it stays there, when I do that on a xinerama setup it doesn't get released and I can drag it through the bar, or back etc.) While this is a wanted behaviour (if you have got a panel between screens, which wasn't really possible with KDE3) it might or might not be related to this behaviour. What are the steps to reproduce the problem? I don't exactly know if there are steps to reproduce this problem. First, I have got a rather unusual xinerama setup, it basically looks like this http://www.bernd-steinhauser.de/xinerama-kde4-panel.png Ignore the wrong panel in the upper screen, that has been fixed and is gone. The panel in the lower screen is of course still there and behaves the same. I did now place a real panel in the upper screen, this panel behaves just like the first panel and didn't affect the behaviour in this bug, but it showed me, that I can do the things I described in comment 3, which (and I tested this) is not possible to do when I am in non-xinerama mode (tested on the same computer and on another one). The xinerama is setup with ATI's Bigdesktop, the important part in xorg.conf looks like this: Option "DesktopSetup" "vertical,reverse" Option "EnableMonitor" "lvds,crt1" Option "Mode2" "1600x1200" This will make xrandr --verbose spit things out like: Screen 0: minimum 320 x 200, current 1600 x 2400, maximum 1600 x 2400 default connected 1600x2400+0+0 (0x8f) normal (normal) 0mm x 0mm Identifier: 0x8e Timestamp: 87130477 Subpixel: no subpixels Clones: CRTC: 0 CRTCs: 0 1600x2400 (0x8f) 230.4MHz h: width 1600 start 0 end 0 total 1600 skew 0 clock 144.0KHz v: height 2400 start 0 end 0 total 2400 clock 60.0Hz I already compared the kwin output with the one of my other computer and it doesn't show anything unusual, as far as I can tell, but I'll attach one, if needed. I don't really know what actually could trigger this, obviously you need a multimonitor setup. But normally the two things, that are "unusual" in my setup are the different sizes of the two screens (1600x1200+1280x800) and the vertical setup. BTW, in KDE3 the setup works perfectly and kicker (or any external taskbar) gets respected during maximizing, so it is definitely a KDE4 problem. ;-) I made two more screenshots to show the actual problem: The first screen shows, that new windows sometimes spawn (partially) behind the panel. http://www.bernd-steinhauser.de/xinerama1.png The second screen shows what happens if I maximize a window. http://www.bernd-steinhauser.de/xinerama2.png You can see, that the window really is maximized, by the maximizing button in the corner. If I resize it, so it matches the free screen area it shows, that it is not maximized. I took the upper screen, but it is true for both screens, with and without the panel in the upper screen (I added that manually). Ok, I did a little bit more testing and I found out what the reason for this is. I changed: - Option "DesktopSetup" "vertical,reverse" + Option "DesktopSetup" "horizontal,reverse" Now maximizing works. The problem seems to be, that I use a vertical screen setup and not, like most people do, a horizontal setup. I hope, that is useful information. ;) Ok, I installed the open source driver and using xrandr 1.2 I can change the layout using --above and --left-of and it happens there, too, so this is definitely not a driver bug. The funny thing is, if I change from --left-of with a (correctly) maximized window opened to --above it will "remaximize" the window to the whole screen. With a quite recent revision (775056) it is better, the maximizing on the first screen works without problems. Only on the second screen there are still problems. Checked latest svn and this problem seems to be fixed, most likely by this revision: http://websvn.kde.org/?view=rev&revision=786175 So this bug report might be marked as being fixed. On fortunately there have been other bugs introduced, for example moving windows through the panel is only working in one direction. (Or actually window placement on the first screen is completely broken.) Fixed in Plasma. Please create new reports for new issues. |
