Re: RE: ACPI -- Workaround for broken DSDT

["Scott T. Smith" <scott-j3vAvQ9dNB9ByuSxxbvQtw@public.gmane.org>]

On Tue, 2004-02-03 at 23:22, Brown, Len wrote:
> > From Brown, Len on Sunday, 01 February, 2004:
> > >The vendor should supply a correct DSDT with their BIOS.
> > >In the case of Dell, you might inquire here: http://linux.dell.com/
> > >For non-vendor supplied solutions, you might also follow the 
> > DSDT link
> > >here: http://acpi.sourceforge.net/  
> > 
> > Hmm.  Do vendors generally release these?  I know Dell's very shaky on
> >   the Linux support front, at least for desktop/laptop.
> > Also, how do non-vendor supplied ones get made?  Seems like something
> >   you need NDA'ed docs for.
> 
> Non-vendor supplied DSDTs are created by end-users who bought machines
> that don't work.  Per the DSDT link above, one can extract,
> dis-assemble, modify a DSDT -- and tell Linux to use your copy instead
> of the version burned into PROM.

what's the long term strategy for ACPI on Linux?  If there are so many
broken DSDT's, and we want ACPI to be accessible to non-programmers,
then what's the ultimate solution?  Is it to include patches for every
possible platform, and have the ACPI subsystem autodetect and fix at
boot time?

Since thus far the ability to override the DSDT tables has not been
included in the vanilla ACPI distribution, then it seems you guys have
something else in mind.

What does Windows do?  Is it just that their DSDT
parser/executer/whatever operates differently (in which case a Windows
emulation mode could be added to the Linux subsystem), or is it that
Laptop manufacturers ship a corrected DSDT as part of their driver set?

	Scott



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn