search

rm-hull / luma.core

A component library providing a Pillow-compatible drawing canvas, and other functionality to support drawing primitives and text-rendering capabilities for small displays on the Raspberry Pi and other single board computers.
https://luma-core.readthedocs.io
MIT License
144 stars 52 forks source link

Retrieve supported display modes for device #155

Open thijstriemstra opened 5 years ago

thijstriemstra commented 5 years ago

Would be nice to have a unified API that returns the supported display modes for a certain device. Right now these values are hardcoded and impossible to retrieve, e.g.

thijstriemstra commented 3 years ago

@rm-hull I was thinking about something like a get_supported_modes() (or sizes) method on luma.core.device.device that returns whatever dimensions the luma device type supports.

For example, for luma.lcd.device.st7735, get_supported_modes() would currently return:

[(160, 80), (160, 128), (128, 128)]

For luma.oled.device.sh1106 it would have to include some extra data or we need to remap this dict action going on there:

{
    (128, 128): dict(multiplex=0xFF, displayoffset=0x02),
    (128, 64): dict(multiplex=0x3F, displayoffset=0x00),
    (128, 32): dict(multiplex=0x20, displayoffset=0x0F)
}

Like the previous example, it should return a list:

[(128, 128), (128, 64), (128, 32)]

but with some more metadata, so not a tuple but perhaps a dict with width/height keys?

Thoughts?

rm-hull commented 3 years ago

What or how would you make use of get_supported_modes()?

I think in principle, yes we could readily add that to every device class (possibly as a class method?) but I’m wondering how a program could actually make use of it, because mostly if you have a display you almost certainly know up-front what the size is.

thijstriemstra commented 3 years ago

I would use it in the luma.examples, and show what sizes are supported in the error message. And yea overall it's cleaner to have it in a central place, I often check the source code what sizes are supported and having it in a general place across all luma devices would be nice.

It's actually surprising to me that not having it central/in place since day one, and that it's an afterthought in the API. I guess this indicates it also not as important to have but still.

It's mostly a refactor thing to make things uniform.