Bug#280738: Acknowledgement (xserver-xfree86: When installing with a radeon 9200 SE (1002:5964) the ati wrapper doesn't recognize it, radeon is ok)
On Wed, Dec 15, 2004 at 03:08:13PM -0500, Branden Robinson wrote:
> On Fri, Dec 10, 2004 at 01:43:45PM +0100, Sven Luther wrote:
> > On Fri, Dec 10, 2004 at 04:42:22AM -0500, Branden Robinson wrote:
> > > Do you have any suggestions for how this could be rectified?
> >
> > Well, i am a bit lost here, but more to this below ...
> >
> > > Does the PCI ID matching code fail to disregard secondary (i.e., non-zero)
> > > functions in the PCI ID? *Should* it disregard secondary functions?
> >
> > Well, i don't understand why the primary pci-id is not chosen here, but only
> > the secondary one. I have some feeling that the wrapper iterates or something
> > and choses the secondary pci id since it is the last one. Maybe i should
> > rebuild the driver and do some creative debugging to see what happens. See, if
> > you had accepted the driver-sdk patch all those years ago, i wouldn't need 4GB
> > and hours of compiling to make this happen :) To add to this, i only have the
> > prototype cpu module right now, which sometimes segfaults on heavy compilatin
> > :/
> >
> > > Or is the fix simply to add the ID for the "(Secondary)" device to the ati
> > > driver, so it knows to load the radeon submodule?
> >
> > Well, both fixes should do :
> >
> > 1) make the ati wrapper use only the primary function for identifying the
> > card.
> >
> > 2) add the secondary pci-id to the ati wrapper.
> >
> > I don't know if the ati card work like the 3dlabs wildcat VP, where you can
> > configure the card into behaving as two fully independent heads (with two
> > framebuffers and two accel pipes and so on), then it makes sense to go for 2),
> > but i don't think this is the case, so i would guess 1) is the way to go, and
> > this is an upstream bug, maybe they even have a fix already for this, did you
> > check ?
>
> I'm not precisely sure where to look. Keep in mind that Debian doesn't
> have a proper upstream for XFree86 anymore. X.Org is a different, albeit
Well, in this case, the upstream would be the ati driver author, which means
the ati folk, which are upstream for X.org too.
> related codebase, and even if The XFree86 Project, Inc. didn't have
> something other than heaping mounds of scorn for Debian, I'm pretty sure
> they don't support 4.3.0 anymore.
Yep. But as said, the code in question is copyrighted by the ATI folk, and
they most assuredly care about that. If nothing else, you could ask Michel.
> > > I could use some advice as to what the best path forward is, even once I
> > > have more information from the submitter, so I am tagging this bug "help".
> >
> > Ok. I would :
> >
> > 1) contact radeon driver upstream to see if they have a newer version which
> > fixes this.
>
> It's not clear to me who owns the ATI driver at freedesktop.org. Just
> within the past two months it's been hacked on by Roland Mainz, Vladimir
> Dergachev, Alex Deucher, Egbert Eich, Daniel Stone, Michel Dänzer, "kuhn",
> and Matthieu Herrb.
Well, i would ask Michel to be sure, but i was under the impression that most
of that code came from ATI in more or less direct way. I may be wrong though.
> All that activity is great in contrast to XFree86; unfortunately, it leaves
> me puzzled as to who has ownership of that part of the tree. ;)
I think some of those are already X.org folk, and some are also DDs, so it
should not be so difficult to get the straigth out of it.
> > 2) make the ati wrapper use only the first function.
> >
> > Investigating 2) right now, but i don't promise anything.
>
> Any luck on this yet?
Not much, it is a huge function and i have been busy. I get some feeling that
it is in radeon_probe.c in the RADEONProbe function that things happen though.
Maybe we should look at it, and put some debug in it, and see if it gets
called two time. Maybe just adding the secondary pci id would be enough
though, not sure.
> > BTW, next time, please bcc control, so idon't need to remove it when replying :)
>
> I'd rather not -- it serves as a means of documenting the top of the mail
> message to people who would otherwise have trouble figuring out what that
> stuff is.
Well, the message is the same, you just don't get the control@... when you do
a group reply.
Friendly,
Sven Luther
Reply to: