Am 11.10.2015 um 16:19 schrieb Noralf Trønnes: > > 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@xxxxxxxxx> >>>> --- > > ... > >>> (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. Hello Noralf, after having seen that my previous patches have already moved to staging-next, I've reconsidered your recent suggestions. If I rewrote the ST7789V display controller driver into a C-Berry28 display driver, the last patches would be effectively reverted, rendering previous testing efforts in vain (among other things). The driver would loose much of its current flexibility (i.e. being able to support similar displays with the same controller but different voltages or gamma curves) and the meta data concerning the ST7789V would be thrown away. Furthermore, as the future direction of fbtft development is uncertain, it makes little sense to optimize the code for an interface which has not been defined yet. Even if the final interface to the normal user should provide display drivers instead of display controller drivers, the abstraction of display controllers as reusable components for display driver developers would still be a desirable solution. In addition, the more the available drivers for fbtft diverge from each other in terms of design and structure, the harder it will become to convert them to the successor framework in the future. Therefore, I think it is reasonable to keep the current display controller driver for the ST7789V. Best regards, Dennis Menschel _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
