On Wed, Jan 26, 2022 at 02:46:08PM +0100, Javier Martinez Canillas wrote:
On 1/26/22 14:12, Andy Shevchenko wrote:
On Wed, Jan 26, 2022 at 12:26:36PM +0100, Greg Kroah-Hartman wrote:
On Wed, Jan 26, 2022 at 12:17:08PM +0100, Helge Deller wrote:
On 1/26/22 11:31, Daniel Vetter wrote:
...
You are describing a transitioning over to DRM - which is Ok. But on that way there is no need to ignore, deny or even kill usage scenarios which are different compared to your usage scenarios (e.g. embedded devices, old platforms, slow devices, slow busses, no 3D hardware features, low-color devices, ...).
All of those should be handled by the drm layer, as Daniel keeps pointing out. If not, then the tinydrm layer needs to be enhanced to do so.
Anyone have a pointer to hardware I can buy that is one of these fbtft drivers that I could do a port to drm to see just how much work is really needed here?
I have bought myself (for other purposes, I mean not to convert the driver(s)) SSD1306 based display (SPI), SSD1331 (SPI), HX88347d (parallel).
I've just bought a SSD1306 (I2C) based one and will attempt to write a DRM driver using drivers/staging/fbtft/fb_ssd1306.c as a reference.
You should take ssd1307fb.c instead. And basically create a MIPI based driver for I2C. Then we won't go same road again for other similar devices.
I didn't find one with a SPI interface but we can later add a transport for that if I succeed.