[Enhancement Request] Making TFT library more generic

[q2dg]

Now TFT Screen has been retired, TFT library seems pretty useless. Would it be too difficult to adapt it to be able to support more screens (at least the most common/popular) "à la UTFT (http://www.rinkydinkelectronics.com/library.php?id=51)" or similar? Then we could use common minimums offered by the official TFT library like the LiquidCrystal does (namely: without caring about the exact screen manufacturer) I suppose the crux is add more drivers below abstraction layer, but I don't know if it is easy.
Thanks, anyway.

[Chris--A]

All screens I have bought off the internet have all had their own library or are supported by some popular libraries like u8glib and UTFT. Unless the offerings of this library are something unique, or can support a screen that the others don't, It might be best to leave this for all the people that own the official screen, not saying don't improve it, however creating a hardware abstraction is going to require a good modification and would probably be better as a new library.

Besides, the others have far more users which results in more debugging and hopefully robust code. If it has not been added already, it wouldn't be too hard to integrate the screen into one of the other libraries already with a hardware abstraction layer.

[shiftleftplusone]

I agree, there are tons of issues about TFT displays (most of them from China) with shady driver support, which are hard to make work with UTFT or u8glib libs or don't work at all. A hardware abstraction layer to provide sort of a Arduino standard display interface (additionally feat. hardware SPI support) would be very much appreciated!

[agdl]

This issue was moved to arduino-libraries/TFT#3