From: InKi D. <da...@gm...> - 2009-11-02 08:50:16
Attachments:
lcd.patch
|
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 <ink...@sa...> Best Regards, InKi Dae. |
From: Pavel M. <pa...@uc...> - 2009-11-05 19:27:45
|
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 |
From: InKi D. <da...@gm...> - 2009-11-07 12:44:03
|
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 <pa...@uc...>: > 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 > |
From: Pavel M. <pa...@uc...> - 2009-11-07 16:48:51
|
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 |
From: InKi D. <da...@gm...> - 2009-11-09 15:38:09
|
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 <pa...@uc...>: > 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 > |
From: Pavel M. <pa...@uc...> - 2009-11-09 20:16:12
|
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 |
From: Andrew M. <ak...@li...> - 2009-11-09 23:19:30
|
On Mon, 2 Nov 2009 17:50:02 +0900 InKi Dae <da...@gm...> 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. |
From: InKi D. <da...@gm...> - 2009-11-10 03:26:49
|
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 <rp...@li...>: > 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 > > > > |
From: Richard P. <rp...@li...> - 2009-11-09 23:38:42
|
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 |
From: Richard P. <rp...@li...> - 2009-11-10 08:46:53
|
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 |
From: Matthew G. <mj...@sr...> - 2009-11-10 15:28:29
|
Is the confusion here just that LED displays aren't backlit in the traditional sense of the term? -- Matthew Garrett | mj...@sr... |
From: InKi D. <da...@gm...> - 2009-11-11 06:17:49
|
it's my comment below. thank you. 2009/11/10 Richard Purdie <rp...@li...>: > 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. |
From: Richard P. <rp...@li...> - 2009-11-11 09:32:13
|
On Wed, 2009-11-11 at 15:17 +0900, InKi Dae wrote: > 2009/11/10 Richard Purdie <rp...@li...>: > > 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 |
From: InKi D. <da...@gm...> - 2009-11-13 03:14:04
|
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 <rp...@li...>: > On Wed, 2009-11-11 at 15:17 +0900, InKi Dae wrote: >> 2009/11/10 Richard Purdie <rp...@li...>: >> > 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 > > > |