inmarket

You need to use the i686-pc compiler not the i686-w64 compiler. The difference is the startup files and the "Windows console mode" the two compilers use. Unfortunately I have not been able to find a way to overcome the differences. The i686-pc compiler is available in cygwin64 too as that is the one I use all the time.

While semantically different, in uGFX they are actually the same thing.

The uGFX fonts will not be compatible with the hardware font engine. You would need to load whatever font format the hardware requires and that will cause visual differences to the uGFX fonts.

To do a chip like this well would require significant architecture changes to uGFX. Things like hardware accelerated fonts are also not a good idea if you want to maintain consistancy accros platforms as hardware fonts vary from vendor to vendor. There are several approaches to implementation for this chip: 1. (Recommended) The existing available acceleration functions are implemented ie fillarea, blit and scroll. This should give good performance for most situations. uGFX internally uses these for all more complex operations so adding extra acceleration has diminishing returns. 2. Extra features that are specific to this chip can be taken advantage of using the gdispControl interface and other uGFX interfaces eg. Page switching (gdispControl), storing of graphic assets (GFILE using NATIVE format messages), multiple display surfaces (extra GDisplay objects) 3. The extra acceleration functions for line, circle etc could be shoe horned into uGFX. This is complex, requires archetecture changes in uGFX and is redundant given the uGFX V3 is completely changing the GDISP driver interface. I would definitely suggest that this part not be attempted until atleast stage 1 and 2 above are complete.

There is likely a bug in your fillarea driver routine. The easy way to test this is to turn off GDISP_HARDWARE_FILLS in your gdisp_lld_config.h file. If everything works (albiet slowly) then the problem is in your gdisp_fill_area routine. If it still doesn't look right then the problem is in the gdisp_draw_pixel routine. Also the GDISP_STARTUP_LOGO macro belongs in your gfxconf.h not in the driver config file.

Any help is very welcome. Our understanding is that the files in the above mentioned forum post work - its just a hacky way of doing it which is why we have delayed adding it to the repo.

The first thing that happens with any display is that the screen is cleared regardless of whether the startup logo is displayed. That is why implenting the hardware accelerated clear helped. Any time you are doing a screen as large as 1920x1080 you are talking about a LOT of pixels. Acceleration functions are absolutely mandatory especially on slow cpus. Make sure you implement all the ugfx acceleration functions, particularly fillarea and blit. Text drawing is a complex operation and is not the fastest operation. On one hand uGFX uses bitmap fonts which are much faster than rendering scaled fonts like truetype. On the other hand uGFX does not cache rendered fonts because it assumes it doesn't have the RAM to do so (and won't on most embedded systems). This then makes it slower than cached truetype. The only thing that can be done currently is to implement the deiver acceleration functions. It is currently too big a job to add another font engine (like freetype) when that font engine will be of no use to 99% of the uGFX user base because of its code and RAM requirements.

Thanks to work by @cpu20 the STM32F746-Discovery now works with ChibiOS V3 and V16. ChibiOS V2 doesn't support the STM32F7 processor so ChibiOS V3 is the minimum version for this board. The changes are now in the repository.

cpu20's changes (slightly changed) and your makefile modification are now in the repository

I have updated the uGFX repository with the changes and updated it so that it also has a better chance of working reliably across other OS's. Thank-you very much @cpu20 for the hard work. I have also incorporated your ChibiOS 'git' version make changes (although with a slight modification so that the ChibiOS version has to explicitly be set to git in the makefile).

Great news! I will try to follow that up this weekend. Thank you for all your hard work on this.

1. SPI will be fine provided the display resolution is not too high. The higher the redolution the higher the bandwidth you need to update it at a reasonable speed. 2. On the uGFX website there is a list of controllers that are supported. Any supported controller will work with STM32. 3. You will need RAM for a framebuffer only if your chosen display controller does not have internal RAM for the framebuffer. In practice all SPI and 8 bit parallel controllers will have internal RAM for the framebuffer. 16bit controllers may or may not depending on the controller.

