Date: Tue, 7 Mar 2006 00:07:18 +0300
From: Andrew Zabolotny <zap@homelink.ru>
To: Richard Purdie <rpurdie@rpsys.net>
Cc: adaplas@gmail.com, linux-fbdev-devel@lists.sourceforge.net,
       linux-kernel@vger.kernel.org
Subject: Re: RFC: Backlight Class sysfs attribute behaviour
Message-Id: <20060307000718.0e8b8be3.zap@homelink.ru>
In-Reply-To: <1141634729.6524.14.camel@localhost.localdomain>
References: <1141571334.6521.38.camel@localhost.localdomain>
	<440B89AB.3020203@gmail.com>
	<1141634729.6524.14.camel@localhost.localdomain>
Organization: home
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1088
Lines: 26

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?

-- 
Greetings,
   Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/