From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Richard Purdie <rpurdie@rpsys.net>
Cc: Dmitry Torokhov <dtor_core@ameritech.net>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [RESEND] Add Dell laptop backlight brightness display
Date: Tue, 7 Feb 2006 13:55:02 +0000 [thread overview]
Message-ID: <20060207135502.GA2770@srcf.ucam.org> (raw)
In-Reply-To: <1139319426.6422.42.camel@localhost.localdomain>
On Tue, Feb 07, 2006 at 01:37:06PM +0000, Richard Purdie wrote:
> On Tue, 2006-02-07 at 13:23 +0000, Matthew Garrett wrote:
> > Would you be open to adding generic support for displaying separate AC
> > and DC brightnesses? Making it driver specific leaves the potential for
> > inconsistencies.
>
> The problem is that AC or DC is not a generic property of backlights but
> specific to your problematic hardware case. You're going to have a to
> find a way to tell if its running on AC or not to report the right value
> in the manner the class requires.
Cases rather than case, sadly. Determining whether the hardware is on AC
or not tends to be much more awkward than you'd think. On HPs, it seems
to be done by making a specific call to the embedded controller. This is
very model specific, whereas the brightness values aren't. It's also
likely to go horribly wrong if the hardware is trying to access the
embedded controller at the same time. Realistically, it's impossible
without making the driver depend on ACPI and exporting acpi_ac_get_state
from the ACPI layer, which would be a shame since the rest of the
functionality isn't ACPI dependent at all.
> I can't see how you plan to add "generic support for displaying separate
> AC and DC brightnesses" without destroying the point of the class (which
> for the brightness parameter is to display the current backlight
> brightness).
I think providing a consistent interface for what information we can
provide is worthwhile.
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2006-02-07 13:55 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-06 19:15 [PATCH] Make DMI code store chassis type Matthew Garrett
2006-02-06 19:18 ` [PATCH] Add HP laptop backlight brightness display Matthew Garrett
2006-02-06 19:19 ` [PATCH] Add Dell " Matthew Garrett
2006-02-07 0:37 ` [PATCH] [RESEND] " Matthew Garrett
2006-02-07 3:37 ` Dmitry Torokhov
2006-02-07 12:32 ` Matthew Garrett
2006-02-07 13:06 ` Richard Purdie
2006-02-07 13:23 ` Matthew Garrett
2006-02-07 13:37 ` Richard Purdie
2006-02-07 13:55 ` Matthew Garrett [this message]
2006-02-07 14:54 ` Richard Purdie
2006-02-08 9:06 ` Pavel Machek
2006-02-06 20:04 ` [PATCH] Add HP " Jan-Benedict Glaw
2006-02-07 3:43 [PATCH] [RESEND] Add Dell " Michael E Brown
2006-02-07 4:09 ` Matthew Garrett
2006-02-07 16:34 Michael_E_Brown
2006-02-07 17:20 ` Matthew Garrett
2006-02-12 17:26 ` Pavel Machek
2006-02-07 17:23 Michael_E_Brown
2006-02-20 16:45 Michael_E_Brown
2006-02-20 16:53 ` Pavel Machek
2006-02-23 5:17 ` Michael E Brown
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=20060207135502.GA2770@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=dtor_core@ameritech.net \
--cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).