Support ILI9488 3.5" (320x480) displays about luma.lcd HOT 4 CLOSED

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.

from luma.lcd.

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

from luma.lcd.

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.

from luma.lcd.

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

from luma.lcd.