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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
