Summary: | "ati" wrapper detection failures: PCI-E X800 (and X300, X600, X700...) card work only using Driver "radeon" | ||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Timo Jyrinki <timo.jyrinki> | ||||||||||||||||||||
Component: | Driver/Radeon | Assignee: | Xorg Project Team <xorg-team> | ||||||||||||||||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||||||||
Severity: | major | ||||||||||||||||||||||
Priority: | high | CC: | psmith, speedator | ||||||||||||||||||||
Version: | 7.0.0 | ||||||||||||||||||||||
Hardware: | x86 (IA32) | ||||||||||||||||||||||
OS: | Linux (All) | ||||||||||||||||||||||
Whiteboard: | |||||||||||||||||||||||
i915 platform: | i915 features: | ||||||||||||||||||||||
Attachments: |
|
Description
Timo Jyrinki
2006-04-30 20:43:54 UTC
Created attachment 5527 [details]
lspci
Created attachment 5528 [details]
lspci -n
Created attachment 5529 [details]
xvinfo
Created attachment 5530 [details]
Xorg.0.log-ati
Xorg.0.log using the default "ati" driver (ie. X doesn't start).
Created attachment 5531 [details]
Xorg.0.log radeon
Xorg.0.log using "radeon" (ie. X starts but only in 640x480 mode)
Created attachment 5532 [details]
xorg.conf
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 lists. 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] example patch 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[1] 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 !pVideo->size[1]? 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-usingpatch
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 also. (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[1] == 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[1] == 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 (https://launchpad.net/distros/ubuntu/+source/xserver-xorg-video-ati/+bug/28925), 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] radeon-detect.patch 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[1] 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.. |
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.