Even old and well-woking xorg.confs do not work any more. My external monitor is completely out of sync, my internal monitor does not display anything. It is the same for newly SaX-configured xorg.confs. xorg-x11-driver-video-radeonhd-1.2.5_20090901_f7ad938-1.1.x86_64 xorg-x11-server-7.4-51.4.x86_64
Created attachment 29522 [details] legacy xorg.conf that does not work any more
Xorg.0.log please.
Created attachment 29541 [details] Xorg.0.log
Just before it has started the external monitor (internal stayed black) which was out of sync. Now both screens stay black: xorg-x11-driver-video-radeonhd-1.2.5_20090901_f7ad938-9.1
Try using a minimal xorg.conf (with just the Device section) and let Xorg auto-detect the monitors.
Well, the X-server actually starts with a minimal xorg.conf like Suses xorg.conf.install, but the screens section of xrandr -q is multilated so that I can not even configure xinerama mode with hindsight: Screen 0: minimum 1600 x 1200, current 1600 x 1200, maximum 1600 x 1200 default connected 1600x1200+0+0 0mm x 0mm 1600x1200 77.0* I would regard the suppport of xorg.confs as mandatory for a well working driver, because this is the only way to prefconfigure xinerama mode (left-of, right-of), to configure the screen size which is important to let KDE3 use the right font size, to preconfigure the keyboard layout and to configure the right freuqency for the monitor to get a stable picture (lately often out of sync). Besides this xorg.conf has always let me tweak the hw-accelaration mode and is therefore important for comprehensive testing. Please resolve this as soon as possible!! Otherwise I will stop my engagement in testing radeonhd and will simply use fglrx. The main advantage of radeonhd over fglrx has always been the good xinerama support. If this is not given any more (minimal xorg.confs only) there will to my mind be no sense in using radeonhd any more.
Please attach the Xorg.0.log with the new xorg.conf, and also the output of `xrandr --verbose'. Feel free to add the layout stuff back in. The point of having you try the minimal config is to check whether the displays are providing sane EDIDs, if they exist. A quick look of your log shows the driver setting the modes provided in xorg.conf. Also remember to set your Virtual value.
How to set the virtual value?
Created attachment 29554 [details] Xorg.0.log for xorg.conf.install
Created attachment 29555 [details] xorg.conf.install
> xrandr --verbose Screen 0: minimum 1600 x 1200, current 1600 x 1200, maximum 1600 x 1200 default connected 1600x1200+0+0 (0x44) normal (normal) 0mm x 0mm Identifier: 0x43 Timestamp: 25168 Subpixel: unknown Clones: CRTC: 0 CRTCs: 0 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: 1600x1200 (0x44) 147.8MHz *current h: width 1600 start 0 end 0 total 1600 skew 0 clock 92.4KHz v: height 1200 start 0 end 0 total 1200 clock 77.0Hz P.S. Please notify me as soon as possible when Xinerama setup should work again.
xorg.conf from installation uses fbdev driver by default - by intention! fbdev driver does not support RANDR 1.2 like radeonhd does. Do not use any xorg.conf and the RANDR 1.2 capable radeonhd driver will be chosen by default - unless you have fglrx installed. In that case the latter driver will be used.
It does not work without an xorg.conf. The external monitor will be completely out of sync and the internal monitor will stay black. Besides this I want the xinerama and screen size preconfiguration of my legacy xorg.conf to be used. No way to specify this without an xorg.conf. Radeonhd will still need to support xorg.confs even if it supports the HDMI plug and play mechanism.
Try the following xorg.conf. We still need to see an actual log from an auto-detected session with radeonhd before going further. Section "Device" Identifier "ATI Mobility RadeonHD 2600" Driver "radeonhd" EndSection Section "Screen" Identifier "Default" Device "ATI Mobility RadeonHD 2600" SubSection "Display" Depth 24 Virtual 3840 1200 EndSubSection EndSection
Created attachment 29595 [details] Xorg.0.log for xorg.conf of Comment #14 Sorry for my late reply. I have put a rescue xorg-anc repo online for people who experience problems with the current release (http://suse.elstel.com/radeonhd).
The driver detects a 1920x1200 panel - is that what your laptop has? If not, there's an issue with panel detection, but apparently your laptop's AtomBIOS doesn't have dedicated panel information, which is kind of odd. Now does the panel work with the minimal xorg.conf you posted?
1920x1200 is correct for both - the external and internal screen. Nonetheless my external monitor was out of sync. It has shown blurry columns in motion - an error which I knew for old vga ray tubes on misconfigured xorg horiz/vert sync rates. I am not absolutely sure if the internal monitor has shown something with the new xorg.conf. Otherwise there is no difference between using the posted xorg.conf and no xorg.conf (Please don`t let me test again until you have a fix for the sync-rates of my external monitor - I always have to reinstall the old radeonhd drivers afterwards!).
(In reply to comment #17) > ...It has shown blurry columns in motion... I'm assuming your external monitor is a LCD. Is it driven with VGA/DVI-A or DVI-D? > I am not absolutely sure if the internal monitor has > shown something with the new xorg.conf. Otherwise there is no difference > between using the posted xorg.conf and no xorg.conf We need to know about the internal panel as well, since you're saying there's issues with it as well as the externally connected display. Try leaving the external monitor unplugged and see if at least the panel come up correctly. > (Please don`t let me test > again until you have a fix for the sync-rates of my external monitor - I always > have to reinstall the old radeonhd drivers afterwards!). This is an isolated issue so you're the only one that can run relevant tests. We can't provide you with a solution until we actually know what the cause of the problem is.
My external monitor is connected via HDMI and should support Plug&Play. I will test the internal monitor soon. Wouldn`t it be possible for you to keep old-style xorg.confs supported, so that I do not have to up-/downgrade my whole Xorg for every test again and again. Perhaps we will get other similar issues. Hardware(or Firmware) isn`t free of bugs either.
"Old style" (as you call it) xorg.confs are actually supported. If it doesn't work, there's a bug.
Hm, this looks actually good: (II) RADEONHD(0): Output PANEL connected (II) RADEONHD(0): Output TV_7PIN_DIN disconnected (II) RADEONHD(0): Output DVI-D_1 connected (II) RADEONHD(0): Output VGA_1 disconnected (II) RADEONHD(0): Using exact sizes for initial modes (II) RADEONHD(0): Output PANEL using initial mode 1920x1200 (II) RADEONHD(0): Output DVI-D_1 using initial mode 1920x1200 You say that this doesn't work any more - which version of the driver did work? I guess you have to git bisect the driver to the exact git commit that broke this - because this is so unusual, and we have never seen anything similar before. BTW - you can copy the old, working driver somewhere else (e.g. /var/tmp/xorg_modules) and then add ModulePath "/var/tmp/xorg_modules" ModulePath "/usr/lib64/xorg/modules/updates,/usr/lib64/xorg/modules" to the Files section to activate the old driver. Then just comment out the /var/tmp/xorg_modules line to use the regularly installed driver. Of course, you can also do it the other way round, and install the driver to be tested (non-working) somewhere else. That's probably the better idea, stick with a working driver in the system, and use the ModulePath for a driver to be tested.
xorg-x11-driver-video-radeonhd-1.2.5_20090506_4be5f71-2.13.x86_64.rpm does definitely work. thx; - am going to try the dual driver install now.
Created attachment 29601 [details] Xorg.0.log: internal screen only The internal/attached screen always stays dark even if I unplug the external monitor. The ext monitor is out of sync (flurry). yippee - dual driver install is fine and working well.
In that case we have no chance but to git bisect this issue. There are quite a number of descriptions in the web (also I think in this bugzilla) how to do that (we probably should add one to the radeonhd wiki) - if you have any issues tell me and I'll guide you through the process. The openSUSE packages have the according git commit ids in the package name. For you that means: good = 4be5f71 bad = f7ad938
What does git-bisect mean; who should do it?
prusnak has confirmed this; see at the OpenSuse most annoying bugs (http://suse.elstel.com/qa). He is right: in a fact my screen is not black but very very dark (If I darken my room I can see something.). However increasing the backlight does not improve things at me. confirmed for xorg-x11-driver-video-radeonhd-1.2.5_20090914_37ccdde-1.4.
(In reply to comment #26) > He is right: in a fact my screen is not black but very very dark (If I darken > my room I can see something.). However increasing the backlight does not > improve things at me. Is the backlight actually on? Can you verify that the output of `rhd_dump -l 0 <pci_id>` is sane? It should be a list of increasing values ending at 3FF.
No rhd_dump utility is shipped with the standard SuSE packages. Perhaps you could give me some links or advice on how to build Xorg&radeonhd by the OSuse-Build-Service since I am lacking other debugging tools, too: color-palette-dump.
(In reply to comment #28) > No rhd_dump utility is shipped with the standard SuSE packages. > Perhaps you could give me some links or advice on how to build Xorg&radeonhd > by the OSuse-Build-Service since I am lacking other debugging tools, too: > color-palette-dump. $ sudo zypper in make automake libtool xorg-x11-server-sdk gcc pciutils-devel $ wget http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/snapshot/xf86-video-radeonhd-1.2.5.tar.bz2 $ tar xjf xf86-video-radeonhd-1.2.5.tar.bz2 $ cd xf86-video-radeonhd-1.2.5 $ ./autogen.sh $ cd utils/conntest/ $ make $ sudo cp ./rhd_dump /sbin/ $ sudo rhd_dump -l 0 1:00.0 you may need other pci id.
Will probably need to install a whole self-compiled radeonhd as the seperately compiled radeonhd-rhd_dump refuses to work: > lspci 01:00.0 VGA compatible controller: ATI Technologies Inc M76XT [Mobility Radeon HD 2600 XT] > rhd_dump -l 0 01:0.0 rhd_dump: v1.2.5, non-git sources Speicherzugriffsfehler (memory access error)
(In reply to comment #30) > > rhd_dump -l 0 01:0.0 > rhd_dump: v1.2.5, non-git sources > Speicherzugriffsfehler (memory access error) Err, ups. Did we have some bug in rhd_dump in 1.2.5? Don't remember... You can try git version of radeonhd: $ sudo zypper in git $ git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-radeonhd $ cd xf86-video-radeonhd $ ./autogen.sh and so on...
This is probably another fallout of git commit #de3f80b. I have disabled this commit in the latest package for openSUSE. You can test the package from the X11:Drivers:Video buildservice repository. Regarding rhd_dump: Did you call this as root? You have to...
Created attachment 30209 [details] rhd-dump & other files note: There is not only the darkness issue of my integrated display but my external display is out of sync so that I have to move windows to sepcial locations in order being able to read their content.
There are two major (and wierd) bugs fixed in latest git master - you might want to try that. If it doesn't work, please git-bisect the issue, I've written up a description how to do that here: http://www.x.org/wiki/radeonhd#head-21026d3aec5e838d5692e50e28dc304567b274c9 You want to start with git bisect start f7ad938 4be5f71
Luckily the color palette issue (dark screen) has been resolved with xorg-x11-driver-video-radeonhd-1.2.5_20091001_be7216f-2.2. Nonetheless now still both screens (integrated & external one) are out of sync.
Created attachment 30211 [details] scrs out of sync: Xorg -logverbose & rhd_dump
1.3.0 fixes a number of DDC related issues - you might want to retry that. Though I fear that this doesn't fix your problem.
Created attachment 30347 [details] rhd-dump with radeonhd-1.2.5_20091001_be7216f-13.1 Screen still out of sync with newest radeonhd: > pkgs radeonhd xorg-x11-driver-video-radeonhd-1.2.5_20091001_be7216f-13.1
The monitors should not be out of sync if they used the modeline configuration specified in my xorg.conf. Can you assert that the xorg- modeline configurations are in deed used as soon as they are specified in xorg.conf as you have promised me in Comment #20? We should have to remove the modelines in order to test auto-configuration!
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
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.