Using a custom DSDT with Fedora

David Zeuthen david at fubar.dk
Mon Oct 9 15:10:56 UTC 2006


On Mon, 2006-10-09 at 09:17 +0200, Arjan van de Ven wrote:
> > > Please read my blog entry. The ACPI interpreter isn't broken, the BIOS
> > > just doesn't read from the hardware like it should.
> > 
> > Then the BIOS is broken, complain to the BIOS vendor?
> 
> this is a good place to plug the bios<->linux test tool that Intel
> recently released:
> 
> http://www.linuxfirmwarekit.org
> 
> The aim is to make it real easy for bios folks to test with linux, but
> normal users can use it too, say for evaluating what to buy etc.

That is an awesome effort Arjan!

Reading the whole thread I think we need to fix a few things in Fedora
though. Here's an example where Richard actually fixed a bug. Can anyone
explain why Richard needs to jump through hoops to actually apply his
bug fix? Clearly something is broken with Fedora here.

At the very least we ought to provide the option to mkinitrd so it can
include the new DSDT and load it into the kernel at startup. IIRC the
main resistance is that upstream kernel and other developers don't like
to deal with bug reports when a custom DSDT is used. So perhaps one way
of dealing with this is to taint the kernel if that isn't happening
already.

I also think we need to think about the experience we want people to
have when they use Fedora. We already have thousands of work arounds and
quirks for broken hardware in Fedora, why doesn't this apply to the
DSDT? Just because it's firmware? What are the risks here? What are the
main issues Fedora developers have here?

In other words: Why can't we ship updated DSDT tables if the vendor
(Lenovo in this case) have ACK'ed the DSDT with the bug fix and said
it's the right update? (maybe there are redistribution issues here)

Further, if a vendor has an updated BIOS and it's suitable for
redistribution in Fedora, why can't we include that BIOS image and ask
the user if he wants to flash his BIOS?

Of course, all this requires vendors like Lenovo, Dell, IBM and so on to
actually participate in the process and tell us what they need. One
solution to this problem is for each vendor to contribute code that
hooks into, for example, HAL and provides the implementation for an
UpdateFirmware() method. I bet we could talk Richard into doing the UI
in either gnome-power-manager or elsewhere.

Perhaps this is interesting for vendors if we do it this way since HAL
is an upstream project shipped by all distros and we can do the update
UI in a distro-independent way. Hence, their contributions will be
applicable mostly everywhere. From the vendor point of view, I can't
speak for them, but I bet it would be much nicer than what they do on
Windows where they supply some binary program to the user with a weirdo
UI.

We can do a lot better here and I believe with the right infrastructure
we can make it appealing for vendors to actually participate in this
process. I know that at least Dell's Matt Domsch is very active in
Fedora so I'm curious what he thinks about it from a vendor perspective.

Something to think about. We can do so much better than what we do
today.

     David





More information about the fedora-devel-list mailing list