Bugzilla – Bug 310208
misplaced panel on widescreen displays
Last modified: 2008-05-27 21:22:09 UTC
After install a openSUSE 10.3 beta3 on a laptop with widescreen display and login to GNOME session the panel is missplace somewhere on the screen (looks as on the position for a 1024x786 display). Because of the missplaced panel also maximse windows (as e.g. xterm) show a strange behavior. I could reproduce the problem on several widescreen displays as user and root.
Created attachment 163834 [details] screenshot with missplaced panel
Created attachment 163836 [details] screenshot with missplaced panel and maximised xterm Screenshot with missplaced panel and maximised xterm if xterm window was placed before in the top left part of the screen above of the panel
Created attachment 163837 [details] screenshot panel and maximised xterm right side Screenshot with missplaced panel and maximised xterm if xterm window was placed before in the top right part of the screen (right of the panel)
whats the output of xrandr?
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 1680 x 1680 VGA disconnected 1024x768+0+0 (normal left inverted right) 0mm x 0mm 1024x768_60 60.0* LVDS connected 1680x1050+0+0 (normal left inverted right) 331mm x 207mm 1680x1050 60.1*+ 60.0 58.9 1600x1024 60.0 1400x1050 60.0 1280x1024 60.0 1280x960 60.0 1152x768 54.8 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 TV disconnected (normal left inverted right)
Ok, I suspect the issues is that two screens are marked in use.
In KDE it works as expected and they are not marked as used. The first one is marked as disconnected.
Danny, could you please attach the output of xdpyinfo and of "gconftool-2 --dump /apps/panel"?
Also, could you please post a screenshot of SaX2's "dual head settings" window?
Hmm, unless those questions yield something obvious, this will require some logging to be added to gnome-panel; the code for multiscreen support is a bit convoluted. I'll work on it.
Created attachment 164192 [details] output of xdpyinfo
Created attachment 164193 [details] output of the requested gconf dump
Created attachment 164194 [details] screenshot of the sax2 settings
See also bug #272715.
Danny, could you please install the package here: http://download.opensuse.org/repositories/home:/federico-mena/openSUSE_10.3/ Please restart your session, and after the panel starts up, send a SIGUSR1 to the gnome-panel process. You'll get a ~/panel-debug-log-xxxxxxx.txt file. Could you please attach that file here?
Created attachment 175724 [details] panel-debug-log
xrandr still looks the same.
and yes, "xrandr --output VGA --off" "fixes" the issue.
*** Bug 272715 has been marked as a duplicate of this bug. ***
*** Bug 335520 has been marked as a duplicate of this bug. ***
I can replicate this in gnome. To make tihngs more fun, this happens also in xfce4.
Created attachment 182696 [details] xfce4 suffering from the same problem
Created attachment 182698 [details] output of xrandr (JosefAssad, vanilla 10.3, no remedial steps taken to address this issue yet)
Keith Packard says that this is an bug in the Intel driver; initially it mis-detects that VGA is connected, then goes back to thinking that it isn't. That's why it reports a monitor on the VGA output. On the other hand, GTK+ sees is that there are two monitors which *overlap*: Screen 0 has 2 monitors: Monitor 0: x=0, y=0, w=1024, h=768 Monitor 1: x=0, y=0, w=1680, h=1050 I.e. they are both at (0, 0) even though they are of different sizes. This is an implementation detail of how XRandR does "clone the display". I'm not sure if GTK+ should do anything special here... will keep investigating.
Note to self: xrandr(1) says: VGA disconnected 1024x768+0+0 (normal left inverted right) 0mm x 0mm 1024x768_60 60.0* LVDS connected 1280x800+0+0 (normal left inverted right) 0mm x 0mm 1280x800 59.9*+ See what the "+" in "59.9*+" means; read the source to xrandr(1) to see how it gets that from the API. Does that mean "this is the primary monitor"? We can probably work around this in gnome-panel if we can detect overlapping monitors *and* a primary monitor.
Oh, the "+" means "preferred modeline", while "*" means "currently active modeline". Note to self: The panel has a default of /apps/panel/toplevels/monitor = 0 (defined in panel-toplevel.schemas). + Check if a new panel configuration indeed uses that "0" to pick which monitor will be used for the panel's geometry. + To avoid breaking new users, and to un-break existing users, try a heuristic like if (there_are_overlapping_monitors (panel_toplevel->monitor)) { m = find_largest_overlapping_monitor (); set_geometry (panel_toplevel, m); }
This behavior also manifests itself in fluxbox. The fluxbox taskbar displays just fine, but apps (thunderbird, konsole, etc.) maximise to a subset of screen width.
In gnome, xrandr --auto fixes it for the session. No effect in fluxbox.
CCing Stefan. Stefan, I talked to Keith Packard and he mentioned a problem in the Intel driver, where on some laptops it will mis-detect that the VGA output is connected. Do you know anything about this problem? Thanks :)
No, this is another issue. By default the projector support for randr12 drivers is enabled by running xrandr in /etc/X11/xdm/Xsetup to set a 1024x768 mode for the external output. Unfortunately gdm seems to see a Xinerama setup now and sometimes chose the wrong display to be the first display. xine and vlc have the same problem when switching to fullscreen mode. I'm not sure hwo this can be handled correctly at all. See also Bug #343858.
*** This bug has been marked as a duplicate of bug 343858 ***
I'll reopen this; the bug is due to the same cause as GDM's, but this one needs a different patch, specific to gnome-panel.
Created attachment 185193 [details] gnome-panel-bnc310208-buggy-intel-xinerama.diff Tentative patch
Can the people who experience this bug please test the gnome-panel packages here: http://download.opensuse.org/repositories/home:/federico-mena:/10.3/openSUSE_10.3/ It's a similar fix to GDM's (bug #343858); let's see if it works for the panel.
cjp@workstation6l:~> rpm -qa | grep gnome-panel gnome-panel-lang-2.20.0-3.1 gnome-panel-2.20.0-3.1 gnome-panel-devel-2.20.0-3.1 gnome-panel-extras-2.20.0-3.1 gnome-panel-doc-2.20.0-3.1 cjp@workstation6l:~> Actually it does _fix_ the panel not the problem. With the original gnome-panel packages from factory I can unlock the panel and pull it down to the edge of the display, where it takes on full size as well and then lock it there. Likewise applications when pulled below the 1024*768 border and then maximized take on the full screen size. With the testing gnome-panel packages the panel is now _confined_ to the 1024*768 footprint and applications disappear when minimized. Also this doesn't take care of Control Center/Screen Resolution which still offers _only_ 1024*768 as resolution. ( There should be a range of resolutions all the way down to 320*200, shouldn't there ?)
Re comment #37 Disregard "and applications disappear when minimized.", it seems the panel items get rearranged, so the window list gets squeezed to the utmost right where it can't expand to show the applications registered.
While of course getting the gnome panel fixed is a step forward, the behavior I've described goes beyond the gnome panel what with fluxbox and xfce displaying the same problem. Then again, this bug _is_ about the panel, so conceivably fixing the panel itself would close the bug but not resolve the underlying issue. Should I open another bug?
(In reply to comment #37 from Casual J. Programmer) > With the testing gnome-panel packages the panel is now _confined_ to the > 1024*768 footprint and applications disappear when minimized. Can you please create a log file just like before and attach it here? The code is supposed to pick the largest resolution; maybe I screwed something up... > Also this doesn't take care of Control Center/Screen Resolution which still > offers _only_ 1024*768 as resolution. ( There should be a range of resolutions > all the way down to 320*200, shouldn't there ?) Hmm, that capplet probably needs a more specific fix, one that really pays attention at RANDR. I'm thinking that maybe the "just use the biggest monitor" hack needs to go into GdkScreen, but first we need to see why the panel isn't working.
Created attachment 185313 [details] gnome-panel logfile
Created attachment 185316 [details] gnome-panel-bnc310208-buggy-intel-xinerama.diff I'm a big fat idiot. This should fix the problem with the panel. I'll post a link to a package shortly...
OK, there's an updated gnome-panel package here: http://download.opensuse.org/repositories/home:/federico-mena:/10.3/openSUSE_10.3/ Could you please give it a try? This should fix the panel's position. I'm not sure that it will fix maximized windows; the panel struts will be correct, but Metacity keeps its own view of the available monitors.
This is somewhat weird. On first try the panel is completely out of sight, not reachable. ps -a shows it's running though ( A terminal can be started via context menu of desktop ). After reboot the panel docks to the top edge of the screen. I can move it to the left edge, but not bottom or right. Applications take the 1024*768 footprint, but can be dragged outside and maximized to full size (1280*800). Appending a logfile.
Created attachment 185331 [details] gnome-panel logfile
Two more observations: 1. when booting, before login screen appears, the cursor flickers between two points around the center of the screen. Probably center of 1024*768 and 1280*800. 2. After logging in, the splash screen shown while loading the panel has 1024*768 footprint.
After updating from factory this morning this is partially fixed. Login screen full size Panel full size Applications expand to full size Control Center / Screen Resolution now set to 1280*800, alas still fixed. I.e. 1280*800 is only resolution available. openSUSE 11.0 (i586) Alpha0 VERSION = 11.0 2.6.24-rc3-git1-2-default gnome-panel-2.20.0-36 gnome-panel-doc-2.20.0-36 gnome-panel-lang-2.20.0-36 gnome-panel-extras-2.20.0-36 gnome-panel-devel-2.20.0-36 gdm-lang-2.20.0-44 gdm-2.20.0-44
Please disregard comment #47 I had been playing with the settings in /etc/sysconfig/displaymanager while the update was taking place and assumed erroneously that this file had been updated as well. My manual changes are still there and most probably the cause of the change. Changing DISPLAYMANAGER_RANDR_MODE_auto="1024x768_60 64.11 1024 1080 1184 1344 768 769 772 795 -HSync +Vsync" to DISPLAYMANAGER_RANDR_MODE_auto="1280x800_60 68.90 1280 1301 1333 1408 800 804 808 816 -hsync -vsync" as sugested by Morten Welinder in Bug 343858 comment #2, only I found the information not in /etc/X11/xorg.conf but rather /var/log/Xorg.0.log
*** Bug 347299 has been marked as a duplicate of this bug. ***
I just noticed that the log from comment #45 has a GLog warning; this indicates that my patch screwed up something. Could you please do this: $ gnome-session-remove gnome-panel $ gdb gnome-panel (gdb) tb main (gdb) r (gdb) b g_log (gdb) c (gdb) bt and paste what "bt" says?
Created attachment 187034 [details] panel-debug-log-2007-12-11-17-08-28.txt I installed federico's gnome-panel-2.20.0-4.1 package and got the panel-log requested. fwiw, I didn't get any g_log errors from panel
Created attachment 187041 [details] panel-debug-log-2007-12-11-17-33-05.txt oops, previous debug log was done after having manually run xrandr --auto, so this is a new debug log where the screen is broken :)
Hallo Federico, you put me in as requestee for NEEDINFO, not sure how I can be of help. My config has changed since, I am currently using all factory packages and changed /etc/sysconfig/displaymanager to reflect the correct displaysize as suggested by Morten Welinder in https://bugzilla.novell.com/show_bug.cgi?id=343858#c2 2. In /etc/sysconfig/displaymanager, I had to change DISPLAYMANAGER_RANDR_MODE_auto from its default setting of "1024x768..." to this DISPLAYMANAGER_RANDR_MODE_auto="1280x800_75 83.46 1280 1344 1480 1680 800 801 804 828" In my case it is now #DISPLAYMANAGER_RANDR_MODE_auto="1024x768_60 64.11 1024 1080 1184 1344 768 769 772 795 -HSync +Vsync" DISPLAYMANAGER_RANDR_MODE_auto="1280x800_60 68.90 1280 1301 1333 1408 800 804 808 816 -hsync -vsync" Not sure where this is heading, but one should keep in mind that _all_ of this was working perfectly ( for me ) in openSuSE 10.2 out of the box, including 3D and external monitor. If you want me to try something for you, you are welcome, but we need to set up everything afresh. Hardware: Notebook FSC Amilo Si1520 Graphics: Intel 945 GM, LCD 1280*800 Wireless: Intel ipw3945 Sound: Intel ICH7 Desktop: GNOME OS: openSUSE 11.0 (i586) Alpha0 VERSION = 11.0 Kernel: 2.6.24-rc4-git6-2-default rpm -qa | grep x11 x11-input-wacom-0.7.8-59 xorg-x11-libxcb-7.3-13 xorg-x11-libX11-7.3-14 xorg-x11-libXdmcp-devel-7.3-11 xorg-x11-xtrans-devel-7.3-10 xorg-x11-libxcb-devel-7.3-13 xorg-x11-libX11-devel-7.3-14 xorg-x11-libXfixes-devel-7.3-13 xorg-x11-libXmu-devel-7.3-13 xorg-x11-server-extra-7.3-37 libqt4-x11-4.3.3-5 xorg-x11-libXau-7.3-11 xorg-x11-driver-video-7.3-46 dbus-1-x11-1.1.3_git20071112-5 xorg-x11-libXrender-7.3-13 xorg-x11-libICE-devel-7.3-11 yast2-x11-2.15.11-54 xorg-x11-fonts-devel-7.3-11 xorg-x11-libxkbfile-7.3-13 xorg-x11-libXpm-7.3-13 x11-tools-0.1-112 xorg-x11-libfontenc-7.3-11 xorg-x11-libXext-7.3-13 xorg-x11-libfontenc-devel-7.3-11 xorg-x11-libXp-7.3-13 xorg-x11-libXext-devel-7.3-13 xorg-x11-libs-7.3-19 xorg-x11-fonts-core-7.3-21 x11-input-wacom-tools-0.7.8-59 xorg-x11-proto-devel-7.3-13 x11-input-synaptics-0.14.6-124 xorg-x11-libSM-devel-7.3-11 xorg-x11-libXv-devel-7.3-13 ghostscript-x11-8.60-12 xorg-x11-server-7.3-37 xorg-x11-libICE-7.3-11 xorg-x11-libXt-7.3-13 xorg-x11-libXmu-7.3-13 xorg-x11-libxkbfile-devel-7.3-13 xorg-x11-libX11-ccache-7.3-24 xorg-x11-libXau-devel-7.3-11 xorg-x11-util-devel-7.3-13 xorg-x11-libXv-7.3-13 xorg-x11-libXprintUtil-7.3-13 xorg-x11-libXrender-devel-7.3-13 xorg-x11-libXp-devel-7.3-13 xorg-x11-fonts-7.3-21 xorg-x11-devel-7.3-19 xorg-x11-driver-input-7.3-27 xorg-x11-libXdmcp-7.3-11 xorg-x11-libSM-7.3-11 xorg-x11-libXfixes-7.3-13 xorg-x11-libXt-devel-7.3-13 xorg-x11-libXpm-devel-7.3-13 xorg-x11-libXprintUtil-devel-7.3-13 xorg-x11-7.3-28 xorg-x11-Xvnc-7.3-37
Hello there, Don't know if this information is helpful, but when I enable 3d acceleration AND desktop effects in Gnome, the problem disappears on both of my systems.
Hello, I have the same sort of problems as described above. I found out that when in runlevel 3 and after that startx is used the displacement is not there and the x session behaves as normal. Maybe it has something to do with the gdm or xdm? Also in case of displacement the program: gnome-display-properties gives no higher resolution than 1024x786. Otherwise it gives the normal resolutions selection. In my case 1280x800. I hope this helps finding a solution. If more information/testing is needed let me know. vrgr. Jan
For bug #343858 I've patched GTK+ to sanitize the monitor geometries directly in GdkScreen. With this, the panel should require no changes. So for now I'll mark this bug as depending on that one.
really annoying bug and took me way to long to figure this out... anyway the following worked for me: comment out the DISPLAYMANAGER_RANDR_MODE_VGA="auto" and DISPLAYMANAGER_RANDR_MODE_auto="1024x768_60..." in /etc/sysconfig/displaymanager then reboot or restart X.
maybe this bug and 343858 are related??? I have the same problem on two laptops with intel graphics chipsets and it appears AFTER a full update. Both i586 and x64 architectures
why the fix takes so long as the solution is found as far as I read from both this and 343858 bug posts? :/
bump, this is really annoying me lately as I've been running some test suites that tend to crash my X :( I'm constantly having to login to a quarter-screen gdm and then open an xterm to run xrandr --auto just to fix my panel
(In reply to comment #59 from Theodoros Nikolakopoulos) > why the fix takes so long as the solution is found as far as I read from both > this and 343858 bug posts? :/ No, it is not. The source of the problem is found (having xinerama screens with different resolutions active at the same time), a feature that wasn't possible before. The "solution" is to deactivate this feature, which results in other regressions (external projector support). This is just not handled correctly in gdm yet. And probably in other applications. (In reply to comment #60 from Jeff Stedfast) > I'm constantly having to login to a quarter-screen gdm and then open an xterm > to run xrandr --auto just to fix my panel If commenting out DISPLAYMANAGER_RANDR_MODE_VGA="auto" doesn't help you, you're probably hitting a different bug.
Closing again as duplicate of bug 343858. I've submitted an updated gtk+ package with a fix. *** This bug has been marked as a duplicate of bug 343858 ***
Doesn't look extremely fixed to me though, after clean install from Beta3 the screen comes set to 1024*768, that's the only reason it looks fixed. Setting resolution to 1200*800 with "Configure Display Settings" from the applet doesn't change that. It simply follows the external monitor which happens to be not there but is preset to 1024*768 Running sax2 from runlevel 3, setting the resolution to 1280*800 causes the maximizing windows problem again ( windows maximize only to the 1024*768 footprint, unless they are drawn over that limit before maximizing. The applet still shows resolution of 1024*768 Only setting DISPLAYMANAGER_RANDR_MODE_auto as per comment #48 to 1280x800_60 68.90 1280 1301 1333 1408 800 804 808 816 -hsync -vsync solves this issue, yet no other resolutions can be selected from the applet.
.
I've also noticed this bug after installing 11.0 Beta3. My screen resolution is 1280x800.
Are we talking about panels or the maximized windows here? If the latter, then this is now tracked in bug 385553.
Hmm, right, it's windows for me, so I'll switch over to Bug 385553
All the related bugs are fixed now for 11.0, so marking this as fixed.