Bug 19179 - [GM45] extended desktop display issue over 2048x2048 with Fedora 10
Summary: [GM45] extended desktop display issue over 2048x2048 with Fedora 10
Status: RESOLVED DUPLICATE of bug 17490
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Gordon Jin
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2008-12-19 03:26 UTC by David J. Orman
Modified: 2008-12-24 17:45 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
xorg.conf that breaks X, Virtual 4096 4096 (2.16 KB, text/plain)
2008-12-19 03:26 UTC, David J. Orman
no flags Details
Xorg log when using Virtual 4096 4096 (27.48 KB, text/plain)
2008-12-19 03:26 UTC, David J. Orman
no flags Details

Description David J. Orman 2008-12-19 03:26:06 UTC
Created attachment 21314 [details]
xorg.conf that breaks X, Virtual 4096 4096

Hi,

I'm running Fedora 10, x64. I'm trying to enable an external display as an extended desktop with the laptop display, not mirroring. Mirroring works as to be expected (both displays adjust to the screen's resolution that is the lowest).

However, extended desktop does not work.

This is what I see when I try using XrandR when running with *no* xorg.conf:

[david.orman@ormandj-laptop src]$ xrandr --output VGA --auto --right-of LVDS
xrandr: screen cannot be larger than 1440x1440 (desired size 2720x1024)
[david.orman@ormandj-laptop src]$ xrandr
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 1440 x 1440
VGA connected (normal left inverted right x axis y axis)
   1280x1024      60.0 +   75.0     60.0  
   1400x1050      60.0  
   1280x960       60.0  
   1152x864       75.0  
   1024x768       75.0     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        75.0     72.8     75.0     66.7     59.9  
   720x400        70.1  
LVDS connected 1440x900+0+0 (normal left inverted right x axis y axis) 303mm x 190mm
   1440x900       60.0*+   50.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
HDMI-1 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)
[david.orman@ormandj-laptop src]$ Xorg -version

X.Org X Server 1.5.3
Release Date: 5 November 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.18-92.1.18.el5 x86_64 
Current Operating System: Linux ormandj-laptop 2.6.27.7-134.fc10.x86_64 #1 SMP Mon Dec 1 22:21:35 EST 2008 x86_64
Build Date: 11 December 2008  05:27:30PM
Build ID: xorg-x11-server 1.5.3-6.fc10 
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
[david.orman@ormandj-laptop src]$ 

So, even though it seems odd that I need to muck with an xorg.conf file, I created one with a "Virtual" line, of "4096 4096".

Then, X locks up when started. I am attaching the xorg.conf (which works when Virtual is set to 2048 2048) that fails, along with the log from xorg.

From the readme in the Intel driver:
"- No support for X Screens larger than 2048 pixels in either direction
  before the 965.  This reflects hardware limitations in the x direction on
  those older chips, and limits dualhead functionality.  It may be possible to
  extend the limit vertically on these older chips."

I have the G45/X4500MHD, which is certainly newer than the 965.

So, I'm reporting two things:

#1 - I don't understand why it is necessary to have an xorg.conf to create a virtual desktop of XYZ size. I would expect I could not create one beyond the hardware capabilities available, obviously.

#2 - With the xorg.conf, it seems I cannot extend a desktop across two monitors if the resolution would exceed 2048x2048. This is not what the Intel driver README states, and is a very real problem for those of us who use laptops as workstations. :) I have read in a few places that DRI has to be disabled on older Intel cards, and other such workarounds, but as this is one of the newer Intel graphics chipsets out there, (and relatively new software) I would not have expected that to be the case.

Hopefully this is already being worked on, but I wanted to put in a report in case it was not known about yet.

Here's some more information that may/may not be useful:

[david.orman@ormandj-laptop Documents]$ uname -a
Linux ormandj-laptop 2.6.27.7-134.fc10.x86_64 #1 SMP Mon Dec 1 22:21:35 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
[david.orman@ormandj-laptop Documents]$ 

From dmesg:
Linux agpgart interface v0.103
agpgart-intel 0000:00:00.0: Intel Mobile Intel? GM45 Express Chipset
agpgart-intel 0000:00:00.0: detected 32764K stolen memory
agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000
[drm] Initialized drm 1.1.0 20060810
[drm] Initialized i915 1.6.0 20080730 on minor 0

