From: Mario Schwalbe <schwalbe@inf.tu-dresden.de>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Richard Purdie <rpurdie@rpsys.net>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] video: mbp_nvidia_bl: Add support for MacBook 5, MacBook Air 2, and MacBook Pro 5
Date: Sat, 13 Dec 2008 13:04:12 +0100 [thread overview]
Message-ID: <4943A4BC.4060107@inf.tu-dresden.de> (raw)
In-Reply-To: <20081212205609.GA28485@srcf.ucam.org>
Hi,
Matthew Garrett schrieb:
> On Fri, Dec 12, 2008 at 09:48:51PM +0100, Mario Schwalbe wrote:
>> Known Bugs:
>> * MacBook Pro 5:
>> Initial brightness after bootup is the last recently used
>> brightness (in Mac OSX), while the firmware reports maximum.
>> Impossible to fix.
>
> In that case, why not read the firmware value and then set that
> explicitly on driver load? Having the driver be in sync with the
> hardware is better than avoiding a brightness change on boot.
that's already the case. the previous code worked like that and the
patch doesn't change that behaviour. however, the problem is:
(1) the driver tries to read the current setting which is always maximum,
even through the actual brightness might be lower.
(2) afterwards the driver re-sends this value to hardware effectively
setting the (visible) brightness to maximum. now hardware and software
are consistent. that's a brightness change on boot we cannot avoid.
not re-sending the read value on boot is no solution either because if
the user later decides to adjust brightness incrementally (by means of
functions keys) it would immediately jump to some value near maximum
with his adjustment applied. then after the first change, the state
would be consistent.
>> +static int intel_chipset_get_intensity(struct backlight_device *bd)
>> {
>> outb(0x03, 0xb3);
>> outb(0xbf, 0xb2);
>> return inb(0xb3) >> 4;
>> }
>
> Just to absolutely clarify, this is intel chipset as in motherboard
> chipset and not graphics chipset, right? A comment to make that clear
> would be good - it left me a little confused at first. Other than that,
> it looks good.
yes, *_chipset refers to the motherboard chipset vendor.
ciao,
Mario
--
Wo das Chaos auf die Ordnung trifft, gewinnt meist das Chaos,
weil es besser organisiert ist.
- Friedrich Nietzsche -
--
_____ ________
/ \ / ____/ Mario Schwalbe
/ \ / \ \____ \
/ Y \/ \ eMail: schwalbe@inf.tu-dresden.de,
\____|__ /______ / ms790178@inf.tu-dresden.de
\/ \/
key ID: 7DA9 DAFF
public key: https://www1.inf.tu-dresden.de/~ms790178/key.asc
key fingerprint: 2979 AA20 4A93 B527 90CC 45E5 4B28 511A 7DA9 DAFF
next prev parent reply other threads:[~2008-12-13 12:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-12 20:48 [PATCH 1/2] video: mbp_nvidia_bl: Add support for MacBook 5, MacBook Air 2, and MacBook Pro 5 Mario Schwalbe
2008-12-12 20:56 ` Matthew Garrett
2008-12-13 12:04 ` Mario Schwalbe [this message]
2008-12-22 17:11 ` Johannes Berg
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=4943A4BC.4060107@inf.tu-dresden.de \
--to=schwalbe@inf.tu-dresden.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=rpurdie@rpsys.net \
/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