Running Ubuntu dapper, with the latest CVS version of
http://webcvs.freedesktop.org/xorg/driver/xf86-video-ati/ installed. The PCI ID
of my graphics card is (1002:)5d4f, which should be supported. The
manufacturer/model is Sapphire's X800 GTO Ultimate 256MB. The motherboard is a
RS482-based ATI board.
With "ati" driver (default after ubuntu's gfx detection), X doesn't start at
all. With "radeon" specified, X starts but only with 640x480 resolution whatever
This bug's aim would probably to have at least 2D working at higher resolutions,
and also have "ati" driver working correctly, ie. delegating the handling of gfx
to "radeon" driver. I can also get some debug output about eg. some variables at
some point in the driver code, if someone would like to know something more
specific. I've only casually looked at the driver code (and X is quite unknown
to me in other ways too), so I would need some specific points to study to
uname -a: Linux test-desktop 2.6.15-21-amd64-generic #1 SMP PREEMPT Fri Apr 21
16:42:20 UTC 2006 x86_64 GNU/Linux
Module Size Used by
rfcomm 45600 0
l2cap 30464 5 rfcomm
bluetooth 59268 4 rfcomm,l2cap
radeon 116768 0
drm 95656 1 radeon
powernow_k8 12992 1
cpufreq_powersave 3328 0
cpufreq_stats 8264 0
cpufreq_userspace 9184 1
cpufreq_ondemand 9768 0
cpufreq_conservative 10984 0
freq_table 6464 2 powernow_k8,cpufreq_stats
tc1100_wmi 9096 0
video 18824 0
acpi_sbs 24600 0
battery 12296 1 acpi_sbs
i2c_acpi_ec 7040 1 acpi_sbs
container 6272 0
button 8864 0
pcc_acpi 16128 0
sony_acpi 7060 0
ac 7176 1 acpi_sbs
dev_acpi 15364 0
hotkey 13768 0
ext3 145936 1
jbd 70952 1 ext3
ipv6 300416 8
dm_mod 63176 1
md_mod 76792 0
af_packet 28172 2
tuner 46244 0
tvaudio 28316 0
msp3400 36300 0
bttv 201296 0
video_buf 27012 1 bttv
i2c_algo_bit 11144 1 bttv
v4l2_common 9088 1 bttv
btcx_risc 6792 1 bttv
tveeprom 19344 1 bttv
i2c_core 26624 7
tsdev 10240 0
videodev 13696 1 bttv
snd_hda_intel 21664 0
8139too 31744 0
8139cp 26880 0
snd_hda_codec 170952 1 snd_hda_intel
floppy 74120 0
mii 7680 2 8139too,8139cp
snd_pcm_oss 59424 0
snd_mixer_oss 20608 1 snd_pcm_oss
ohci1394 37452 0
ieee1394 369688 1 ohci1394
snd_pcm 104712 3 snd_hda_intel,snd_hda_codec,snd_pcm_oss
snd_timer 29064 1 snd_pcm
snd 68576 6
soundcore 13216 1 snd
snd_page_alloc 13968 2 snd_hda_intel,snd_pcm
rtc 16760 0
pcspkr 3592 0
psmouse 40452 0
serio_raw 9732 0
shpchp 51360 0
pci_hotplug 33168 1 shpchp
sg 43568 0
sr_mod 19748 0
cdrom 41144 1 sr_mod
evdev 14464 1
reiserfs 257904 3
ide_generic 2816 0
ehci_hcd 34568 0
ohci_hcd 23684 0
usbcore 145980 3 ehci_hcd,ohci_hcd
atiixp 8464 1
sd_mod 21504 6
sata_sil 12292 10
libata 82328 1 sata_sil
scsi_mod 160248 4 sg,sr_mod,sd_mod,libata
generic 7300 0
thermal 16524 0
processor 29224 2 powernow_k8,thermal
fan 6408 0
capability 7176 0
commoncap 9728 1 capability
vga16fb 14864 1
cfbcopyarea 5120 1 vga16fb
vgastate 10368 1 vga16fb
cfbimgblt 4224 1 vga16fb
cfbfillrect 5760 1 vga16fb
fbcon 43136 72
tileblit 4096 1 fbcon
font 9984 1 fbcon
bitblit 7424 1 fbcon
softcursor 3712 1 bitblit
Created attachment 5527 [details]
Created attachment 5528 [details]
Created attachment 5529 [details]
Created attachment 5530 [details]
Xorg.0.log using the default "ati" driver (ie. X doesn't start).
Created attachment 5531 [details]
Xorg.0.log using "radeon" (ie. X starts but only in 640x480 mode)
Created attachment 5532 [details]
Forgot to mention that I also tried ati-1-0-branch, even though I didn't yet
find information what's different in that. Same results ("ati" does not work /
"radeon" gives 640x480).
Unless you really have two monitors connected, the 640x480 limit is probably due
to bug 5623.
As for the ati wrapper failing, that's probably the PCI ID missing in one of the
I have an LCD monitor and TV connected. Disconnecting TV-out and rebooting
doesn't change a thing. However, Option "MonitorLayout" "TMDS,NONE" seems to fix
this problem as pointed out in bug 5623, but of course the detection should
succeed automatically. Now running successfully at 1280x1024.
About the ati-wrapper problem: I can't find a place in code where 5D4F wouldn't
be mentioned where other X800-series cards are, so it might be it's not just a
missing PCI ID. I checked atipciids.h, radeon_chipset.h, radeon_driver.c and
radeon_probe.c. It probably does not matter that this is not really a "X850 Pro"
card but one of these rebranded X800 GTO cards.
(In reply to comment #9)
> About the ati-wrapper problem: I can't find a place in code where 5D4F wouldn't
> be mentioned where other X800-series cards are, so it might be it's not just a
> missing PCI ID. I checked atipciids.h, radeon_chipset.h, radeon_driver.c and
> radeon_probe.c. It probably does not matter that this is not really a "X850 Pro"
> card but one of these rebranded X800 GTO cards.
Yes, that shouldn't matter at all. I think something might go wrong in the
ATIProbe function. Can't see what though at first glance, you could add some
printfs to that function-from-hell to see what's going on - I think ultimately
it should just end up calling that RadeonProbe function in the end, however I
can't even tell if it's expected that you get a warning that the device could
(naturally) not be attached as a mach64. The ati wrapper is kinda deprecated
though and may be removed in the future, I don't think anyone is really
interested in it and working on it. I certainly get a headache from looking at it.
Created attachment 5567 [details] [review]
A nice function, that is. Anyway, the attached example patch let's the radeon
driver do it job for me.
In the first part, if it's looking for Mach64's, is that kind of using of
ATIChipID a completely wrong thing to do? Without it, the code dwells into that
part of the code and yields "PCI Mach64 (...) could not be detected".
The second part is of course just a hack, but combined with the previous part:
is that pVideo->size supposed to be some completely trustworthy thing to say
if a chip is a Mach64 (if FALSE) or something else (if TRUE)? Because in first
part it's false with my card, the code dwells into Mach64 code, and in the
second part the whole "look for block I/O devices"-code is skipped because of
I first used only the first part of the patch, and noticed that then it skipped
Mach64 code but also skipped block I/O devices code and found nothing.
Created attachment 5568 [details]
Xorg.0.log created with startx when using the patched version of the driver.
This is a description of two bugs. This bug needs to be split into two bugs.
1. The first bug that is covered is that the Sapphire Radeon X800 GTO is not
detected using the "ati" wrapper.
2. The second bug is that the driver won't change the resolution to anything
higher than 640x480 using the dvi output. Modelines work correctly when using
the vga output, in other words I have 1600x1200 using the vga output.
Pertaining to the first bug, I checked the radeon atipciids.h, and the pci id is
listed. For some reason the "ati" wrapper wants to detect the card as a mach64.
I saw the message detecting an X300SE on the second pci bus address as a mach64
(In reply to comment #13)
> 2. The second bug is that the driver won't change the resolution to anything
> higher than 640x480 using the dvi output. Modelines work correctly when using
> the vga output, in other words I have 1600x1200 using the vga output.
As pointed out before, this is probably bug 5623.
> For some reason the "ati" wrapper wants to detect the card as a mach64.
I think that's just the ati wrapper's way of saying 'I have no idea what this
is; I tried treating it as a Mach64 eventually, but it didn't work'.
(In reply to comment #14)
> I think that's just the ati wrapper's way of saying 'I have no idea what this
> is; I tried treating it as a Mach64 eventually, but it didn't work'.
Well, I (think I) found that it's not like that. It looks like it is actually
detected as Mach64, and it's never even tried to be found out whether it's
Radeon or not (as Mach64 detection comes before Radeon). If you check the
portion of the patch in the code, it looks like the ati wrapper thinks a card is
a Mach64 if:
1. Chip is not MACH32 (but still made by ATI)
2. pVideo->size == FALSE
(if the chip is MACH32 or the 2. is TRUE, it continues to Radeon model detection)
Please correct if I'm wrong, but that's how it currently looks to me (though I
might very easily miss something the function is doing). And similarly, if a
Mach64 is not found, a Radeon is "detected" by checking that the chip is still
not MACH32, and that pVideo->size == TRUE.
Assuming ATIChipID can't be trusted wholely (as it only knows chips listed in
atipciids.h), would it be okay to use it if the chip id is actually found as
listed? Then the first part of the patch could be applied with additional
chip-id-was-found-in-the-pci-id-list check so that the Mach64 would be skipped
at least for the known/listed newer Radeons. And maybe in the latter part
similar check could also be made so that the Radeon code is enabled for the
known cards at least.
This bug might be affecting all "PCI-E Xxxx series cards", or does someone how a
working X300/X600/X700/X800 PCI-E card?
*** Bug 7959 has been marked as a duplicate of this bug. ***
*** Bug 8778 has been marked as a duplicate of this bug. ***
(removing the "only 640x480" from the summary because it's a different issue
that has its own bug)
Considering Ubuntu has 16 duplicates for this problem
I'd propose changing the severity to major, though I'm not sure how severity
levels are defined here. For out-of-the-box experience or for anyone new to free
OSs / X.org, this is a big problem.
Created attachment 8275 [details] [review]
Added something "proper" to the second problematic place in the code, plus
comments. Applies to latest git. What do you think, any sense in that or does
it expose to some problems?
The root problem still probably is why none of us, who have problematic (PCI-E,
apparently) X600/X700/X800 cards, have pVideo->size set. Though I don't even
know if it has to be set, as everything works properly anyway using this patch
or the driver "radeon" in xorg.conf.
Okay I've committed this please close the bug if it fixes the problem..
Thanks a lot for applying the patch. It works for me now with the latest GIT and
Driver "ati", and hopefully it works for all the others as well.
(now if only I'd be able to fix bug 5991 and/or bug 5623 to give >640x480
resolution without specifying MonitorLayout... :)