Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61

[Thomas Renninger <trenn@suse.de>]

On Tue, 2008-02-19 at 11:24 -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 19 Feb 2008, Thomas Renninger wrote:
> > > 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"
> 
> Huh?!  No, I don't.  I would walk away in disgust if we did it.  OSI(SLED10
> SP2) would be even worse than OSI(Linux) plus a OS<whatever>(2.6.24), I
> think I can safely assume that we *all* agree on THAT one.
> 
> > 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
> 
> AFAIK, there is no problem with the *ACPI* brightness firmware on ThinkPads.
> At all.  Its only quirk is that you want to call _BCL at least once at
> driver load.
No it's not that it's:
 - you call BCLL, a totally undefined AML function, found out by DSDT
   examination..., Lenovo is allowed to and will change the name this
   function at some time, they even could for a BIOS update
 - It is that we have to use the ibm_acpi driver quirks for an interface
   that is specified and which nearly every Vista compatible machine is
   providing.
   You need special handling for Lenovos. You need to blacklist them to
   not use the well defined interface, but use the ibm_acpi quirks.

I really like to ask Lenovo to add a (on Intel graphics cards):
if (linux)
   call _BCM/BQC/BCL this way
else
   call _BCM/BQC/BCL the other way
All this should be only some simple AML lines...
and simply use the video driver for Lenovo backlight switching...

> Anyway, the whole backlight brightness stink is our (as in Linux kernel
> people, userspace people, distro people) doing.  The laptop vendors, for
> once, had nothing to do with it. Also, for once, the ACPI 3.0 specification
> (when correctly implemented in the AML *and* ACPI OSI) does give us all we
> need to have it work properly in any way we see fit.
> 
> Since the brightness issues have *nothing* to do with OSI(anything), let's
> leave it for another thread.
> 
> > 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.
> 
> We all agree on that, Thomas.
Puhhh... good. So I have missed the one or other suggestion or there are
no suggestions yet?

> I am actually arguing for something *even* more fine-grained than a kernel
> version, but at the same time completely independent of kernel versions, so
> that if we backport something, or our userspace improves, we can stop (or
> start) advertising it through OSI() without messing with anything else.

IMO kernel version is enough and the right thing, everything else is
over-designed (please provide an example, I cannot imagine anything
useful/generic but only osi=linux or better osi=linux + kernel version).

I start a new thread/discussion now. I was quite late with reading up
the list and this is important and should get some more attention also
by others who might not have read into this thread.

   Thomas

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html