This patch adds brightness feature to lcd class.
(kernel/driver/video/backlight/lcd.c)
In the past, most of the lcd panels for embedded system was TFT-LCD
Panel needing backlight device.
But now AMOLED LCD Panel appeared so we should consider brightness
control for AMOLED Panel.
For the time being, I used backlight fake driver for brightness
control of AMOLED LCD Panel.
But this way is not good, so I propose to add brightness feature to lcd class.
For this, I attached patch file and if my proposal is approved
Then I will send s6e63m0 and tl2796 AMOLED lcd panel driver based on
lcd class modified soon.
signed-off-by : InKi Dae <[email protected]>
Best Regards,
InKi Dae.
On Mon 2009-11-02 17:50:02, InKi Dae wrote:
> This patch adds brightness feature to lcd class.
> (kernel/driver/video/backlight/lcd.c)
>
> In the past, most of the lcd panels for embedded system was TFT-LCD
> Panel needing backlight device.
> But now AMOLED LCD Panel appeared so we should consider brightness
> control for AMOLED Panel.
>
> For the time being, I used backlight fake driver for brightness
> control of AMOLED LCD Panel.
> But this way is not good, so I propose to add brightness feature to lcd class.
>
Why is it 'not good'? Using backlight driver seems like way to go to
me.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Thank you for your comments.
using backlight is good way in case of TFT-LCD Panel.
because TFT-LCD Panel needs backlight device to light up.
but AMOLED LCD Panel doesn't need backlight device because lighting up itself.
if you try to control brightness of AMOLED LCD Panel and using backlight class
then you should write fake backlight driver that it has no real device
for controlling
and would control brightness through that driver.
with this reason, I think that it's better to control brightness
through lcd class in case of AMOLED LCD panel.
If lcd class has birghtness feature then AMOLED LCD Panel driver would
become more simple and effective.
I think it is more generic way that only real device should have
device driver so I proposed this.
Thank you.
Best Regards,
InKi Dae.
2009/11/6 Pavel Machek <[email protected]>:
> On Mon 2009-11-02 17:50:02, InKi Dae wrote:
>> This patch adds brightness feature to lcd class.
>> (kernel/driver/video/backlight/lcd.c)
>>
>> In the past, most of the lcd panels for embedded system was TFT-LCD
>> Panel needing backlight device.
>> But now AMOLED LCD Panel appeared so we should consider brightness
>> control for AMOLED Panel.
>>
>> For the time being, I used backlight fake driver for brightness
>> control of AMOLED LCD Panel.
>> But this way is not good, so I propose to add brightness feature to lcd class.
>>
>
> Why is it 'not good'? Using backlight driver seems like way to go to
> me.
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
On Sat 2009-11-07 21:43:50, InKi Dae wrote:
> Thank you for your comments.
>
> using backlight is good way in case of TFT-LCD Panel.
> because TFT-LCD Panel needs backlight device to light up.
>
> but AMOLED LCD Panel doesn't need backlight device because lighting up itself.
I know. So what?
User wants to set brightness. Why should userspace know/care if it is
TFT or AMOLED?
I have this script:
#!/bin/bash
echo $1 > /sys/class/backlight/*/brightness
why should I have to rewrite it just because you decided amoled is
special?
Kernel is expected to provide hw abstraction...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
are you saying me that user shouldn't know if it is TFT-LCD or AMOLD?
I agree your saying.
if lcd class has brightness feature then sysfs file for controlling
brightness will be placed
in /sys/class/lcd/*/brightness.
it would be a problem because the path is no sysfs you expected.
how about that symbolic link file is created by lcd class for user?
like this,
/sys/class/lcd/*/brightness -> /sys/class/backlight/*/brightness
for this, some codes of creating symbolic link file should be added to
lcd class.
I still think it is not good way that lcd panel driver not having
backlight device has backlight driver
to control brightness and it should be solved in the course of time.
thank you.
2009/11/8 Pavel Machek <[email protected]>:
> On Sat 2009-11-07 21:43:50, InKi Dae wrote:
>> Thank you for your comments.
>>
>> using backlight is good way in case of TFT-LCD Panel.
>> because TFT-LCD Panel needs backlight device to light up.
>>
>> but AMOLED LCD Panel doesn't need backlight device because lighting up itself.
>
> I know. So what?
>
> User wants to set brightness. Why should userspace know/care if it is
> TFT or AMOLED?
>
> I have this script:
>
> #!/bin/bash
> echo $1 > /sys/class/backlight/*/brightness
>
> why should I have to rewrite it just because you decided amoled is
> special?
>
> Kernel is expected to provide hw abstraction...
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Pavel
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
On Tue 2009-11-10 00:37:59, InKi Dae wrote:
> are you saying me that user shouldn't know if it is TFT-LCD or AMOLD?
> I agree your saying.
Parse error.
> if lcd class has brightness feature then sysfs file for controlling
> brightness will be placed
> in /sys/class/lcd/*/brightness.
> it would be a problem because the path is no sysfs you expected.
>
> how about that symbolic link file is created by lcd class for user?
> like this,
> /sys/class/lcd/*/brightness -> /sys/class/backlight/*/brightness
>
The symlink would have to be backwards, but yes, that would be better
than nothing. (But I still don't see why we should make it
complex. Just pretend it is backlight.)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 2 Nov 2009 17:50:02 +0900
InKi Dae <[email protected]> wrote:
> This patch adds brightness feature to lcd class.
> (kernel/driver/video/backlight/lcd.c)
>
> In the past, most of the lcd panels for embedded system was TFT-LCD
> Panel needing backlight device.
> But now AMOLED LCD Panel appeared so we should consider brightness
> control for AMOLED Panel.
>
> For the time being, I used backlight fake driver for brightness
> control of AMOLED LCD Panel.
> But this way is not good, so I propose to add brightness feature to lcd class.
>
> For this, I attached patch file and if my proposal is approved
> Then I will send s6e63m0 and tl2796 AMOLED lcd panel driver based on
> lcd class modified soon.
Please send the s6e63m0 and tl2796 patches anyway. That way we have
some examples of how this new capability is used by drivers.
On Mon, 2009-11-02 at 17:50 +0900, InKi Dae wrote:
> This patch adds brightness feature to lcd class.
> (kernel/driver/video/backlight/lcd.c)
>
> In the past, most of the lcd panels for embedded system was TFT-LCD
> Panel needing backlight device.
> But now AMOLED LCD Panel appeared so we should consider brightness
> control for AMOLED Panel.
>
> For the time being, I used backlight fake driver for brightness
> control of AMOLED LCD Panel.
> But this way is not good, so I propose to add brightness feature to lcd class.
>
> For this, I attached patch file and if my proposal is approved
> Then I will send s6e63m0 and tl2796 AMOLED lcd panel driver based on
> lcd class modified soon.
Pavel has a good point but let me try and explain it differently.
The point of the backlight class is to expose a backlight brightness
control to userspace in a consistent well defined way. Anyone wishing to
write a piece of software to control the brightness of a backlight then
only needs to support *one* interface.
It is entirely accepted and normal that multiple "class" devices may
appear in userspace for one piece of physical hardware.
Your patch duplicates a userspace API and means any backlight
application would have to look for *two* different interfaces. This is
unacceptable.
Why can't your driver just register a backlight interface and an LCD
interface? I'd imagine your backlight and LCD can be powered on/off
separately too.
Please also cc: the backlight/lcd maintainer (me) on backlight/lcd
patches in future.
Andrew: Can you drop that patch from -mm please as I'm not convinced we
need two backlight brightness interfaces around...
Cheers,
Richard
Thank you for your comments.
it is a good idea that lcd driver registers interfaces to lcd class
and backlight class.
but I think for AMOLED LCD Panel, backlight couldn't be real device so
power on/off
for backlight device doesn't make sense.
I had tried lcd driver registers interfaces to lcd class and backlight
class as you said.
and also backlight fake driver as Pavel said.
but I thought to use my patch is more simple and effective.
of course, this patch has a problem that it has different path from
backlight class
for controlling brightness.
how about creating symbolic link file for competiability?
Best Regards,
InKi Dae.
2009/11/10 Richard Purdie <[email protected]>:
> On Mon, 2009-11-02 at 17:50 +0900, InKi Dae wrote:
>> This patch adds brightness feature to lcd class.
>> (kernel/driver/video/backlight/lcd.c)
>>
>> In the past, most of the lcd panels for embedded system was TFT-LCD
>> Panel needing backlight device.
>> But now AMOLED LCD Panel appeared so we should consider brightness
>> control for AMOLED Panel.
>>
>> For the time being, I used backlight fake driver for brightness
>> control of AMOLED LCD Panel.
>> But this way is not good, so I propose to add brightness feature to lcd class.
>>
>> For this, I attached patch file and if my proposal is approved
>> Then I will send s6e63m0 and tl2796 AMOLED lcd panel driver based on
>> lcd class modified soon.
>
> Pavel has a good point but let me try and explain it differently.
>
> The point of the backlight class is to expose a backlight brightness
> control to userspace in a consistent well defined way. Anyone wishing to
> write a piece of software to control the brightness of a backlight then
> only needs to support *one* interface.
>
> It is entirely accepted and normal that multiple "class" devices may
> appear in userspace for one piece of physical hardware.
>
> Your patch duplicates a userspace API and means any backlight
> application would have to look for *two* different interfaces. This is
> unacceptable.
>
> Why can't your driver just register a backlight interface and an LCD
> interface? I'd imagine your backlight and LCD can be powered on/off
> separately too.
>
> Please also cc: the backlight/lcd maintainer (me) on backlight/lcd
> patches in future.
>
> Andrew: Can you drop that patch from -mm please as I'm not convinced we
> need two backlight brightness interfaces around...
>
> Cheers,
>
> Richard
>
>
>
>
On Tue, 2009-11-10 at 12:26 +0900, InKi Dae wrote:
> Thank you for your comments.
>
> it is a good idea that lcd driver registers interfaces to lcd class
> and backlight class.
> but I think for AMOLED LCD Panel, backlight couldn't be real device so
> power on/off
> for backlight device doesn't make sense.
The backlight power control can just turn the backlight level down to
its lowest setting (off)?
> I had tried lcd driver registers interfaces to lcd class and backlight
> class as you said.
> and also backlight fake driver as Pavel said.
So you've tried this, what was the problem? Perhaps post this driver
code to illustrate your problem?
> but I thought to use my patch is more simple and effective.
> of course, this patch has a problem that it has different path from
> backlight class
> for controlling brightness.
>
> how about creating symbolic link file for competiability?
Creating two ways to do something (with or without symlinks) is not
simple and effective for anything other than your driver.
Cheers,
Richard
Is the confusion here just that LED displays aren't backlit in the
traditional sense of the term?
--
Matthew Garrett | [email protected]
it's my comment below.
thank you.
2009/11/10 Richard Purdie <[email protected]>:
> On Tue, 2009-11-10 at 12:26 +0900, InKi Dae wrote:
>> Thank you for your comments.
>>
>> it is a good idea that lcd driver registers interfaces to lcd class
>> and backlight class.
>> but I think for AMOLED LCD Panel, backlight couldn't be real device so
>> power on/off
>> for backlight device doesn't make sense.
>
> The backlight power control can just turn the backlight level down to
> its lowest setting (off)?
>> I had tried lcd driver registers interfaces to lcd class and backlight
>> class as you said.
>> and also backlight fake driver as Pavel said.
>
> So you've tried this, what was the problem? Perhaps post this driver
> code to illustrate your problem?
all the cases worked fine.
it's not whether lcd driver has a problem or not.
I mean it's design issue of lcd class. AMOLED LCD Panel DOESN'T NEED
backlight device.
and I should have added brightness control feature to AMOLED LCD Panel
driver not using backlight class
because they have no BACKLIGHT DEVICE.
in point of view AMOLED LCD Panel, brightness control is perfomed by
gamma setting, not backlight power controlling.
On Wed, 2009-11-11 at 15:17 +0900, InKi Dae wrote:
> 2009/11/10 Richard Purdie <[email protected]>:
> > So you've tried this, what was the problem? Perhaps post this driver
> > code to illustrate your problem?
>
> all the cases worked fine.
> it's not whether lcd driver has a problem or not.
> I mean it's design issue of lcd class. AMOLED LCD Panel DOESN'T NEED
> backlight device.
> and I should have added brightness control feature to AMOLED LCD Panel
> driver not using backlight class
> because they have no BACKLIGHT DEVICE.
>
> in point of view AMOLED LCD Panel, brightness control is perfomed by
> gamma setting, not backlight power controlling.
The question is whether this gamma control does the same thing as what
we've traditionally used the backlight brightness control for. As I
understand it, the answer is yes and to userspace making it appear as a
backlight brightness control makes sense.
The userspace view of the world is key and the fact there is not a
traditional physical backlight in the hardware isn't really an issue.
Why would we want to create two userspace interfaces doing the same
thing which would mean we just have to complicate userspace drivers?
Symlinking just makes things confusing.
Cheers,
Richard
Ok, I understood your answer.
Just it was my idea for AMOLED LCD Panel.
Both of them (AMOLED, TFT-LCD) do same thing in terms of brightness
control as you said.
Thank you, Richard.
Best Regards,
InKi Dae.
2009/11/11 Richard Purdie <[email protected]>:
> On Wed, 2009-11-11 at 15:17 +0900, InKi Dae wrote:
>> 2009/11/10 Richard Purdie <[email protected]>:
>> > So you've tried this, what was the problem? Perhaps post this driver
>> > code to illustrate your problem?
>>
>> all the cases worked fine.
>> it's not whether lcd driver has a problem or not.
>> I mean it's design issue of lcd class. AMOLED LCD Panel DOESN'T NEED
>> backlight device.
>> and I should have added brightness control feature to AMOLED LCD Panel
>> driver not using backlight class
>> because they have no BACKLIGHT DEVICE.
>>
>> in point of view AMOLED LCD Panel, brightness control is perfomed by
>> gamma setting, not backlight power controlling.
>
> The question is whether this gamma control does the same thing as what
> we've traditionally used the backlight brightness control for. As I
> understand it, the answer is yes and to userspace making it appear as a
> backlight brightness control makes sense.
>
> The userspace view of the world is key and the fact there is not a
> traditional physical backlight in the hardware isn't really an issue.
>
> Why would we want to create two userspace interfaces doing the same
> thing which would mean we just have to complicate userspace drivers?
> Symlinking just makes things confusing.
>
> Cheers,
>
> Richard
>
>
>