Display framebuffer allocation

[5frank]

Problem

Most drivers do not provide a framebuffer but the display interface seems to assume a framebuffer is used. (Example drawing a horizontal line 64 pixels might require 64 bytes of buffer).
This is probably why cfb allocates it's own framebuffer. However this is a problem as the buffer can not be used for other things like drawing a line or add a logo next to the rendered text. Having separate buffers is not a option as most(?) drivers do not support write of individual pixels.. It is also a waste of memory to have multiple framebuffers if not needed.

Solution (suggestion)

• cfb should at least try to get the framebuffer from the driver before calling k_malloc.
• Perhaps have something like CONFIG_DISPLAY_DRIVER_FRAMEBUFFER that requires the drivers to allocate a framebuffer at compile time?

[5frank]

A problem with suggested solution is that it is not clear what buffer size, pitch etc display_get_framebuffer(const struct device *dev) will return. If for example this buffer would be passed to display_write(), then what would the struct display_buffer_descriptor *desc argument be?

[jfischer-no]

Most drivers do not provide a framebuffer but the display interface seems to assume a framebuffer is used. (Example drawing a horizontal line 64 pixels might require 64 bytes of buffer).

No, that depends on the pixel format, and you can draw a line with very small buffer sufficient for minimum addressable unit that a display controller supports, for example 3 bytes for one RGB_888 pixel, a buffer multiple of 3 makes it faster to draw a line but is not required.

This is probably why cfb allocates it's own framebuffer. However this is a problem as the buffer can not be used for other things like drawing a line or add a logo next to the rendered text. Having separate buffers is not a option as most(?) drivers do not support write of individual pixels.. It is also a waste of memory to have multiple framebuffers if not needed.

CFB was designed before display controller driver API, it can be changed to use smaller buffer to render the characters. It is not designed to render graphic primitives, there was no need, although this can also be changed too.

Solution (suggestion)

* cfb should at least try to get the framebuffer from the driver before calling k_malloc.

Not really sure what do you mean by "framebuffer form the driver", rather cfb can be optimized to use smaller buffers.

* Perhaps have something like `CONFIG_DISPLAY_DRIVER_FRAMEBUFFER` that requires the drivers to allocate a framebuffer at compile time?

That also does not make sense.
I do not see what the concrete enhancement should be, it rather question round.

[5frank]

Thank you for the input @jfischer-no! Sorry if I was a bit unclear!
I do not propose graphics primitives to be a part of CFB, it is probably better this is handled by another module. But for this to be possible a common framebuffer must be used. This as the minimum addressable unit is more then one pixels for many display controllers. I assumed, perhaps incorrectly, that display_get_framebuffer() was created for this purpose, so that CFB and other "graphics" modules could share the same buffer.