linux-kernel - Re: [PATCH] fixed sparkling issue on lcd panel when fb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 22 Mar 2010 12:18:05 +0900
From:	InKi Dae <daeinki@...il.com>
To:	Richard Purdie <rpurdie@...ys.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Machek <pavel@....cz>,
	Kyungmin Park <kmpark@...radead.org>,
	linux-fbdev-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fixed sparkling issue on lcd panel when fb_blank mode is 
	changed.

yes, you are right.

when fb_blank mode is changed to FB_BLANK_NORMAL or
FB_BLANK_UNBLANK(power down -> power up)
it has a possibility that we would encounter same issue.

I'd try to modify my patch to be considered with your opinion and will
send it again.
Thank you for your answer.

Best Regards,
InKi Dae.

2010/3/19 Richard Purdie <rpurdie@...ys.net>:
> Hi,
>
> On Fri, 2010-03-19 at 13:36 +0900, InKi Dae wrote:
>> This issue is a problem that lcd panel is spakled when fb_blank mode is changed
>> From FB_BLANK_UNBLANK to FB_BLANK_POWER or FB_BLANK_POWER to FB_BLANK_UNBLANK.
>>
>> In case of FB_BLANK_UNBLANK, screen = on, vsync = on, hsync = on and
>> For FB_BLANK_POWERDOWN screen = blanked, vsync = off, hsync = off
>> So like this when fb_blank mode becomes FB_BLANK_POWERDOWN,
>> Display controller and lcd panel should become off to reduce power consumption.
>>
>> Let's see fb_blank function of fbmem.c file.
>>
>> fb_blank()
>> {
>>     if (info->fbops->fb_blank)
>>             ret = info->fbops->fb_blank(blank, info(
>>     if (!ret)
>>             fb_notifier_call_chain(FB_EVENT_BLANK, &event);
>> }
>>
>> This problem is because this code calls fb_blank (fb_blank of device
>> specific framebuffer driver)
>> Earlier then fb_notifier_call_chain.
>>
>> For example,
>> Device specific fb_blank function is registered to generic framebuffer
>> driver through register_framebuffer function
>> And fb_notifier_call_chain calls any callback function registered to
>> lcd class(lcd.c) through fb_notifier_callback function.
>> So if fb_blank mode is changed to FB_BLANK_POWERDOWN then display
>> controller would become off(clock disable)
>> On the other hand, lcd panel would still be on. at this time, some
>> situation on lcd panel occers like sparkling
>> Because video clock to be delivered to ldi module of lcd panel is disabled also.
>>
>> This patch get fb_notifier_call_chain to be called earlier then fb_blank.
>> Please, review this patch.
>
> So to summarise the problem more succinctly the LCD and the display
> controllers power off in the wrong order causing visual defects
> (sparkling) on the display.
>
> I was a bit worried about event order and loops with this change so I
> checked and there are three consumers of these events in the kernel:
> consoles, LCD and backlight. None of them have a problem with this
> change of order for power down so from that point of view I'm ok with
> the change.
>
> However this function also covers powerup from a screen blank to an
> active screen. When powering up it makes sense to power up the video
> device first, then the LCD, backlight and console as per the current
> code, otherwise I can imagine "sparkling" upon powerup.
>
> So it looks like we need to change order only on powerdown, not upon
> resume, otherwise we'll get further regression reports on poweron?
>
> Cheers,
>
> Richard
>
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/