Re: [PATCH 2/2] ACPI Check for backlight support via ACPI video.ko otherwise use vendor ACPI drivers

[Thomas Renninger <trenn@suse.de>]

On Thursday 10 July 2008 13:09:41 Matthew Garrett wrote:
> On Thu, Jul 10, 2008 at 01:00:34PM +0200, Thomas Renninger wrote:
> > On Thursday 10 July 2008 12:07:09 Matthew Garrett wrote:
> > > This is unnecessary logic. Let's just follow the spec. There's no need
> > > to use thinkpad_acpi here.
> >
> > That is what will be the next version.
> > But two days ago, there was no IGD working driver and ThinkPads did not
> > work with an IGD graphics device and video.ko without your dri
> > extensions. In fact this was the "regression" (in fact it never worked)
> > that blocked the "do not let the video driver poke on graphics devices
> > for which no graphics card is plugged in" (Patch 1/2).
>
> And now there is, so...
>
> > So there was a need for this.
> > In fact, my next version will still use thinkpad_acpi by default.
> > But this one will be based on a dmi blacklist. You mentioned ThinkPad
> > BIOSes which are missing a specific function and cannot work with IGD?
> > Please adjust the blacklist then to match those.
>
> No I didn't. Please don't do this - we have all the code needed to do it
> properly, so there's no need to use the thinkpad_acpi driver for
> backlight control on this hardware.
Ok.
But haven't you said there are ThinkPad BIOSes missing a specific ACPI part 
and therefore you had the delay?
If you could give me a dmidecode output, I like to add it.
It would be great to have an example in the blacklist, then things are much 
easier for others...

> > > No. The DRM can be (and usually is) built as a module and OSI strings
> > > are going to be checked at ACPI init time. This can't be made to work
> > > correctly. Vendors can choose whether to use the opregion or old-style
> > > support based on whether the driver has enabled the support.
> >
> > This has nothing to do with OS.
> > Just give vendors/BIOS developers the possibility to check whether the OS
> > is capable of Opregion video support.
>
> We can't. There's no way of telling whether the OS is capable of
> opregion video support until the drm module has been loaded, and any
> BIOS is going to have done its OSI checks at boot time.
>
> > This is not necessary as long as Linux returns true for Windows strings.
> > There we cannot differ for  individual OSI features anyway.
> > But if we do not do it correct now, we will close the door to be spec
> > compatible forever.
>
> The spec doesn't require an OSI string for this. Firmware that wants to
> know whether the OS is able to respond to opregion requests should do so
> by checking the specced opregion flags that the OS will set when it
> loads the driver.
Ok.