The framebuffer address is set to correspond to the start of the external SDRAM.

Sounds like you have reached the point we did - nothing obvious seems to fix the problem. With regard to the id cache, any difference you find is worth testing

Those things will be looked at in V3

V3 is where some of these acceleration issues are being dealt with. If you have a suggested controller I will work on ensuring the new architecture can be extended for it.

Adding your own accelerated functions is generally not a good idea for several reasons: It disrupts the driver model and makes it incompatible with every other driver and with multiple display scenarios. It makes it incompatible with work currently progressing on uGFX V3 It creates a custom modified version of uGFX that cannot be updated easily as we change uGFX or fix bugs Unless those modifications are submitted back to the repository it will breach the license agreement (any custom modifications to uGFX itself need to be contributed back under the license agreement) On most small controllers, the accelerated functions actually perform slower than the mechanisms we use to accelerate drawing despite the SPI interface. The reason is that the controllers simply do not run fast enough silicon.

With regard to some of the other issues you raised... With regard to ifdefs for your new code... There are two ways of handling this, either add a config and ifdef your additional code within the existing LTDC driver. The alternative way is to create a new LTDC-db driver based on the LTDC driver. Which approach you take is your choice and probably depends on the level of complexity to the code that you are adding/changing. With regard to passing high level synchronization flags, it is probably just not necessary. We have the flush driver interface and a gdispFlush API call that can make explicit use of it if required. Ither synchronization issues such as redraw tracing can be handled in the driver itself by yeilding to other threads or busy waiting until the retrace is available. Due to timing constraints most drivers in this situation will busy wait because the timings are too tight to allow yeilding the thread. With regard to busting of write operations, uGFX V3 has significant advantages in this area and is one of the primary improvements in V3. Even on slow SPI links this can sometimes add efficiency because in a burst operation better choices can be made as to whether invoke dma use. Currently drivers either do or don't. If they do they are disadvantaged for short bursts, if they don't they are disadvantaged on long bursts and can't recover the cpu cycles that dma would have avoided. For V3 far more intelligent decisions can be made. With regard to large displays with slow hardware interfaces, if you need to write the pixels then you need to write the pixels and it will take as long as it takes. While uGFX goes to a lot of trouble to avoid "double-printing" (ie unnecessary pixel drawing) particularly at the GDIP level, as they say in English "You can't make a silk purse out of a sows ear". The one area that uGFX could improve double-printing is in the redraw strategy for GWIN. Changing this however has major considerations for other resources particularly RAM usage.

To implement transparent double buffering using dma to transfer the display would most easily be done in the driver flush routine. The LTDC driver is based around the framebuffer driver. Each pixel gets set into the framebuffer. By adding a flush call to the driver GDISP will call that at appropriate moments (we will talk more on below). For your double buffered LTDC the flush would swap the buffers and start the dma transfer. Note you would also have to put a test into the setpixel driver routine to ensure it didn't try to write a pixel before the dma transfer had finished. Flush is the ideal place to put the double buffer swap as that is exactly what it is designed for - to take pending display updates and flush them to the real display. It is used by most of the monochrome drivers for exactly that purpose. There are a couple of strategies that GDISP can use to call your driver flush. These are controlled by config variables. The default method is to call flush after each high level gdisp call. This is the best method for quick updating of the display but has the disadvantage of potentially slowing down drawing speed particularly if the flush is an expensive operation as in your case. The alternative method is to flush on a timer. A gdisp operation triggers a timer. Thus multiple operations are merged into a single flush gaining efficiency. The period of the timer can be set to compromise between efficiency and latency.

