public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Thomas Renninger <trenn@suse.de>,
	ak@linux.intel.com, linux-acpi@vger.kernel.org,
	linux-next@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Julia Jomantaite <julia.jomantaite@gmail.com>,
	marcus@better.se, dannybaumann@web.de, corsac@debian.org,
	jesse.barnes@intel.com
Subject: Re: [PATCH 1/2] ACPI Video: Ignore devices that aren't present in hardware
Date: Sat, 5 Jul 2008 12:46:15 -0300	[thread overview]
Message-ID: <20080705154615.GA10772@khazad-dum.debian.net> (raw)
In-Reply-To: <20080704173910.GA16595@srcf.ucam.org>

On Fri, 04 Jul 2008, Matthew Garrett wrote:
> Got it. The reason for the delay is that BRTO sits in a loop for no 
> obvious reason unless BRTF is cleared. The only thing that clears BRTF 
> is the PWMS function, which isn't called anywhere in the ACPI tables. 
> The NetBSD driver has the following code:

PWMS: missing from X300, X61t, X61... is this a new thing that Lenovo
recently added to the firmware?  I don't have very new dumps, particularly,
none taken without OSI(Linux) -- might do something to the SSDTs -- so I
might not have the full view of this.

Anyway, if it is that new AND we need it to work well, it means we need to
warn the user to upgrade the firmware when it is missing (and of course, add
your code to use it when it is not missing :p).

BRTO, BRTF: these are around for a while already.  But I can't find anything
that calls BRTO.  What is NetBSD doing with BRTO?

Can you send me your acpidump (and censored dmidecode) output so that I can
look at a new enough dump with PWMS support?

> and doing this in thinkpad_acpi means my brightness control works in an 
> acceptably speedy manner with opregion. Henrique, any thoughts on this? 

I'd like to have newer versions of the tables, before giving an opinion. Can
you send me the dump for your thinkpad?

> If you're happy with it, we can get opregion support into .27 and add 
> the patch to remove duplicate ACPI video devices and everything will 
> work in a beautiful and harmonious manner.

I didn't look much at the code for removing duplicate ACPI video yet, but I
am fine with the basic idea.

However, if we are going to be disabling the entire firmware brightness
change system (which will include ACPI BCM, probably... need the tables to
know), that's something the X server needs to be able to enable/disable.
Otherwise, we break all such changes outside of a X display, which is not
acceptable.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

      parent reply	other threads:[~2008-07-05 15:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-03 16:05 [PATCH 1/2] ACPI Video: Ignore devices that aren't present in hardware Thomas Renninger
2008-07-03 16:08 ` Matthew Garrett
2008-07-03 16:15   ` Thomas Renninger
2008-07-03 16:16     ` Matthew Garrett
2008-07-03 16:21       ` Yves-Alexis Perez
2008-07-03 19:24         ` Matthew Garrett
2008-07-04 10:08       ` Thomas Renninger
2008-07-04 10:18         ` Matthew Garrett
2008-07-04  3:09   ` Henrique de Moraes Holschuh
2008-07-04  9:13     ` Matthew Garrett
2008-07-04 11:55       ` Henrique de Moraes Holschuh
2008-07-04 17:39         ` Matthew Garrett
2008-07-04 19:49           ` Henrique de Moraes Holschuh
2008-07-05 15:46           ` Henrique de Moraes Holschuh [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=20080705154615.GA10772@khazad-dum.debian.net \
    --to=hmh@hmh.eng.br \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=corsac@debian.org \
    --cc=dannybaumann@web.de \
    --cc=jesse.barnes@intel.com \
    --cc=julia.jomantaite@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=marcus@better.se \
    --cc=mjg59@srcf.ucam.org \
    --cc=trenn@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox