GDISPVMT_pixmap missing

[inmarket]

Things are a bit more complex than that unfortunately.

The addition of a 2nd display completely changed the way a video driver is hooked into the system. The reason for that is there are performance and speed penalties for multiple display support and the system calculates the optimal configuration to minimise those penalties. The system of #defines used to make all this happen just do not work with single file make.

If you want to try, not only will pixmaps need to be compiled seperately but also gdisp.c

Try that. It might get you closer.

[Guest]

I am getting a bit closer. I have been able to compile gdisp.c separately, and I am probing a bit into how pixmaps are sent to the display module. As far as I can tell, I am getting stuck when trying to draw to the display itself. I am not sure where I should set the method gdispGBlitArea uses to send data to the display. GDISP_HARDWARE_BITFILLS doesn't seem to work with the display (I don't think DMA will work in this case), and GDISP_HARDWARE_FILLS gets undef'd by the pixmap driver.

Still a bit more work to do here, but I have a separate question. Are pixmaps the only way to get a framebuffer to work? All I am trying to do is get a configuration where I can write to a framebuffer, and only send the changed pixels each time I draw the display. Are pixmaps the right route for this? I see a framebuffer driver example in ugfx, but it doesn't seem to mention pixmaps...

[inmarket]

It is not clear from your description what you are actually trying to do.

When you say you want a "framebuffer to work" do you mean a device that uses a memory framebuffer such as the STM32 LTDC or the Linux kernel driver, Or are you referring to an off-screen framebuffer.

If you are talking about hardware that display from a memory framebuffer then you need to use the framebuffer driver and just change the init routine in your board file as appropriate. There are plenty of examples in the boards directory.

If you are talking about an off-screen framebuffer then pixmaps are the way to go. Pixmaps create a "virtual display" that you can draw into. The pixmap can then also be used as a NATIVE format image to copy parts of that virtual display onto the real physical display. As there is now more than one display (one physical, one or more virtual) it requires multiple display support in the code which is the part that does not work well with the single file make.

If you are wanting to create a "difference" display where you write to a framebuffer and then use some algorithm to flush those changes to a real non-framebuffer display - don't do this. The reason is that uGFX is highly optimised in its drawing routines and understands the underlying hardware design of most embedded displays. uGFX is going to make a much better job of it than any difference engine you create. The only exception to this is for displays where it is not possible to just update a single pixel such as monochrome displays where the minimum update unit is 8 pixels (one byte). For these an internal framebuffer is maintained - see one of the monochrome driver code as an example. Fortunately these display tend to be small and there only require small framebuffers.

 

[inmarket]

With regard to GDISP_HARDWARE_BITFILLS etc, they are complicated macros.

For single display support they are set using the drivers gdisp_lld_config.h file and included into the general list of defined symbols via gfx.h.

For multiple display support it is a lot more complex. The macro is first used to build a VMT (virtual method table) in the driver itself which describes the various available drawing routines. The gdisp_lld_config.h file is therefore now included by the driver itself rather than by gdisp.c and is not part of the general list of symbols included from gfx.h. For the general list of symbols those macros are set as a special value which indicates to the GDISP code it should use the VMT table instead of the direct routine. This is further complicated by allowing a user to set these macros in the gfxconf.h file (but only for multiple display support). If set in the gfxconf.h file these represent overrides that tell gdisp.c that ALL multiple display drivers either do (TRUE) or don't (FALSE) support that routine and thus it doesn't need to test further for support or not.

I hope that helps/