From: Richard Purdie <rpurdie@rpsys.net>
To: Andrew Zabolotny <zap@homelink.ru>
Cc: adaplas@gmail.com, linux-fbdev-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: RFC: Backlight Class sysfs attribute behaviour
Date: Mon, 06 Mar 2006 23:05:07 +0000 [thread overview]
Message-ID: <1141686307.6524.98.camel@localhost.localdomain> (raw)
In-Reply-To: <20060307000718.0e8b8be3.zap@homelink.ru>
On Tue, 2006-03-07 at 00:07 +0300, Andrew Zabolotny wrote:
> On Mon, 06 Mar 2006 08:45:28 +0000
> Richard Purdie <rpurdie@rpsys.net> wrote:
>
> > * the user supplied power sysfs attribute
> > * the user supplied brightness sysfs attribute
> > * the current FB blanking state
> > * any other driver specific factors
> As far I see the only real concern here is the console blanking. So why
> not make it just another device state flag, which doesn't influence the
> 'power' attribute and which isn't visible from user space (what for?).
> And the 'real' power state will be computed as "blank && power"
> attributes. The entire logic could be hidden in backlight.c so that no
> driver will have to be modified for this. Maybe a 'hw_power' or such
> would be needed to see the 'real' hardware state (and possibly
> modify, if you really really want to).
>
> Is there any need for a broader-range solution here?
You've ignored the "driver specific factors" and one of the drivers
already has such a thing (borgi_bl's low battery backlight limiting).
My driver_brightness is really a more generic version of your "hw_power"
which allows other factors to be taken into consideration as well. We
may as well have the broader-range solution as it costs us nothing.
(I don't expect each factor to be visible to userspace, just the end
result).
Richard
next prev parent reply other threads:[~2006-03-06 23:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-05 15:08 RFC: Backlight Class sysfs attribute behaviour Richard Purdie
2006-03-05 22:09 ` Andrew Zabolotny
2006-03-06 0:08 ` Richard Purdie
2006-03-06 21:47 ` Pavel Machek
2006-03-06 1:00 ` Antonino A. Daplas
2006-03-06 8:45 ` Richard Purdie
2006-03-06 21:07 ` Andrew Zabolotny
2006-03-06 23:05 ` Richard Purdie [this message]
2006-03-08 9:48 ` Andrew Zabolotny
2006-03-06 21:44 ` Pavel Machek
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=1141686307.6524.98.camel@localhost.localdomain \
--to=rpurdie@rpsys.net \
--cc=adaplas@gmail.com \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=zap@homelink.ru \
/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).