Bugzilla – Bug 272715
Gnome detects wrong graphics resolution
Last modified: 2008-03-26 21:25:41 UTC
On an FSC Amilo Si 1520 running openSuSE 10.3 alpha4 when switching from GDM to XDM the menu bar is not properly sized.
Created attachment 138677 [details] Screenshot of XDM Desktop
I don't think this is a displaymanager issue. Does it also happen with kdm?
I only categorized it as X.Org because xdm seems to be part of that package ( according to YaST ), yes, it is the same with KDM.
Created attachment 138721 [details] Screenshot of KDM Desktop
I wonder how this should be related to kdm/xdm. It's after starting the session. Which kind of session is this? KDE or GNOME?
I am generally using GNOME, I only installed KDM just now to answer your question. So I suppose it's a GNOME session. It looks as though the menu bar is adjusted to some lesser resolution in XDM and KDM, I am using 1280x800 it could be adjusted to 1024x768 or 800x600
Your resolution is switched automatically after login? Wow! Assuming you're already using the intel driver this might be related to enabling the external output for Laptops with intel chipsets in /etc/X11/xdm/Xsetup: # # Check if the machine is a laptop and configure # external output if XRANDR 1.2 is available # if xrandr | grep -q "^default connected" ; then echo "Driver not XRANDR 1.2 capable, ignoring DISPLAYMANAGER_RANDR_MODE_* settings" else if $halporp --key system.formfactor --string laptop ; then mode_auto="$DISPLAYMANAGER_RANDR_MODE_auto" else mode_auto="" fi for ext in VGA DVI-I DVI-D DVI-A Composite S-Video Component LFP Proprietary ; do var="DISPLAYMANAGER_RANDR_MODE_${ext//-/_}" line="${!var}" test "x$line" = xauto && line="$mode_auto" mode="${line%% *}" case "x$line" in x) ;; x*\ *) echo "xrandr for $ext: new mode $line" xrandr --newmode $line xrandr --addmode $ext $mode xrandr --output $ext --mode $mode ;; x*) echo "xrandr for $ext: known mode $line" xrandr --output $ext --mode $mode ;; esac done fi Could you set DISPLAYMANAGER_RANDR_MODE_VGA in /etc/sysconfig/displaymanager to "" to check if this issue disappears? The other issue is, that we still do not write a correct X11 configuration for the new intel driver. :-(
"Your resolution is switched automatically after login? Wow!" you lost me here :-( "Assuming you're already using the intel driver" xorg.conf has "intel" "Could you set DISPLAYMANAGER_RANDR_MODE_VGA in /etc/sysconfig/displaymanager to "" to check if this issue disappears?" Setting DISPLAYMANAGER_RANDR_MODE_VGA = "" Setting DISPLAYMANAGER = XDM The menu bar now has the proper size, see screenshot.
Created attachment 138765 [details] Screenshot of Desktop using XDM after change requested
P.S. DISPLAYMANAGER_RANDR_MODE_VGA was = auto
Could you attach output of "xrandr" and your xorg.conf? Then I could adjust it to your needs so that changing DISPLAYMANAGER_RANDR_MODE_VGA is hopefully no longer required. I think this is another bug which depends on Bug #270846.
Created attachment 138769 [details] /etc/X11/xorg.conf
workstation6l:/home/cjp # xrandr Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280 VGA disconnected (normal left inverted right) LVDS connected 1280x800+0+0 (normal left inverted right) 261mm x 163mm 1280x800 60.0*+ 1024x768 60.0 800x600 60.3 640x480 59.9 TMDS-1 disconnected (normal left inverted right) TV disconnected (normal left inverted right)
Created attachment 138770 [details] xorg.conf Now you should get a 1280x800 resolution from the beginning. No matter if the sysconfig variable is set to "auto" (default) or "". Hopefully.
Can you confirm this?
Alas not, Stefan, see Screenshot. The Background spreads over the full 1280x800, while the menu bar is set at 1024x768
Created attachment 138773 [details] Screenshot of Desktop after rebooting with new xorg.conf and XDM DISPLAYMANAGER_RANDR_MODE_VGA = auto
Created attachment 138775 [details] Screenshot of same situation with evolution running As you can see, Evolution uses the full 1280x800 resolution, while gnome menu bar does not. I am not sure about Desktop, as a picture in the upper right corner stays in place, but outside the 1024x768 range. The background definitely uses the full resolution of 1280x800
Hmm. Could you also attach /var/log/Xorg.0.log for the new xorg.conf?
Created attachment 138783 [details] /var/log/Xorg.0.log as requested
According to your logfile Xservers starts with 1280x800 as default. Maybe Matthias has an idea what's going on here.
You lost me again :-( 1280x800 is my standard resolution, why should the x-server start with anything else ? Am I missing something here ?
Hmm. The question is then why GNOME thinks that the resolution is 1024x768 if it has been 1280x800 from the beginning and didn't change with the xrandr calls in /etc/X11/xdm/Xsetup. Maybe we found a GNOME bug.
To figure out if it's a GNOME bug, we would need to verify it with a KDE session. You would need to use KDM as displaymanager to easily select the session type and KDE needs to be installed. Is this possible?
Created attachment 138929 [details] xorg.conf Fixed xorg.conf. --- bug-272715_xorg.conf +++ xorg.conf - Option "monitor-LVDS" + Option "monitor-LVDS" "Monitor[0]"
Although I don't think that the fixed xorg.conf will change anything.
Created attachment 138980 [details] Snapshot of KDE Session with Display Settings As it seems KDE is setting resolution properly to 1280x800 ( although everything appears larger, I set icon size in GNOME to 75% and fonts to 8 )
Ok. Then I think it's a GNOME bug.
AFAIK this was also the case for KDE only few weeks ago. It turned out to be a bug in KDE, so probably gnome has the same issue. AFAIK Dirk Mueller knows more about that. (In reply to comment #24) > session. You would need to use KDM as displaymanager to easily select the > session type and KDE needs to be installed. Is this possible? It's no longer necessary to use KDM. GDM works quite as well. (In reply to comment #27) > As it seems KDE is setting resolution properly to 1280x800 ( although > everything appears larger, I set icon size in GNOME to 75% and fonts to 8 ) This *might* be a side effect. To be sure, check the output of xdpyinfo | grep resolution The useful range is 75-130. If it is outside that range (typical monitors have approx. 100, laptops typically a bit higher, we have to check whether they are correct.
Forgot to add Dirk due to mid-air collision...
> It's no longer necessary to use KDM. GDM works quite as well. Just a side note. GDM currently does not work for the reporter at all and is the root for about a dozen of bugreports by him. This is only one of them.
Reply to comment #29 (In reply to comment #27) xdpyinfo | grep resolution resolution: 125x125 dots per inch Managed to set icon and font size to my liking in KDE presently :-)
That's a pretty high dpi value, but not unreasonable for laptops (I assume a laptop with a high resolution screen here).
Sorry for goofing on this: comment #27 was based on the assumption that choosing KDE automatically also uses KDM, obviously this is not the case. So the Screenshot from #27 was in fact based on KDE with GDM. Attaching a new one, which shows KDE with KDM. Please note, that with GNOME and KDM applications could use the full screen area, wheras with KDE and KDM it appears that applications stay in the 1024x768 area.
Created attachment 139050 [details] Screenshot of KDE using KDM
Egbert, JFYI. Since Matthias or me is in Cc of this bugreport or the reported itself, it might be interesting for you as well.
What's the screen size in XDM/KDM? I would assume it's 1024x768, while GDM sets it to 1280x800. So something resets it at startup of the KDE/GNOME session. Any X application gets the screen size during connection setup. 'Interested applications' - and i would assume any GNOME/KDE applications qualify for this - can register for events to be notified of screen size changes. So to me it looks like that either there is a race in delivering these events or these events are not delivered properly.
>What's the screen size in XDM/KDM? I would assume it's 1024x768, while GDM >sets it to 1280x800. This was my first thought as well, but it was proven to be wrong. Xserver already starts with 1280x800.
What's the output of xdpyinfo when the window decorations are wrong? Is the xrandr output in comment #13 exactly what's printed on this system? Another worthwhile thing to test would be the xinerama layout data. Unfortunately there is no easy client to test this.
"Is the xrandr output in comment #13 exactly what's printed on this system?" What do you think we are up to here ? Playing games on each other ?
(In reply to comment #40) > "Is the xrandr output in comment #13 exactly what's printed on this system?" > > What do you think we are up to here ? Playing games on each other ? > Hey, you don't have to insult me here. You were testing various combinations with different display managers. It's conceivable that you ran this with GDM where the sessions had the correct display size. RandR reports a size of 1280x800, what xdpyinfo reports I don't know because you didn't attach the output I asked you for. We still need to find out what Xinerama says as there is currently no client to query that.
Egbert asked you for the xdpyinfo output. :-(
Created attachment 140106 [details] tool for printing xinerama info Use this tool for printing xinerama information. Compile with g++ -o xinedump xinedump.cc -lXinerama -lX11
cjp@workstation6l:~> xdpyinfo name of display: :0.0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 70000001 X.Org version: 7.0.0.1 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 4, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x320001f, revert to PointerRoot number of extensions: 29 BIG-REQUESTS Composite DAMAGE DEC-XTRAP DOUBLE-BUFFER DPMS Extended-Visual-Information GLX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RANDR RECORD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP X-Resource XC-APPGROUP XC-MISC XFIXES XFree86-Bigfont XINERAMA XInputExtension XKEYBOARD XTEST XVideo default screen number: 0 number of screens: 1 screen #0: print screen: no dimensions: 1280x800 pixels (260x163 millimeters) resolution: 125x125 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 root window id: 0x52 depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store NO, save-unders NO largest cursor: 1280x800 current input event mask: 0x7a803f KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask ExposureMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask number of visuals: 4 default visual id: 0x2c visual: visual id: 0x2c class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2d class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2e class: TrueColor depth: 32 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2f class: TrueColor depth: 32 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits
After updating from factory to alpha7 this happens again with Driver=intel
Created attachment 154761 [details] Screenshot of desktop
can you provide the output of xrandr?
cjp@workstation6l:~> xrandr Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280 VGA disconnected (normal left inverted right) LVDS connected 1280x800+0+0 (normal left inverted right) 261mm x 163mm 1280x800 60.0*+ 1024x768 60.0 800x600 60.3 640x480 59.9 TMDS-1 connected 1024x768+0+0 (normal left inverted right) 0mm x 0mm 1024x768 60.0* 800x600 60.3 640x480 59.9 TV disconnected (normal left inverted right)
There is an interesting quirk about it, I noticed this time: If I start nautilus from the menu or by clicking an icon on the desktop it uses the full screen space, when I start it from a terminal it is confined to the 1024x768 boundary. While banshee uses always the full display space, whether started from the menu or a terminal doesn't matter.
Even funnier: While windows are not maximized, they can be dragged out of the 1024x768 boundary. If maximized afterwards, they use the full screen size. I could even drag the panel outside and it resizes to its proper size at the bottom edge. Starting programs have their windows still confined to the 1024x768 boundary.
After several "clean" installs from beta1 DVD and _not_ using LDAP for local users, this behaves normal again, not sure what to make of it.
Mark, can you try to dupe this one?
No luck.
Mark, do you have a laptop with the external display turned on with a different resolution than the built in display? See xrandr output above.
This looks like a duplicate of bug #310208.
Casual J., could you please try the gnome-panel package here: http://download.opensuse.org/repositories/home:/federico-mena/openSUSE_10.3/ Start a GNOME session, and then do killall -USR1 gnome-panel Then, please attach the ~/panel-debug-log-xxxxxxx.txt file to the bug. The log file from the duplicate bug shows that gnome-panel finds one X screen with two monitors, where the *first* monitor is 1024x768 and the *second* one is the full resolution of your "primary" display. I don't know yet if this is the expected behavior and if gnome-panel is doing something wrong, or if it's an actual problem with the X configuration. *** This bug has been marked as a duplicate of bug 310208 ***