Created attachment 298161 [details]
Xorg.0.log - system comes up in 1920x1080 mode (monitor only support 1280x1024)

Same behavior with current Rawhide:

xorg-x11-server-utils-7.3-3.fc9.i386
xorg-x11-server-common-1.4.99.901-10.20080314.fc9.i386
xorg-x11-server-Xorg-1.4.99.901-10.20080314.fc9.i386

running "xrandr --size 1920x1080" puts the monitor "out of sync". "xrandr --size
1280x1024" properly restores it.

So it looks to me that the monitor initially is actually set properly to
1280x1024, but some setting causes xrandr to report out as 1920x1080, and causes
xdpyinfo to report resolution the same.

This confuses some apps that display images (like the workspace switcher applet,
firefox's buttons and window size, etc.).

My routine after gnome login is to run "xdpyinfo | grep 1920" (and "xrandr
--size 1280x1024":
[tbl@localhost ~]$ xdpyinfo | grep 1920
  dimensions:    1920x1024 pixels (300x230 millimeters)
[tbl@localhost ~]$ xrandr --size 1280x1024
[tbl@localhost ~]$ 

Is there additional info that would be useful?

Created attachment 298511 [details]
Xorg.0.log using NO xorg.conf, xrandr still reports 1920x1080

I tried again to restart gdm/X without xorg.conf; this time it worked on my
Thinkpad X60!

Attached Xorg.0.conf shows it coming up in, I think, 1280x1024 mode. 

The use case was boot up gdm, check xpyinfo for 1920x1080 resolution, and then
run "xrandr --size 1280x1024"

I continue to have this issue.  Here is what I see each time I boot/login:

1. gdmgreeter sets display to 1024x768 (although this takes about 15-20 seconds
on reboot)
2. After entering password, another 7-10 seconds spins until the display
'resizes' to 1280x1024 (the largest my monitor/adapter can support).
3. Upon resizing, I get a "tiled" view of the "fedora curve" background: one
full image in the upper left corner, 3 "pieces of tile" in the upper right,
bottom left and bottom right.
4. After spinning for another 15 seconds or so, the background is replaced with
a single 1280x1024 image and my "session windows" start appearing (actually, 2
gnome-terminal windows and a pidgin window).
5. Typically within about 5 seconds, the applets start appearing.
6. The display and most of the programs think the display is set to 1280x1024,
but xdpyinfo, firefox and the workspace switcher applet think the display is set
to 1920x1024: "xdypinfo | grep dimensions" reports "dimensions:   1920x1024
(300x230 millimeters)".
7. Running "xrandr --size 1280x1024" blanks and redraws the screen (but mostly
nothing changes: workspace switcher applet is now properly sized).


I run through the above sequence every login.

Running latest Rawhide packages......

Is there some additional information I can provide?  Additional debugging?

I get exactly the same behavior if I 'telinit 3' and run startx.

Notice this in Xorg.0.log:

(II) intel(0): X context handle = 0x1
(II) intel(0): [drm] installed DRM signal handler
(==) intel(0): VideoRam: 262144 KB
(**) intel(0): Framebuffer compression enabled
(**) intel(0): Tiling enabled
(II) intel(0): Attempting memory allocation with tiled buffers.
(II) intel(0): Allocating 5760 scanlines for pixmap cache
(II) intel(0): Success.
(II) intel(0): Increasing the scanline pitch to allow tiling mode (1920 -> 2048).

Is the reporting on 'Tiling' to be expected?

X works like a charm if I only use the builtin LCD display (1024x768): system
comes up properly.

If I connect either of my monitors and boot up X, X starts up in 1920x1024 (or
1920x1080) mode.

Here is output of xrandr after adjusting to 1280x1024:

[root@localhost log]# xrandr
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 1920 x 1920
VGA connected 1280x1024+0+0 (normal left inverted right x axis y axis) 359mm x 287mm
   1920x1080      59.9  
   1680x1050      59.9  
   1600x1024      60.2  
   1400x1050      60.0  
   1280x1024      75.0     60.0*    60.0  
   1440x900       59.9  
   1280x960       60.0  
   1360x768       59.8     60.0  
   1280x800       85.0     75.0     70.0     60.0  
   1152x864       85.1     85.0     75.0     75.0     70.0     60.0  
   1280x768       85.0     75.0     70.0     60.0  
   1280x720       85.0     75.0     70.0     60.0  
   1152x768       54.8  
   1024x768       85.0     75.1     75.0     70.1     60.0  
   832x624        74.6  
   800x600        85.1     72.2     75.0     60.3     56.2  
   640x480        85.0     75.0     72.8     72.8     75.0     66.7     60.0   
 59.9  
   720x400        85.0  
   640x400        85.1  
   640x350        85.1  
LVDS connected (normal left inverted right x axis y axis)
   1024x768       50.0 +   60.0     40.0  
   800x600        60.3  
   640x480        60.0     59.9  
[root@localhost log]# 


I'm at a loss on how to debug, and would welcome any direction to collect more
info or to test.....

BTW, "xrandr --auto" seems to "fix this" as well: it resets display to 1280x1024
from 1920x1024:

[tbl@localhost ~]$ xdpyinfo | grep dim
  dimensions:    1920x1024 pixels (300x230 millimeters)
[tbl@localhost ~]$ 
[tbl@localhost ~]$ 
[tbl@localhost ~]$ xrandr --auto
[tbl@localhost ~]$ 
[tbl@localhost ~]$ xdpyinfo | grep dim
  dimensions:    1280x1024 pixels (287x229 millimeters)
[tbl@localhost ~]$ 

This was posted on fedora-devel.  Could it be related?

Nicolas Mailhot wrote:

    The problem is not applications doing it wrong, and the Gnome
    appearance configuration doing it right, they all change things at the
    wrong level which explains why the changes are not shared, conflict,
    and are a PITA for users.

    The right desktop level for DPI is xorg. All the apps need to be fixed
    to stop meddling with DPI values, use the Xorg DPI values directly
    (and fix xorg when it's getting it wrong, in your case vmware side).
    Unfortunately so far the reflex of every app writer was not to help
    xorg fix its code but workaround it locally in various conflicting and
    incompatible ways. What you are seing right now is the pile of dpi
    workarounds and bandaids crumbling on your system.


I think you summarized it pretty well. To be accurate, the VMWare problem is not
DPI reporting (which is correct, as per xrdb -query), but the screen *size*
reporting (in millimeters). The function get_dpi_from_x_server() in the
control-center source code calls gdk_screen_get_width_mm() and  computes its own
DPI value from the screen pixel and mm size, and get its wrong. As you said, it
would cleaner if it queried the X server for the DPI size directly...

xrandr continues to report seemingly bogus information:

[tbl@localhost ~]$ xrandr
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 1920 x 1920

**** why is the maximum reporting out as 1920x1920??? no way my monitor or
interface can support that.  When gnome "comes up" the current is reporting out
as 1920x1024, and xdpyinfo is reporting dimension of 1920x1024 causing desktop
confusion.....

VGA connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm

**** As far as I can tell, many of these modes are not supported (anything
bigger than 1280x1024)

   1280x1024      60.0 +   75.0*    60.0     60.0  
   1920x1080      59.9  
   1680x1050      59.9  
   1600x1024      60.2  
   1400x1050      60.0  
   1440x900       59.9  
   1280x960       60.0  
   1360x768       59.8     60.0  
   1280x800       75.0     70.0     60.0  
   1152x864       75.0     75.0     70.0     60.0  
   1280x768       75.0     70.0     60.0  
   1280x720       75.0     70.0     60.0  
   1152x768       54.8  
   1024x768       75.1     75.0     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        75.0     72.8     72.8     75.0     60.0     59.9  
   720x400        70.1  
LVDS connected (normal left inverted right x axis y axis)

****** LVDS settings look right ******

   1024x768       50.0 +   60.0     40.0  
   800x600        60.3  
   640x480        60.0     59.9  
[tbl@localhost ~]$ 

Some more (hopefully helpful) comments on this:

1. when connected only to laptop screen, all work 100% OK.

2. If I create and use an 'xorg.conf' (using s-c-display to generate) that
specifies only 1280x1024 (or below), the behavior changes slightly. 
     gdmgreeter now comes up in the "correct" resolution (1280x1024 instead of
1024x768) 

3. Notwithstanding the xorg.conf specs (included below), xrandr and xdpyinfo
still show the screen as 1920x1024, and xrandr still shows lots of unsupported
modes.

The screen size of 1920x1024 is the major problem, as windows are not placed (or
sized) properly.   Running in this mode, the "Maximize Window" button does not
really work: the window is expanded to only about 60% of the screen (could it be
expanded by 1280/1920 = 66%?)

I'll post here output of xrandr (notice the "Screen 0" current of 1920x1024 and
a max of 1920x1920, and the unsupported modes), output of 'xdpyinfo | grep dim'
and contents of generate xorg.conf:

[tbl@localhost ~]$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1024, maximum 1920 x 1920
VGA connected 1280x1024+0+0 (normal left inverted right x axis y axis) 359mm x 287mm
   1280x1024      75.0 +   60.0*    60.0  
   1920x1080      59.9  
   1680x1050      59.9  
   1600x1024      60.2  
   1400x1050      60.0  
   1440x900       59.9  
   1280x960       60.0  
   1360x768       59.8     60.0  
   1152x864       85.1     85.0     75.0     75.0     70.0     60.0  
   1024x768       85.0     75.1     75.0     70.1     60.0  
   832x624        74.6  
   800x600        85.1     72.2     75.0     60.3     56.2  
   640x480        85.0     75.0     72.8     72.8     75.0     66.7     60.0   
 59.9  
   720x400        85.0  
   640x400        85.1  
   640x350        85.1  
LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis) 246mm x 185mm
   1024x768       50.0*+   60.0     40.0  
   800x600        60.3  
   640x480        60.0     59.9  
[tbl@localhost ~]$ 

[tbl@localhost ~]$ grep dim xdpyinfo-conf.txt
  dimensions:    1920x1024 pixels (508x271 millimeters)
[tbl@localhost ~]$ 

[Display appears to have a 'non-displayed' area beyond the right edge.]

[tbl@localhost ~]$ cat /etc/X11/xorg.conf
# Xorg configuration created by system-config-display

Section "ServerLayout"
	Identifier     "single head configuration"
	Screen      0  "Screen0" 0 0
EndSection

Section "Device"
	Identifier  "Videocard0"
	Driver      "intel"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Videocard0"
	DefaultDepth     24
	SubSection "Display"
		Viewport   0 0
		Depth     24
		Modes    "1280x1024" "1280x960" "1152x864" "1024x768" "832x624" "800x600"
"720x400" "640x480" "640x400" "640x350"
	EndSubSection
EndSection

[tbl@localhost ~]$ 

Booting with 'i915.modeset=1' on boot line seems to 'fix' this problem.

That is, gnome comes up with display/screen properly sized:

[tbl@localhost ~]$ xrandr
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 1920 x 1920
VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x
301mm
   1280x1024      60.0*+   75.0     60.0* 
   1920x1080      59.9  
   1680x1050      59.9  

Notice 'current' is now set as 1280x1024 (not 1920x1024).  Icons are all
properly sized (mostly workspace switcher aplet, and maiximize window button].

On the other hand, compiz-type effects appear choppy, and glxgears reports about
300 fps (vs. about 1000 booting without 'i915.modeset=1'):

[tbl@localhost ~]$ glxgears
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try running with LIBGL_THROTTLE_REFRESH and LIBL_SYNC_REFRESH unset.
1486 frames in 5.0 seconds = 297.031 FPS
1494 frames in 5.0 seconds = 298.324 FPS
1500 frames in 5.0 seconds = 299.821 FPS

Is this making any sense.....?

Turning on 'ModeDebug' and restarting the server (without i915.modeset=1), I
notice a few occurrences of the following:

(II) intel(0): Mode for pipe A:
(II) intel(0): Modeline "(null)"x0.0  135.00  1280 1296 1440 1688  1024 1025
1028 1066 +hsync +vsync (80.0 kHz)
chosen: dotclock 134400 vco 2688000 ((m 84, m1 13, m2 7), n 1, (p 20, p1 2, p2 10))

I do not notice with when running with 'i915.modeset=1'. Is the "(null)x0.0"
suspicious?

More data for this......

[This is on a Thinkpad X60, with intel 945 graphics running compiz. Setup is
with laptop connected to external monitor and laptop lid closed.]

It appears that the 'modesetting' code may not be setting the 'Virtual' size of
the display as expected(?)

So here's the way it plays out....:

1. Without an xorg.conf, gdmgreeter starts up in 1024x768, after entering
password/etc., screen resizes to 1280x1024 (the largest my screen will support,
945 too?), but the "dimension" as reported by xrandr is 1920x1024.  This causes
problems with the size of come graphics (e.g., window-switch applet, etc.), and
creates an area off the right side of the screen where the mouse "vanishes". 
Finally, "maximize window" doesn't work: windows appear to fill up 2/3 of screen.

2. With xorg.conf (generated by s-c-d, with 1280x1024 and smaller modes) above
behavior is the same, except gdmgreeter now displays in 1280x1024 instead of
1024x768.  "dimension" as reported by xdpyinfo continues to read 1920x1024.

3. With above xorg.conf augmented with "Virtual 1280 1024", same behavior as 2
above, but "dimension" is now reported as "1280x1024":
  dimensions:    1280x1024 pixels (339x271 millimeters)
This is different from 1 and 2 above where it was reported:
  dimensions:    1920x1024 pixels (508x271 millimeters)

[Notice also 508 vs. 339.....]

But...... "maximize window" still fails: I get windows that fill about 2/3's in
both x and y.  I attach below a screen show showing a 80x24 terminal window
"maximized".

I continue to be thoroughly confused......

Created attachment 303320 [details]
Screenshot with 66% sized maximized window

Created attachment 303493 [details]
Xorg.0.log booting w/o xorg.conf and using 'xrandr --fb 1280x1024'

Fixing the size using 'xrandr --fb 1280x1024' (instead of --size 1280x1024)
produces:

[tbl@localhost ~]$ xdpyinfo | grep dim
  dimensions:	 1280x1024 pixels (338x270 millimeters)
[tbl@localhost ~]$ 

Items appear scaled properly, no 'right size overhang', but 'maximize window'
still has the 66% problem as shown in #14.

So what is '--size' changing that '--fb' is not.....?

[And why am I the only one complaining about this......]

Created attachment 303630 [details]
Screenshot of "stretched screen" (1920x1024 @ 1280x1024)

Here is a screenshot of my usual setup after logging in.  Note the "black hole"
area on the right side.

xrandr says:

[tbl@localhost ~]$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1024, maximum 1920 x 1920
VGA connected 1280x1024+0+0 (normal left inverted right x axis y axis) 359mm x
287mm
   1920x1080	  59.9	
   1680x1050	  59.9	
   1600x1024	  60.2	
   1400x1050	  60.0	
   1280x1024	  75.0	   60.0*    60.0  
   1440x900	  59.9	
<<<<< snip >>>>>

and 'xdpyinfo' says:

[tbl@localhost ~]$ xdpyinfo | grep dim
  dimensions:	 1920x1024 pixels (508x271 millimeters)
[tbl@localhost ~]$ 


When I boot with 'i915.modeset=1' screen is properly sized.

[I have no xorg.conf.....]

ARGHHHHHHHH

I think I may have figured this one out....

Running gnome-display-properties and turning off the laptop monitor (LVDS) makes
this problem "go away".

Is it possible that somehow the display is trying to drive both simultaneously
(CRT @ 1280x1024, LVDS @ 1024x768) and somehow decides a virtual size of
1920x1024 is best?

I never had both screens active at the same time, so I don't know how this
configuration could have occurred, but ....

OK.  Closing this as NOTABUG.  The issue (if there is one) appears to be with
gnome-display-properties....