On Mon, 2009-06-08 at 16:05 -0400, Bill McGonigle wrote:
> On 06/08/2009 03:18 PM, Adam Williamson wrote:
>
> > I haven't actually looked at what it does for ATI cards, but likely it
> > does much the same: the entire ATI manufacturer ID is mapped to
> > 'radeon'. If you knew of cards that simply didn't work with the driver,
> > they could be mapped to 'vesa' as exceptions.
>
> My original problem was that under Fedora 10, the 'radeon' driver worked
> on my hardware, but under Fedora 11, I need 'radeonhd' ('radeon' still
> exists under F11).
That would be a bug. Any hardware that works with radeonhd ought to work
with radeon (to which you ask, then why do we have both?, to which I
answer, for personal / political / historical reasons :>), so please
file a bug on the radeon driver explaining what goes wrong, if you
didn't already. For Fedora, radeon is the 'official' driver (the
political side of things is that radeon has RH folks involved in its
development, and radeonhd has Novell folks involved in its
development...), our intent is that radeon be used for all ATI adapters.
radeonhd is only really around for testing purposes.
> > anaconda doesn't have to do anything. Anaconda uses a perfectly standard
> > X, so it gets the same autodetected driver as an installed system would.
>
> Yet through preupgrade this doesn't seem to work. I don't know when or
> if preupgrade does autodetection - maybe it happens under preupgrade on
> the old X drivers, which isn't necessarily accurate under the new X drivers?
I don't really know, but I don't see why it would use the 'old' data. X
autodetection happens every time you start X (unless there's an
xorg.conf file), and uses the code from the running X server, obviously.
> > the device->module mappings are now carried in the modules
> > themselves; the modules specify which devices they support, and the
> > module gets loaded on that hardware automatically just using that
> > system. No distro-level infrastructure is needed.
>
> But don't we need to know some of these things about the new target to
> build the proper initrd, and modprobe.cond.d for upgrades when the
> driver is changing for given hardware (especially for the root device)?
Yeah, there's some ickiness around initrd creation and storage-related
drivers, you're right. I don't actually know how this is handled on
Fedora. I'd have to refer you to someone else, not sure who would be the
expert on that.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
