Bug 21423

Part of bug report translated to english:
> startx ends with a white screen, and cursor-x in the middle.

Important parts of attached Xorg.0.log:
(--) RADEONHD(0): Detected an RV730 on an unidentified card
(WW) RADEONHD(0): rhdAtomAllocateFbScratch: FW FB scratch area not located at the end of VRAM. Scratch End: 0x84fec VRAM End: 0x10000000
(EE) RADEONHD(0): RHDHdmiInit: unknown HDMI output type
(WW) RADEONHD(0): RHDCSInit: No CS for R600 and up yet.
last 2 lines:
(II) RADEONHD(0): Query for Restore Registers: failed
(II) RADEONHD(0): Query for Restore Registers: failed

Some other reports about this issue (from the older):
http://lists.opensuse.org/radeonhd/2009-02/msg00080.html
http://lists.opensuse.org/radeonhd/2009-03/msg00298.html
http://lists.opensuse.org/radeonhd/2009-04/msg00062.html
http://lists.opensuse.org/radeonhd/2009-04/msg00264.html

I think it wasn't reported as regression even once.

Do you remember the version of the driver that worked last?

The driver is working flawlessly with an RV730 here on os11.1, so there's a subtle difference between our hardware and yours.

BTW - the 'Query for Restore Registers: failed' is apparently not harmful (I get it as well, though I don't know the origins by memory). It's neither a warning nor an error either.

(In reply to comment #3)
> Do you remember the version of the driver that worked last?
> 
> The driver is working flawlessly with an RV730 here on os11.1, so there's a
> subtle difference between our hardware and yours.
> 

Sorry, i do not know the version-number which worked last. It worked fine with the version that came with os-11.1, and broke with the upgrade from kde-4.1.3 to kde-4.2.2, and never worked again. In the meantime. i tried the following radeonhd versions from the database:
1.2.3_081202, 1.2.5-5.1, 1.2.5-7.1, 1.2.5post_090425_8932f43-1.1, 1.2.5post_090430357f190-1.1, and debuginfo-1.2.5-7.1, always the x86_64 version. All fail with 'RHDHdmiInit: unknown HDMI output type'.
Peter

The 'RHDHdmiInit: unknown HDMI output type' message should uncorrelated - the port is still added as DVI output (HDMI handling in our AtomBIOS system is sub-optimal, still).
I'll ask Stefan on Wednesday which version we originally shipped with 11.1.

But chances are that this breaks not due to the driver version but due to some other upgrade (xserver, etc.). This still may indicate a bug in radeonhd, though.

One idea: maybe the KDE upgrade started a compositing manager, even though dri is not yet available. Can you try a failsafe session?

> I'll ask Stefan on Wednesday which version we originally shipped with 11.1.

Just browse http://download.opensuse.org/distribution/11.1/repo/oss/suse/x86_64/

xorg-x11-driver-video-radeonhd-1.2.3_081202_ed532a7-1.1.x86_64.rpm

X Server version is in attached Xorg.0.log:
> X.Org X Server 1.5.2

(In reply to comment #6)
> The 'RHDHdmiInit: unknown HDMI output type' message should uncorrelated - the
> port is still added as DVI output (HDMI handling in our AtomBIOS system is
> sub-optimal, still).
> I'll ask Stefan on Wednesday which version we originally shipped with 11.1.
> 
> But chances are that this breaks not due to the driver version but due to some
> other upgrade (xserver, etc.). This still may indicate a bug in radeonhd,
> though.
> 
> One idea: maybe the KDE upgrade started a compositing manager, even though dri
> is not yet available. Can you try a failsafe session?
> 
Just tried a failsave boot based on 2.6.27.21-0.1 as provided  in the GRUB menu by the installation of 11.1, but no change at all. I still believe the reason is caused by the KDE-4.2.2 OCI upgrade, because after the first beak, i did a new install, which worked fine up to the KDE upgrade. The upgrade is necessary because KDE-4.1.3 is so unstable that i concider it unusable.
(btw, i did the same with a VAJO notebook, and KDE-4.2.2 works almost perfect.
Onboard video-hw here js INTEL 945-GM) 
Peter.

(In reply to comment #7)
> > I'll ask Stefan on Wednesday which version we originally shipped with 11.1.
> 
> Just browse
> http://download.opensuse.org/distribution/11.1/repo/oss/suse/x86_64/
> 
> xorg-x11-driver-video-radeonhd-1.2.3_081202_ed532a7-1.1.x86_64.rpm
> 
> X Server version is in attached Xorg.0.log:
> > X.Org X Server 1.5.2
> 
I tried to fall back to the 1.2.3... version by copying it from the installation-dvd and then installing it, but no change.

btw, the wrong-hdmi-type message is an (EE) type message which gives me the impression (from the logs) that it stops the execution of the radeonhd-driver.
Peter

One more thing:

please try

'X -ac & sleep 2 ; DISPLAY=:0 xterm'

and check whether you get anything reasonable (i.e. not a white screen). There should be an xterm running.

If you get the xterm, please do 'glxinfo > glxinfo.log' and attach the logfile.

Also, please attach your /etc/X11/xorg.conf.

Created attachment 25485 [details]
glxinfo.zip, contents: glxinfo.log and xorg.conf

(In reply to comment #10)
> One more thing:
> 
> please try
> 
> 'X -ac & sleep 2 ; DISPLAY=:0 xterm'
> 
> and check whether you get anything reasonable (i.e. not a white screen). There
> should be an xterm running.
> 
> If you get the xterm, please do 'glxinfo > glxinfo.log' and attach the logfile.
> 
> Also, please attach your /etc/X11/xorg.conf.
> 
Did as requested, worked as described. glxinfo.zip is sent, containing requested files.
Peter

As I assumed - this is presumably not a radeonhd issue, but a combination of KDE trying to use composite (probably using OpenGL), the logic of detecting whether 3D acceleration is available being broken (as Mesa now returns Direct Rendering: yes even for software rasterization), and the GLX_EXT_texture_from_pixmap being broken in the software rasterizer case.

An easy workaround would be - AFAIR - to disable the Composite extension in the Xserver: Add
  Option "Composite" "off"
in the "Extensions" section of your xorg.conf. If that doesn't help a KDE guru should help you how to switch of compositing by editing a KDE config file.

(In reply to comment #13)
> As I assumed - this is presumably not a radeonhd issue, but a combination of
> KDE trying to use composite (probably using OpenGL), the logic of detecting
> whether 3D acceleration is available being broken (as Mesa now returns Direct
> Rendering: yes even for software rasterization), and the
> GLX_EXT_texture_from_pixmap being broken in the software rasterizer case.
> 
> An easy workaround would be - AFAIR - to disable the Composite extension in the
> Xserver: Add
>   Option "Composite" "off"
> in the "Extensions" section of your xorg.conf. If that doesn't help a KDE guru
> should help you how to switch of compositing by editing a KDE config file.
> 
Thanks, however the workaround did not help at all.
I opened bug no.191813 in bugs.kde.org 5 minutes ago, and will report the progess here asap.
I will be out of town starting tomorrow morning till may-18th, so i cannot checkout things in this period, however i will follow-up on both bugs daily and answer questions whenever possible.
thx, Peter 

Does this issue occur with the preferred ati driver (xf86-vide-ati)?  If so, please move this to the Driver/Radeon component.  

Development of radeonhd has pretty much halted and development focus is on the ati driver.  Please see http://www.x.org/wiki/radeonhd

If the issue does not exist in the ati driver (or if there is no response to this message), this bug will be closed as WONTFIX unless someone contributes a patch.

Closing due to lack of response.  Please reopen and move to the Driver/Radeon 
component if this issue persists with xf86-video-ati