I just added an implementation of disp_dev
(see #13262) to #12509. I have some (admittedly minor) feedback about the current API:
The color
parameter for disp_dev_map
is an uint16_t
pointer. This implies that pixels should at least be 16 bits. The e-Paper display in #12509 uses a single byte per 8 pixels, so it would be more natural to use uint8_t
there. Especially when dealing with something like a 8x3 pixel image.
In the implementation for the ili9341 x2
and y2
describe the coordinate of the inner pixel of the corner, not the outside corner. This is also noted in the documentation of that driver. It is not, however, noted in disp_dev_map
. I also think that (even when explicitly noted) this is not an intuitive use of coordinates: a rectangle with two opposing corners having the coordinates (5,5) and (5,5) has an area of 0, not 1.
disp_dev_set_invert
will probably not apply to all displays. It is currently not possible to communicate this to the user.
Proposals:
Add a return type to
disp_dev_set_invert
indicating success/failure. This should probably also be the case fordisp_dev_map
.
A different solution for this could be to add a number of capability flags to a driver to indicate different driver capabilities.
I have proposal for the color depth issue in the PR #14054 .
While I did some simplifications of the API for coordinates in #14051 .
I also think that (even when explicitly noted) this is not an intuitive use of coordinates: a rectangle with two opposing corners having the coordinates (5,5) and (5,5) has an area of 0, not 1.
But the Coordinator simplification doesn't address this issue. Just a simplification of the API itself.
Use width (w) and height (h) instead of x2 and y2 to avoid any confusion. This is also what SDL, Gegl and Cairo do.
I agree with that one. Should address the issue.
Is it somehow possible to push this topic, so it is not going to die? :)
Ping @aabadie @bergzand?
Ping @aabadie @bergzand?
Most helpful comment
Ping @aabadie @bergzand?