[david.orman@ormandj-laptop Documents]$ rpm -qa |grep -i xorg
xorg-x11-drv-dmc-1.1.2-1.fc9.x86_64
xorg-x11-drv-mga-1.4.9-1.fc9.x86_64
xorg-x11-drv-mutouch-1.2.1-1.fc10.x86_64
xorg-x11-drv-dynapro-1.1.2-1.fc9.x86_64
xorg-x11-drv-keyboard-1.3.0-3.fc9.x86_64
xorg-x11-drv-siliconmotion-1.6.0-1.fc9.x86_64
xorg-x11-server-Xorg-1.5.3-6.fc10.x86_64
xorg-x11-drv-void-1.1.1-9.fc9.x86_64
xorg-x11-drv-mouse-1.3.0-2.fc9.x86_64
xorg-x11-drv-spaceorb-1.1.0-6.fc9.x86_64
xorg-x11-drv-cirrus-1.2.0-1.fc9.x86_64
xorg-x11-drv-tdfx-1.4.0-1.fc9.x86_64
xorg-x11-drv-penmount-1.3.0-1.fc9.x86_64
xorg-x11-drv-microtouch-1.2.0-1.fc9.x86_64
xorg-x11-drivers-7.3-9.fc10.x86_64
xorg-x11-drv-i810-2.5.0-4.fc10.x86_64
xorg-x11-drv-nouveau-0.0.11-1.20081119git65b956f.fc10.x86_64
xorg-x11-filesystem-7.3-2.fc10.noarch
xorg-x11-xauth-1.0.2-5.fc10.x86_64
xorg-x11-font-utils-7.2-6.fc10.x86_64
xorg-x11-server-utils-7.4-3.fc10.x86_64
xorg-x11-xinit-1.0.9-4.fc10.x86_64
xorg-x11-drv-ur98-1.1.0-5.fc9.x86_64
xorg-x11-drv-voodoo-1.2.0-1.fc9.x86_64
xorg-x11-drv-mach64-6.8.0-1.fc10.x86_64
xorg-x11-drv-i128-1.3.0-1.fc9.x86_64
xorg-x11-drv-sis-0.10.0-1.fc9.x86_64
xorg-x11-drv-fbdev-0.3.1-7.fc9.x86_64
xorg-x11-drv-glint-1.2.1-1.fc9.x86_64
xorg-x11-drv-dummy-0.3.0-1.fc9.x86_64
xorg-x11-drv-sisusb-0.9.0-1.fc9.x86_64
xorg-x11-drv-v4l-0.2.0-1.fc9.x86_64
xorg-x11-drv-s3virge-1.10.0-1.fc9.x86_64
xorg-x11-drv-ast-0.85.0-1.fc9.x86_64
xorg-x11-utils-7.4-3.fc10.x86_64
xorg-x11-drv-vesa-2.0.0-1.fc10.x86_64
xorg-x11-drv-synaptics-0.15.2-1.fc10.x86_64
xorg-x11-drv-digitaledge-1.1.1-1.fc9.x86_64
xorg-x11-drv-palmax-1.2.0-1.fc9.x86_64
xorg-x11-drv-aiptek-1.1.1-1.fc9.x86_64
xorg-x11-drv-elographics-1.2.3-1.fc10.x86_64
xorg-x11-drv-calcomp-1.1.2-1.fc9.x86_64
xorg-x11-drv-hyperpen-1.2.0-1.fc9.x86_64
xorg-x11-drv-i740-1.2.0-1.fc9.x86_64
xorg-x11-drv-citron-2.2.1-1.fc9.x86_64
xorg-x11-drv-openchrome-0.2.903-1.fc10.x86_64
xorg-x11-drv-summa-1.2.0-2.fc10.x86_64
xorg-x11-drv-jamstudio-1.2.0-1.fc9.x86_64
xorg-x11-drv-trident-1.3.0-1.fc9.x86_64
xorg-x11-drv-vmware-10.16.0-1.fc9.x86_64
xorg-x11-drv-r128-6.8.0-1.fc10.x86_64
xorg-x11-drv-ati-6.9.0-62.fc10.x86_64
xorg-x11-drv-evdev-2.0.7-3.fc10.x86_64
xorg-x11-drv-diamondtouch-0.2.0-0.1.fc9.x86_64
xorg-x11-drv-vmmouse-12.6.1-1.fc10.x86_64
xorg-x11-drv-nv-2.1.12-6.fc10.x86_64
xorg-x11-drv-magellan-1.2.0-1.fc9.x86_64
xorg-x11-drv-savage-2.2.0-2.fc9.x86_64
xorg-x11-drv-wiimote-0.0.1-1.fc9.x86_64
xorg-x11-drv-acecad-1.2.2-1.fc9.x86_64
xorg-x11-xkb-utils-7.2-7.fc10.x86_64
xorg-x11-drv-fpit-1.2.0-1.fc9.x86_64
xorg-x11-drv-tek4957-1.2.0-1.fc9.x86_64
xorg-x11-drv-rendition-4.2.0-1.fc9.x86_64
xorg-x11-drv-apm-1.2.0-1.fc9.x86_64
xorg-x11-server-common-1.5.3-6.fc10.x86_64
[david.orman@ormandj-laptop Documents]$
Comment 1 David J. Orman 2008-12-19 03:26:42 UTC
Created attachment 21315 [details]
Xorg log when using Virtual 4096 4096
Comment 2 Gordon Jin 2008-12-19 22:44:29 UTC
#1: because the framebuffer size can't be changed dynamically in current code. When X starts up, it needs a pre-defined size. In current code, it picks up one of monitor sizes (1440 in you case, then make framebuffer size 1440x1440). Making xorg.conf gives you a chance to change the default value (typically useful to have extended desktop).

#2: Could you try a smaller size like 2720x1024, instead of 4096x4096? The virtual size limitation is a known issue (see bug#17490) in GEM, and has been fixed in DRI2/UXA.
Comment 3 David J. Orman 2008-12-24 00:59:53 UTC
Hi,

I was able to test this today. Once I added the smaller virtual size, it is functioning as expected (except for a bit of strangeness related to configuring which display is the primary with gnome panels).

Virtual	  2720 1924 is the setting I used that worked for side-by-side expansion.

Thanks,
David
Comment 4 Gordon Jin 2008-12-24 17:45:03 UTC
Thanks for confirming the dup with 17490.

*** This bug has been marked as a duplicate of bug 17490 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.