On Mon, 2008-02-18 at 16:17 -0300, Henrique de Moraes Holschuh wrote: > On Mon, 18 Feb 2008, Thomas Renninger wrote: > > The problem is that OSI is used by Windows to pass the exact Windows > > (not OS) version they are running, this function should be called WOSI. > > We of course want to run on the latest fix-ups here and should pass > > "Windows 2006" (or whatever latest string there exists). > > > > IMO we need the same for Linux. > > We even have the advantage, that the string in LOSI(String) makes some > > sense, e.g. 2.6.24, so why not use LOSI(int, int, int) > > How the exact interface might look like I am not sure, just an idea. > > Looks quite a bad idea IMO. 2.6.24 means what? SuSE's? Mainline's? > Debian's? At what patch level? With which user patches tacked on top? And > at what level of userspace support (X.org can make a LOT of difference > here)? So you think on next Lenovo pre-load we should compile a "SLED10 SP2" into our kernel and let Lenovo BIOS fixups use it? E.g. we could use the default BCM/BQC/BCL brightness interface easily then, just a small if(SLED10_SP2) in the BIOS. A one-liner, it can only effect the very specific Lenovo models that are effected. This is much more appropriate then adding a backport, better say "most dirty hack of the month" (That's not your fault Henrique and by no means meant as an offence..., we both know about the ugliness of these BIOS workarounds) of ibm_acpi to 2.6.16! guessing brightness levels which has high risk to break other ThinkPads and even if not, you move all the QA (not much to do if embedded into such Linux/SUSE/kern_ver condition), and dirty hacks to the vendor...). Please let us not end up with hacks like "SLED10 SP2", "FEISTY" or whatever weirdness and this will come if we ignore osi=linux or do not provide something else. We should make up something more robust and more Linux kernel appropriate and propagate it to the vendors. Thomas - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
