Bug 104597

Summary: Radeon dualhead broken again
Product: [openSUSE] SUSE LINUX 10.0 Reporter: Christian Boltz <suse-beta>
Component: X.OrgAssignee: Matthias Hopf <mhopf>
Status: VERIFIED DUPLICATE QA Contact: Stefan Dirsch <sndirsch>
Severity: Normal    
Priority: P5 - None CC: forgotten_OS1JNCFbCX, lgrimmer, ms, sndirsch
Version: Beta 1   
Target Milestone: ---   
Hardware: Other   
OS: All   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Xorg.log (with configfile from 9.3)
Working Xorg.conf from 9.3
Xorg.0.log for the 9.3 dualhead config file

Description Christian Boltz 2005-08-14 14:09:33 UTC
It seems someone at X.org doesn't like me ;-)  
  
After updating from 9.3 to 10.0 beta1, Radeon dualhead is broken  
again on my laptop (Acer TravelMate 803).  
I only get the laptop display working, but my external screen  
doesn't get any signal.  
 
I tested with  
- the xorg.conf from 9.3 (with MonitorLayout option set)  
- a newly generated xorg.conf - both of the sax2 profiles for radeon  
  dualhead don't work.  
 
This bug also makes it impossible to use YaST after the initial reboot - I'll 
open a separate bug for this. 
 
I temporarily downgraded to x.org from 9.3 which also works on 10.0. 
What's broken this time?
Comment 1 Christian Boltz 2005-08-14 14:17:23 UTC
Created attachment 45983 [details]
Xorg.log (with configfile from 9.3)
Comment 2 Stefan Dirsch 2005-08-14 14:41:10 UTC
Something for Matthias to investigate. 
Comment 3 Lenz Grimmer 2005-08-15 07:12:48 UTC
FWIW, I am seeing the same strange behaviour on my IBM Thinkpad T42 (Radeon
Mobility 9600). SaX2 failed to create a functional xorg.conf for my external
Samsung SyncMaster 920T (see BUG#104640), so I wanted to revert to my previously
working org.conf from SUSE 9.3, which uses a Xinerama setup that spans both the
internal and the external display (see the xorg.conf attached). X start up, but
I only see a display on the internal panel. The external screen goes in
powersave mode and stays black. However, the Xinerama screen was set up
correctly, as the output of "xdpyinfo" confirms:

[SNIP]
name of display:    :0.0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    60802000
X.Org version: 6.8.2
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 8, 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 0x4200007, revert to PointerRoot
number of extensions:    29
    BIG-REQUESTS
    Composite
    DAMAGE
    DPMS
    Extended-Visual-Information
    GLX
    LBX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    RENDER
    SECURITY
    SGI-GLX
    SHAPE
    SYNC
    TOG-CUP
    X-Resource
    XC-APPGROUP
    XC-MISC
    XFIXES
    XFree86-Bigfont
    XFree86-DGA
    XFree86-Misc
    XFree86-VidModeExtension
    XINERAMA
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
default screen number:    0
number of screens:    1

screen #0:
  print screen:    no
  dimensions:    2680x1050 pixels (907x356 millimeters)
  resolution:    75x75 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32
  root window id:    0x60
  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:    64x64
  current input event mask:    0xfa4031
    KeyPressMask             EnterWindowMask          LeaveWindowMask
    KeymapStateMask          StructureNotifyMask      SubstructureNotifyMask
    SubstructureRedirectMask FocusChangeMask          PropertyChangeMask
    ColormapChangeMask
  number of visuals:    9
  default visual id:  0x23
  visual:
    visual id:    0x23
    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:    0x24
    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:    0x25
    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:    0x26
    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:    0x27
    class:    DirectColor
    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:    0x28
    class:    DirectColor
    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:    0x29
    class:    DirectColor
    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:    0x2a
    class:    DirectColor
    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:    0x5d
    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
[SNIP]
Comment 4 Lenz Grimmer 2005-08-15 07:15:07 UTC
Created attachment 46018 [details]
Working Xorg.conf from 9.3

This is the xorg.conf that used to work for Xinerama on 9.3 - in 10.0 I only
see the internal display.
Comment 5 Lenz Grimmer 2005-08-15 07:15:41 UTC
Created attachment 46019 [details]
Xorg.0.log for the 9.3 dualhead config file
Comment 6 Lenz Grimmer 2005-08-15 08:01:19 UTC
As a workaround, I now copied the radeon_drv.o from SUSE 9.3 into
/usr/X11R6/lib/modules/drivers/ - now the dualhead setup works again.
Comment 7 Stefan Dirsch 2005-08-16 08:08:44 UTC
*** Bug 104598 has been marked as a duplicate of this bug. ***
Comment 8 Matthias Hopf 2005-08-16 10:17:17 UTC
Let's track all Dual Monitor / Radeon problems in a single bug.
See there for a first workaround (clone mode only).

*** This bug has been marked as a duplicate of 104640 ***
Comment 9 Matthias Hopf 2005-08-16 14:23:25 UTC
(In reply to comment #0)
> After updating from 9.3 to 10.0 beta1, Radeon dualhead is broken  
> again on my laptop (Acer TravelMate 803).  

Please test again with beta2 (as soon as it is out), configuring as described in
bug #104640 (external monitor detached during X startup, re-confirm monitor). If
this works then, we at least don't have any regression.

> - the xorg.conf from 9.3 (with MonitorLayout option set)
> - a newly generated xorg.conf - both of the sax2 profiles for radeon  
>   dualhead don't work.  

What do you mean with both profiles? You shouldn't use profiles for radeon for
configuring dual head any more.

Please *always* attach *all* configuration and log files - in your case the 9.3
xorg.conf and the new xorg.conf, the Xorg.0.log for both configs with 10.0b1
Xorg and the Xorg.0.log for 9.3 Xorg.

This time please report to this bug, even though it is marked as duplicate.
Comment 10 Christian Boltz 2007-08-31 12:37:37 UTC
Finally setting this bug to VERIFIED (FIXED) - on 10.3 beta2 everything works out of the box (except a small problem, see bug 306691). Even the framebuffer on tty1 is no longer broken :-)

Whatever you did: Thanks! - and please don't break the driver again, please ;-)