gfxInit calls _gdispInit which calls gdriverRegister which calls _gdispdriverinit (I am uncertain of this functions name as i am cuurently not at my computer) which then calls gdisp_lld_init. gfxInit initialises the entire uGFX system. _gdispInit initialises the GDISP module. For each display driver it calls gdriverRegister. gdriverRegister allocates the driver structure and adds it to the driver chain. _gdispdriverinit is then called to initialise all the common gdisp components within the driver structure. It in turn calls gdisp_lld_init gdisp_lld_init in the driver initialises the driver and the hardware. There is also a post init sequence of calls to enable the driver to change to non-init bus speeds. Most drivers don't use this however. The source of your delay you will need to find by debugging. It is likely in your driver as initialisation is very quick except where delays are introduced by drivers waiting for hardware. The only other source of delay in gfxInit is the startup logo. That starts as soon as each display adaptor initialises and ends a few seconds after all displays are initialised. This delay is obviously intentional and can be turned off.

You would need to decode your image into a pixmap. That would then give you the image in memory non-rotated. You could then build a rotation matrix and then point by point transfer the image to the display passing each x, y coordinate through your rotation matrix to get the destination x,y coordinate.

Anytime that changing the optimization level changes the output - that indicates a bug in the compiler optimiser (or atleast an inadequacy). While we try to write code to avoid common optimiser bugs, uGFX supports many compilers and we can't cover every optimiser bug in every compiler. Unfortunately as a result we always suggest compiling only with basic compiler optimiser settings ie -O0 or -O1. -O2 seems to work on some compilers but not all.

The two GDISP_SCREEN_XXX macros are pretty much obsolete. They may be used inside a driver to initialise the display size eg Win32 but that is not required. What is important is the setting of the g->g.Width and g->g.Height members in the gdisp_lld_init routine. Once initialised there is no api support for changing the resolution thereafter although something could be coded using a special GISP_CONTROL code. You would however need to be very careful with framebuffer reinitialisation and things like that.

It sounds like you want the full power that X (with or without Qt) can provide. Unfortunately that doesn't come without resource cost. uGFX obviously doesn't come with all those features but it also doesn't come with the same resource cost either. The same will apply for whatever system you use - it is always a compromise between the features you want and the cost of those features. BTW, video is posdible with uGFX particularly using our streaming API. It just won't be as efficient as the GPU decoding and displaying the video directly. Even using GPU for decoding, tranfering to CPU RAM and then streaming will add overhead. You could however use uGFX to reserve a window area and then use GPU decoding and rendering within that window. Whether that is worthwhile or not depends on the resource issues that your application requires. Note that no windowing system other than X will allow you to use the GPU on the raspberry pi. That is because that is the only aolution that the closed source GPU driver has been made available for although I believe there are efforts being made to reverse engineer how it works.

Yes, what Joel said is correct. We are happy for any contribution at any level. I am happy for either V2 or V3 contributions. V3 contributions are easier for me as I don't have to port the type names etc to V3 but they will obviously not be available for most users until V3 is released. V3 currently compiles for Win32 to the point where it can run the basics demo. Most of the rest of GDISP is broken as it hasn't been ported to the new driver interface. In fact some of the finer details of the V3 driver interface are not settled yet eg. Whether the driver or the gdisp layer updates the window cursor (currently the driver). If you are interested I would be happy to talk to you outside of the forum on the design aims and efficiency comprimises that are being made there. I am currently in the process of moving display orientation support from the driver into the gdisp layer and introducing the concept of a scan direction for the driver. This will enable orientation support on all displays with better efficiency for those that support scan direction changing. Win32 will remain the only driver capable of running V3 until the interfaces are finalised. I tend to try and leave the V3 repo in a compilable state (although currently only for the basics demo) so if you are feeling brave you are welcome to try it. Once I have the GDISP low level layer finalised (anything that needs to take the driver lock) there will be lots of work porting drivers etc and any extra man power would be highly appreciated. Any new features that don't require GDISP low level code are also very much appreciated. As an example I have a bunch of code with new trig highly efficient trig api. That needs to be tested and integrated and V2 compatibility thunks added but obviously the new driver interface is currently taking priority. However you would like to help or contribute we would be very glad.