Bug 28571 - External screen at offset does not work
Summary: External screen at offset does not work
Status: RESOLVED DUPLICATE of bug 28515
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Carl Worth
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-16 03:35 UTC by Nathan Samson
Modified: 2010-06-24 10:28 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Complete Xorg log (38.20 KB, text/x-log)
2010-06-16 03:35 UTC, Nathan Samson
no flags Details
intel_reg_dumper when VGA is at pos 1280x0 (8.61 KB, application/octet-stream)
2010-06-16 03:36 UTC, Nathan Samson
no flags Details

Description Nathan Samson 2010-06-16 03:35:22 UTC
Created attachment 36309 [details]
Complete Xorg log

Placing an external screen at an offset does not work (results in screen corruption and other bad things)

Note: I'm using https://edge.launchpad.net/~xorg-edgers/+archive/ppa on lucid (with the 2.6.35 kernel) and having a GMA 950 graphic card. I'm using dri-gallium (Living on the edge is quite cool :p)

I do have a laptop panel of 1280x800 and an external screen of 1680x1050. I want to place the next to each other so I have a desktop width of 2960. When I enable the external screen at position 0x0 all works well, but when I do xrandr --output VGA1 --pos 1280x0 the external screen becomes corrupted (not usable at all).

* xrandr --output VGA1 --auto
In Xorg.log comes:
[  2831.079] (II) intel(0): EDID vendor "APP", prod id 40031
[  2831.079] (II) intel(0): Printing DDC gathered Modelines:
[  2831.079] (II) intel(0): Modeline "1280x800"x0.0   71.00  1280 1328 1360 1440  800 803 809 823 -hsync -vsync (49.3 kHz)
[  2831.648] (II) intel(0): Allocated new frame buffer 1728x1050 stride 8192, tiled

Framebuffer size is suspicious already if you ask me...

xrandr --output VGA1 --pos 1280x0
Xrandr ends with
nathan@gamma:~$ xrandr --output VGA1 --pos 1280x0
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  149 (RANDR)
  Minor opcode of failed request:  7 (RRSetScreenSize)
  Serial number of failed request:  28
  Current serial number in output stream:  29

Excerpt of xorg log
[  2928.719] (II) intel(0): EDID vendor "APP", prod id 40031
[  2928.719] (II) intel(0): Printing DDC gathered Modelines:
[  2928.719] (II) intel(0): Modeline "1280x800"x0.0   71.00  1280 1328 1360 1440  800 803 809 823 -hsync -vsync (49.3 kHz)
[  2928.856] (EE) intel(0): Failed to allocate framebuffer.
[  2928.865] (II) intel(0): Allocated new frame buffer 1728x1050 stride 8192, tiled


Then doing an "xrandr" (to see what current config is)
nathan@gamma:~$ xrandr
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 4096 x 4096
VGA1 connected 1680x1050+1280+0 (normal left inverted right x axis y axis) 459mm x 296mm
   1680x1050      59.9*+
   1280x1024      75.0     60.0  
   1280x960       60.0  
   1152x864       75.0  
   1024x768       75.1     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        72.8     75.0     66.7     60.0  
   720x400        70.1  
LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 286mm x 179mm
   1280x800       59.9*+
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
DVI1 disconnected (normal left inverted right x axis y axis)
TV1 disconnected (normal left inverted right x axis y axis)


I notice 2 things: Screen0 is 1680 x 1050, not what I expect, but VGA1 has the offset...




Note: I was collecting this info (trying to reproduce these xrandr crash errors etc, and while I was doing this I saw at a moment in the xorg log a GPU hang being reported) - This maybe another bug...
[  2056.230] (EE) intel(0): Detected a hung GPU, disabling acceleration.
[  2056.400] (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/ou
tput error
(I'm not sure what I did at that point, but I was fiddling as now with xrandr, only I cant reproduce it now)

And then I was so stupid to run glxgears, and I was rewarded with an Xorg crash (from my old xorg log)
[  2493.446] 
Backtrace:
[  2493.447] 0: /usr/bin/X (xorg_backtrace+0x28) [0x4647f8]
[  2493.447] 1: /usr/bin/X (0x400000+0x6442d) [0x46442d]
[  2493.447] 2: /lib/libpthread.so.0 (0x7fdff6cb2000+0xf8f0) [0x7fdff6cc18f0]
[  2493.447] 3: /usr/lib/xorg/modules/extensions/libdri2.so (0x7fdff4084000+0x2e
7d) [0x7fdff4086e7d]
[  2493.447] 4: /usr/lib/xorg/modules/extensions/libdri2.so (0x7fdff4084000+0x35
b4) [0x7fdff40875b4]
[  2493.447] 5: /usr/bin/X (0x400000+0x3068c) [0x43068c]
[  2493.447] 6: /usr/bin/X (0x400000+0x2616a) [0x42616a]
[  2493.447] 7: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fdff5c1cc4d]
[  2493.447] 8: /usr/bin/X (0x400000+0x25d19) [0x425d19]
[  2493.447] Segmentation fault at address (nil)
[  2493.474] 
Caught signal 11 (Segmentation fault). Server aborting
Comment 1 Nathan Samson 2010-06-16 03:36:45 UTC
Created attachment 36310 [details]
intel_reg_dumper when VGA is at pos 1280x0
Comment 2 Chris Wilson 2010-06-24 10:28:53 UTC
The core of the bug, the failed xrandr, is bug 28515 and should be now fixed:

commit 726210f87d558d558022f35bc8c839e798a19f0c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jun 24 11:38:00 2010 +0100

    intel: Limit tiled pitches to 8192 on pre-i965.
    
    Fixes:
    
      Bug 28515 - Failed to allocate framebuffer when exceed 2048 width
      https://bugs.freedesktop.org/show_bug.cgi?id=28515
    

The other oddities I am less certain about, there definitely seems to be room for improvement following the modesetting error. The GPU hang may be a result of this error, some internal inconsistency, or another application submitting a bad batch buffer to the GPU. Difficult to say, and if you can reproduce any of these in isolation, please file a bug.

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


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.