search

rm-hull / luma.lcd

Python module to drive PCD8544, HT1621, ST7735, ST7567 and UC1701X-based LCDs
https://luma-lcd.readthedocs.io
MIT License
156 stars 56 forks source link

Support ILI9488 3.5" (320x480) displays #147

Closed TCB13 closed 2 years ago

TCB13 commented 2 years ago

Hello,

Are there any plans to support for 3.5" (320x480) displays with the ILI9488 chip? Or anyone already did it?

Examples of devices:

Thank you.

rm-hull commented 2 years ago

No plans to write a driver for it, but if there is a Linux framebuffer driver for this device, you could use https://luma-core.readthedocs.io/en/latest/device.html#luma.core.device.linux_framebuffer instead

TCB13 commented 2 years ago

Interesting, so I can get a PIL.ImageDraw out of the core device and use it to draw stuff in the same way I do with supported screens?

Side question, this library seems to support ILI9341 and there's also fb_ili9341 for it. Why is supported "natively" by the library and the other is via framebuffer? Or it all comes down to nobody with the skills and time to implement it on the library needs it?

Thank you.

rm-hull commented 2 years ago

Interesting, so I can get a PIL.ImageDraw out of the core device and use it to draw stuff in the same way I do with supported screens?

Yes, exactly

Side question, this library seems to support ILI9341 and there's also fb_ili9341 for it. Why is supported "natively" by the library and the other is via framebuffer?

The original ILI9341 driver was quite slow - pushing out a lot of pixels in python on a RPi was "challenging". We made some improvements to the diff to previous framebuffer, so it only drew changes since last time - this immensely improves FPS.

The framebuffer luma driver is universal (and was implemented after the ili9341 IIRC), and obviously there exists a number of different fb kernel drivers, so adding the framebuffer luma impl opened up to more devices.

Also framebuffer driver is likely to be better performance for larger screen resolutions

Or it all comes down to nobody with the skills and time to implement it on the library needs it?

I guess it mostly boils down to that yes, plus needing to acquire a device to test against

TCB13 commented 2 years ago

Thank your for the patience and detailed answer. It makes perfect sense now. I'm going to try the framebuffer driver route and see how it goes.