I have a MSI mainboard (RS480M2-IL aka MS-7093) with onboard gfx; ATI Radeon Xpress 200. I'm running FreeBSD/amd64 on it. Recently, a port for Xorg 6.8.99.5 was created, so I installed that. 'Xorg -configure' detects the driver as 'ati' (without an existing xorg.conf), but using either that driver or the 'radeon' driver, I get a garbled display. The 'vesa' driver works, but only up to 1024x768 (my monitor does 1280x1024).
Created attachment 2633 [details] output of 'lspci -v' for the radeon xpress 200 device
Created attachment 2634 [details] Xorg logfile with Radeon Xpress 200
turn off colortiling. it's probably not set up correctly for the xpress chips yet. It should probably be disabled by default for the xpress chips. Add this line: Option "ColorTiling" "false" to your device config.
(In reply to comment #3) > turn off colortiling. it's probably not set up correctly for the xpress chips > yet. It should probably be disabled by default for the xpress chips. Add this > line: > Option "ColorTiling" "false" > to your device config. Yes, this works - sort of. It gives me a normal display, but it freezes the machine completely (ie no activity, no response from ssh shell, does not answer ping) as soon as there is activity on the X display. How to repeat: run 'startx' (default w/ 3 shells), try 'xvinfo' or another command in a shell window. Result: it gives me a screenfull of info, then the machine is dead. If I do nothing in X, the machine does not die.
Created attachment 2642 [details] Xorg logfile with radeon driver and 'Option "ColorTiling" "false"'
comment out the load dri line in your modules section.
(In reply to comment #6) > comment out the load dri line in your modules section. Done, it doesn't make a difference. But I have noticed that if I just use a command like 'echo "some text"' my machine doesn't die, it dies only when I use the 'xvinfo' or 'xdpyinfo' commands (I haven't tested other X commands yet). Also, the vesa driver detects the capabilities of my monitor through ddc without fail, but the radeon driver does not (see attachments after this comment).
Created attachment 2647 [details] Xorg log file with vesa driver This is the Xorg log file when using the vesa driver, and a xorg.conf file which autodetects all the rest. Notice that ddc detection of the monitor is working (and correct).
Created attachment 2648 [details] Xorg log file with the radeon driver, and specified HorizSync and VertRefresh This is a xorg log file when using the radeon driver, and this Monitor section in xorg.conf: Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" HorizSync 32-91 VertRefresh 58-85 EndSection
The vesa driver uses vbe to determine the DDC information. The radeon driver queries it directly. There is no formal support for the xpress200 chips; right now they are treated like RS300 chips. They may require some special handling. Perhaps Michel or Hui has some insight.
I have the same system using Fedora3 with recent Xorg from CVS and I see the same behaviour. Vesa driver is running fine in 1280x1024. Thanks a lot.
(In reply to comment #11) > Vesa driver is running fine in 1280x1024. Interesting. I just found out that if I run the vesa driver in 1280x1024, I have broken text (blurred / garbled for lack of a better word - it is like it has horizontal white stripes through each line of text), but if I run vesa in 1024x768, the text is ok.
I have exactly the same motherboard running X 6.8.99.15 on gentoo 2005.0/AMD64. I installed the ati drivers as well as the open source ones. Here are the results of my testing a) "ati" - X comes up but any attempt to move a window makes it freeze and the window itself breaks up. Didn't try any further to see if the system would freeze too. b) "radeon" - Same as "ati" c) "vesa" - Appears to work but completely freezes the computer intermittently when switching from X to text terminal for example (e.g ctrl-alt-F1. All that is left is a message from the monitor saying "mode not supported" (Syncmaster 171s). Any help much appreciated. Attachments to follow. Raphael
Created attachment 3237 [details] xorg.conf
Created attachment 3238 [details] xorg log
Created attachment 3239 [details] dmesg
Created attachment 3240 [details] lspci
Created attachment 3241 [details] faulty document
Has anyone tried the patch at http://www.c.csce.kyushu-u.ac.jp/~kenta/index.php?plugin=attach&refer=Linux%20on%20RS480&openfile=XOrg-6.8.2-XPRESS200.patch at the Japanese web site http://www.c.csce.kyushu-u.ac.jp/~kenta/index.php?Linux%20on%20RS480 ? It appears not to be in 6.8.99.15 yet but I may be mistaken. Raphael
(In reply to comment #19) > Has anyone tried the patch at > http://www.c.csce.kyushu-u.ac.jp/~kenta/index.php?plugin=attach&refer=Linux%20on%20RS480&openfile=XOrg-6.8.2-XPRESS200.patch > > at the Japanese web site > > http://www.c.csce.kyushu-u.ac.jp/~kenta/index.php?Linux%20on%20RS480 > > ? > > > It appears not to be in 6.8.99.15 yet but I may be mistaken. > Raphael The above patch just adds the PCI id. That id has been in xorg cvs for 4 months now: http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_chipset.h?rev=1.4&view=markup
Created attachment 3254 [details] [review] HEAD patch 2/2: Add missing locking to _cairo_scaled_glyph_lookup I forgot to give the result of using fglrx. X won't even start finishing with the error (EE) No devices detected. Fatal server error: no screens found
The fglrx problem is solved. Two things are needed One is that you can't use the latest ati-drivers for xpress 200. You have to use 8.13.4 NOT 8.14.13-r2 (at least under gentoo). Secondly it won't work unless you use X 6.8.2. 6.8.99.15 is NOT supported. fglrx works great now. Just vesa and radeon that are flaky/broken. Raphael
You might try adding chipid 0x5B60 to your device section using the radeon driver. It could be that the xpress200s are more like rv370s than rs300s. I just guessed when I added the pci ids. ati hasn't released any documentation on the xpress chipsets.
(In reply to comment #23) > You might try adding > chipid 0x5B60 > to your device section using the radeon driver. Did this work?
I have a motherboard with ATI Radeon XPress200 chipset RC410 (chip id 5a61). Is there a way now for making xorg running with radeon driver ? It work's with VESA generic driver but i'm not able to play correctly videos with Mplayer.
Can you try the ati-1-0-branch driver ?
I'm on Freebsd, How can i do that ?
You check out that current branch from the cvs.
jmd, are you still experiencing this issue using a current version of xorg and the ati driver?
(In reply to comment #29) > jmd, are you still experiencing this issue using a current version of xorg and > the ati driver? FWIW, I still need the 'ChipID 0x5b60' in the Device Section on my xorg.conf. If that line is removed, no devices are detected. This is with FreeBSD 6.1-stable from May 10th, 2006 Xorg 6.9.0
(In reply to comment #30) > FWIW, I still need the 'ChipID 0x5b60' in the Device Section on my xorg.conf. > If that line is removed, no devices are detected. > This is with > FreeBSD 6.1-stable from May 10th, 2006 > Xorg 6.9.0 If your (5954) id is not detected with xorg 6.9/7.0 that would probably be because you're using the ati wrapper, as that id has been added to the radeon driver (but forgotten to be added to the wrapper) before xorg 6.9/7.0 release. Try using radeon as driver directly instead of that deprecated mess. In any case, it ought to be fixed with xorg 7.1. Some feedback on tiling would be nice, while it's disabled by default and doesn't make much sense if dri is not enabled (because it doesn't work) anyway I'm actually not sure anyone has tested it on rs400 igps.
(In reply to comment #31) > If your (5954) id is not detected with xorg 6.9/7.0 that would probably be > because you're using the ati wrapper, as that id has been added to the radeon > driver (but forgotten to be added to the wrapper) before xorg 6.9/7.0 release. > Try using radeon as driver directly instead of that deprecated mess. I am using the radeon driver. > In any case, it ought to be fixed with xorg 7.1. xorg 7.1 isn't in the FreeBSD ports tree yet. :-/
Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status. Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.
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.