linux-kernel - Re: [PATCH 1/2] staging: fbtft: add support for ST7789V display controller

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 11 Oct 2015 16:19:43 +0200
From:	Noralf Trønnes <noralf@...nnes.org>
To:	Dennis Menschel <menschel-d@...teo.de>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org
Subject: Re: [PATCH 1/2] staging: fbtft: add support for ST7789V display
 controller

Den 11.10.2015 09:31, skrev Dennis Menschel:
> Am 10.10.2015 um 17:36 schrieb Noralf Trønnes:
>> Den 07.10.2015 22:15, skrev Dennis Menschel:
>>> This patch adds support for the Sitronix ST7789V display controller.
>>> The controller is intended for small color displays with a resolution
>>> of up to 320x240 pixels.
>>>
>>> Signed-off-by: Dennis Menschel <menschel-d@...teo.de>
>>> ---

...

>> (blank() is used on OLED controllers and set_gamma() will be obsolete with
>> display drivers since gamma can be set in init())

...

> Thank you for your detailed explanation about the current state of fbtft
> and the future plans for a possible successor framework. As suggested by
> you, I'll make the following changes in the next patch:
>
> - Change the st7789v controller driver to a cberry28 display driver.
> - If applicable, use the default fbtft implementation of set_addr_win().
> - Remove the blank() function as it is only intended for OLED displays.

I want to expand a bit on blank(), it can be used by all drivers, but all
the non-OLED displays I have tried turns off the pixels when it's blanked,
so the backlight shines through, making it of no use (no power savings to
speak of either). So these displays need the backlight to be turned off
during blanking. The main reason blank() isn't implemented in the
controller drivers, is that if it's used on a display without backlight
control, the display would turn white during blanking.

There's a bug in the fbtft backlight implementation that prevents it from
turning off backlight on the first fb_blank. Subsequent blanks are ok.
I haven't looked into it, because the fbtft backlight implementation
should really be handled by the gpio-backlight driver. That's what I've
done in my new work.

Noralf.

--
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/