From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Tippett Subject: Custom Override for DSDT? Date: Fri, 13 Dec 2002 17:47:11 -0500 Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Message-ID: <3DFA636F.80407@casero.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Errors-To: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: "Grover, Andrew" Cc: 'Craig Whitmore' , Matthew Tippett , chbm-tNiY1ywYjSU@public.gmane.org, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-acpi@vger.kernel.org Getting back to the original question, would it make sense to support a way of overriding a dsdt to allow a broken BIOS that the manufacturer won't fix be usable? This still keeps standards based ACPI compliance but with the nice twist that we don't have to rely entirely on the manufacturer for the BIOS to work. Regards, Matthew Grover, Andrew wrote: >>From: Craig Whitmore [mailto:lennon-q3Ck4f9/EBK9koe0gwxAeg@public.gmane.org] >> >>>>distributed in windows drivers. >>> >>>Continuing with this thread, would it make sense to be ACPI >> >>compliant >> >>>but allow 'custom' dsdts to be passed to the acpi subsystem to allow >>>users to work around less than perfect implementations from >>>manufacturers. >>> >> >>Just 1 question. What do the manufacturer's say when you tell >>them they have >>a "broken" dsdt? Do they normally fix it? or give some excuse >>in a reason >>why they won't fix it? > > > It varies. BIOS bugs exposed by Linux may be prioritized lower due to > Linux's market position in laptops. They also may not get attention if they > are on end-of-lifed machines, or rolled into a BIOS update only when enough > other bugs are fixed to justify a new BIOS's validation and release. (We may > *say* to them it is a trivial fix, but the only way to know if it breaks > Windows is for them to test it!) > > There also isn't always a clear way to report BIOS bugs from end users. > > On the upside, the things we're seeing are almost always obviously wrong and > easy to fix - it's just getting them to make the trivial change. > > Regards -- Andy > > > ------------------------------------------------------- > This sf.net email is sponsored by: > With Great Power, Comes Great Responsibility > Learn to use your power at OSDN's High Performance Computing Channel > http://hpc.devchannel.org/ > _______________________________________________ > Acpi-devel mailing list > Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/acpi-devel > ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/