All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: Len Brown <lenb@kernel.org>
Cc: linux-acpi@vger.kernel.org, Adrian Bunk <bunk@stusta.de>
Subject: Re: [PATCH 6/6] Revert "ACPI: video: Ignore ACPI video devices that aren't present in hardware"
Date: Wed, 19 Mar 2008 10:10:14 +0100	[thread overview]
Message-ID: <1205917814.4040.41.camel@linux-2bdv.site> (raw)
In-Reply-To: <200803181701.30447.lenb@kernel.org>


On Tue, 2008-03-18 at 17:01 -0400, Len Brown wrote:
> On Tuesday 18 March 2008, Thomas Renninger wrote:
> > On Tue, 2008-03-18 at 02:02 -0400, Len Brown wrote:
> > > From: Len Brown <len.brown@intel.com>
> > > 
> > > This reverts commit 3fa2cdcc45a0176de15cac9dbf4ed2834ebf8932.
> > > 
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9995
> > 
> > This is so wrong...
> > You register a driver on a device which does not exist.
> > You do this because on T61 ThinkPads, the external graphics device
> > method (soft-int 10) for brightness switching also works for the
> > internal Intel graphics card by pure luck...
> >
> > You introduce this obviously wrong approach and break other machines
> > intentionally (this is not a regression, because brightness switching
> > was done through thinkpad_acpi before).
> 
> acpi video brightness worked on the T61 before this patch, eg. in 2.6.24.
> acpi video brightness stopped working when this patch was applied.
> acpi video brightness works again when this patch (and its clone) were reverted.
It worked in a very broken way, by using the Nvidia ACPI graphics
device, even you have an Intel graphics card plugged in.
> 
> > This is known for months and reverting this in last minute is the wrong
> > action.
> > This should be:
> >   - fixed up in BIOS through a OSI("IGD") string
> 
> IGD isn't part of this discussion, since that support didn't ship
> in 2.6.24, and isn't shipping in 2.6.25.
IGD is the reason why this does not work as expected.

> Enabling IGD, or any other feature, via OSI on a platform that has
> already shipped is effectively impossible.  It would require every
> BIOS and every OS to be updated.
The only correct fix (as long as Linux does not support IGD) is a BIOS
fix like this:

Nvidia device
    _BCM implementation: use_int10
Intel device
    if (OSI="IGD")
        _BCM implementation: use_IGD
    else
        _BCM implementation: use_int10

and everything could work fine with the video.c implementation.
I just realize that this does not work because we return true for
OSI=Windows and these do not know about OSI="IGD".
This must be changed in future (I am still waiting for examples where it
really makes sense and does some good to return OSI=Windows). We now are
lucky because on ThinkPads the thinkpad_acpi driver can ugly, but easily
work around this.
There may pop up other things (e.g. IGD on other machines and whatever
other stuff) which will end in a Linux support impasse then.

Now this could get inverted and it would work (it is a bit embarrassing
to suggest this to a vendor: Can you please invert the logic because we
return true for Windows also)...:
Nvidia device
    _BCM implementation: use_int10
Intel device
    if (OSI="NOIGD")
        _BCM implementation: use_int10
    else
        _BCM implementation: use_IGD

That vendors are publishing OSI="Linux feature support" in their BIOS is
a bit optimistic and we might end up trying to dig in the dark fiddling
together things in vendor_acpi drivers as we always did.
But currently there is a move towards Linux also on laptops/workstations
and those vendors who care to publish a BIOS which fully works on Linux
and always should need the ability to do this.

> >   - get workarounded (as it always has been done) in thinkpad-acpi
> >     meanwhile.
> >
> > Please try to not load the ACPI video driver.
> > Instead load the thinkpad_acpi driver with:
> > brightness_enable=1
> > parameter. Does this work?
> > If that works, this is the right workaround for T61 with
> > internal/on-board
> > Intel graphics card.
> 
> Yes, the thinkpad_acpi driver with brightness_enable=1 works.
> 
> The thinkpad_acpi driver is really useful.
> It provides ways to get to thinkpad features for which
> no standard interface in Linux currently exists.
> 
> However, the thinkpad_acpi driver should not be used
> to provide features for which a generic method exists.
> 
> I understand that a distro may latch onto thinkpad_acpi
> to get features in the hands of customers as soon as possible.
> I understand that the transition off of custom solutions
> is never easy.  brightness_enable=1 was added to ease that
> transition.  If you have additional suggestions, please speak up.
> 
> > You can get a dmi blacklisting so that video driver is not loaded on the
> > ThinkPads or this can be done in user-space, but pls do not revert this
> > obvious fix.
> 
> This patch was far from obvious, including to Matthew, who created it.
PCI devices do not have a _STA function.
Therefore one has to look up PCI slot:dev.func and check whether the
device is present and really plugged into the board.

   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

      reply	other threads:[~2008-03-19 20:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-18  6:02 ACPI patches for 2.6.25-rc6 Len Brown
2008-03-18  6:02 ` [PATCH 1/6] ACPI: lockdep warning on boot, 2.6.25-rc5 Len Brown
2008-03-18  6:02   ` [PATCH 2/6] ACPI: battery: Don't return -EFAIL on broken packages Len Brown
2008-03-18  6:02   ` [PATCH 3/6] Revert "thermal: fix generic thermal I/F for hwmon" Len Brown
2008-03-18  6:02   ` [PATCH 4/6] thermal: re-document thermal units Len Brown
2008-03-18  6:02   ` [PATCH 5/6] thermal: delete "default y" Len Brown
2008-03-18  6:02   ` [PATCH 6/6] Revert "ACPI: video: Ignore ACPI video devices that aren't present in hardware" Len Brown
     [not found]     ` <1205852061.21619.192.camel@queen.suse.de>
2008-03-18 21:01       ` Len Brown
2008-03-19  9:10         ` Thomas Renninger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1205917814.4040.41.camel@linux-2bdv.site \
    --to=trenn@suse.de \
    --cc=bunk@stusta.de \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.