Joel Bodenmann

Glad to hear that you're making progress Feel free to ask if you have any more questions. We're happy to help wherever we can!

Hello & welcome to the µGFX community. Given that the library currently doesn't ship with a GDISP driver for the ST7789 I assume that you wrote your own. We'll try to address your issues as best as we can: Speed: Make sure that your driver is setup correctly and that your host's SPI is configured to run at a decent speed. Check the corresponding datasheet(s) to determine the maximum allowed bus frequency that your physical driver and display module can handle. Brightness: Not every display module uses features built into the physical controller for screen brightness control. Often you get a simple set of LEDs with which you can control the brightness via PWM. Check whether this is the case in your scenario. If so, changing any of the physical display driver configuration registers won't have any effect on the display brightness. You can setup a PWM peripheral in your GDISP driver's board file in order to still be able to use gdispSetBacklight() to control the brightness. Full image: I'm not sure what you mean by this. However, this sounds again like an issue with your GDISP driver. I do not know which "LCD image converter tool" you're talking about. Image formats supported by µGFX are listed here: https://wiki.ugfx.io/index.php/Images It's difficult to help without being able to review the driver. If you're unable to share the driver publicly, you can get in touch with us for paid support.

Hello & welcome to the µGFX community! Regarding your first compilation output: It seems like the corresponding features are not enabled in the configuration file (gfxconf.h). Most notably it seems like GDISP_NEED_TEXT and GWIN_NEED_TABSET. Did you use the configuration file that ships with the demo? If they are not enabled in there we certainly need to update that demo. The same seems to be the case with your second compilation output. It seems like some features such as text, circles and GINPUT are not enabled. Useful resources: Example configuration file: https://git.ugfx.io/uGFX/ugfx/src/branch/master/gfxconf.example.h Wiki article: https://wiki.ugfx.io/index.php/Configuration

We're currently in the process of adding support for the CMake build system. The current master branch of the git repo contains the current efforts. One can easily include the µGFX library into a consuming cmake project using find_package(). We're still in the process of adding support for all the currently available boards & drivers.

As long as you can avoid modifying library code that's certainly the way to go. Can you share the code of how you create the container? See the section regarding "Border": https://wiki.ugfx.io/index.php/Container#Border

Yes, the window manager will resize a widget to fit into the parent. This is where the inner size (inner width & inner height) come into play. Check the return values of gwinGetInnerWidth() and gwinGetInnerHeight() of the parent container. This will most likely return the values you initially reported. The WM has no other option but to resize the widget to fit those dimensions. If your child needs to have those exact dimensions, either make the parent container larger or implement a container which handles this the way you need it. I think the default built-in container has a border vs. no-border option (check the docs). I think if you disable the border the inner size will not be reduced by the border size.

What's the size of the parent container? It's possible that the window manager is resizing the button widget to fit into the container. The container API provides gwinGetInnerWidth() and gwinGetInnerHeight() to retrieve the inner height & width of the container.

Hello & Welcome to the µGFX community! Unfortunately, the µGFX-Studio is currently not publicly available.

Hi, As of today, we do not provide python bindings. However, as this is a plain C library it would be very easy to do so. In fact, there have been successful efforts in providing a MicroPython wrapper in the past: https://badge.emfcamp.org/wiki/TiLDA_MK3/ugfx https://github.com/pypilot/micropython_ugfx https://github.com/SHA2017-badge/Firmware We'd be more than happy to answer any question you might have when writing bindings. This would certainly be a great addition to the library!

@inmarket and I revisited this today. Both problems you reported are now fixed by these commits: 1235a9056c8324c5552f739114343b3e91dc15fb 7845f44f20034779d7d3c969750279297ff524ce Thank you for reporting these! Your contribution were noted in the corresponding commit messages.

Took a bit longer than expected to get to this but yeah: This is definitely a typo. Fixed in commit 888c7e8640caf02082adc23c967c5c0ba49a5146 Thank you for reporting this! There were some other improvements to the STM32LTDC driver in the meantime (which is why getting to this took a bit longer):

Hello & welcome to the µGFX community! If gfxAlloc() returns NULL, it indeed would indicate an issue with the memory layout/setup/capacity. You are setting GFX_USE_OS_CMSIS to GFXON. Are you actually using the CMSIS OS? Note that the CMSIS OS is a different component than the CMSIS library itself. If you're not using the actual CMSIS OS, you should select the proper OS instead - or use GFX_OS_RAW32 instead. After checking the OS situation: To further debug this, I'd recommend disabling the GDISP Module (setting GFX_USE_GDISP to GFXOFF in the configuration file) and trying to do various calls to gfxAlloc() in your main() right after gfxInit(). This way you can more easily figure out what is actually happening.

We've made changes to the STM32LTDC driver. While the changelog and updated board files reflect the changes necessary this forum post attempts to provide an overview of the changes necessary for migrations: Peripheral clock setups The driver no longer implements the necessary logic to setup the clocks for the LTDC & DMA2D peripherals. Instead, the board file now contains the new functions: void init_ltdc_clock(void) void init_dma2d_clock(void) Prior to this change, the driver itself setup the clocks. This change was made to increase portability and remove any dependency of underlying HAL definitions for RCC. This change also makes the previously existing LTDC_NO_CLOCK_INIT option obsolete and was removed accordingly. Renaming existing configuration options For consistency reasons and easier upgrading to µGFX v3.x, the following changes were made to the configuration options: ALLOW_2ND_LAYER -> STM32LTDC_USE_LAYER2 GDISP_LTDC_USE_RGB565 -> STM32LTDC_USE_RGB565 LTDC_DMA_CACHE_FLUSH -> STM32LTDC_DMA_CACHE_FLUSH LTDC_USE_DMA2D -> STM32LTDC_USE_DMA2D Double Buffering The STM32LTDC now supports double buffering. This feature can be enabled via STM32LTDC_USE_DOUBLEBUFFERING. For more information on this, see the readme.md in /drivers/gdisp/STM32LTDC.

Here's the `gdisp_lld_Win32.c` file I was using for this test (this is the same as in the current `master` branch): gdisp_lld_Win32.c That sounds like something worth contributing

I am working on reproducing this. Unfortunately, I was unsuccessful so far. Here's my simple test case following your pseudo code: #include "gfx.h" int main(int argc, char* argv[]) { (void)argc; (void)argv; gfxInit(); // Open image gImage myImage; gdispImageOpenFile(&myImage, "640x480.bmp"); // Create pixmap GDisplay* pm = gdispPixmapCreate(640, 480); gdispGImageDraw(pm, &myImage, 0, 0, 640, 480, 0, 0); // #1: blit the entire pixmap on the display - works correctly gdispGBlitArea(GDISP, 0, 0, 640, 480, 0, 0, 640, gdispPixmapGetBits(pm)); // #2: Blit a partial pixmap on the display with source coord (0,0) - works correctly gdispGBlitArea(GDISP, 0, 0, 200, 200, 0, 0, 640, gdispPixmapGetBits(pm)); // #3: blit a region from the middle of the pixmap to the display (source coord != (0,0)) - PROBLEM!! gdispGBlitArea(GDISP, 200, 200, 200, 200, 200, 200, 200, gdispPixmapGetBits(pm)); // Close the image gdispImageClose(&myImage); // Keep the application alive while (gTrue) gfxSleepMilliseconds(100); return 0; } When running this, the window (display) shows the image as expected without any defects. Am I missing something obvious here? For reference, here is a ready-to-run Win32 project with the code shown above and the corresponding asset(s): win32_blit_test.zip

I might have a look at this in the meantime. Could you provide the exact font you used (ideally both the font source file (if possible due to licensing) as well as the output of the font converter).

We're currently in the process of migrating our git server. Up until now, we were running Gogs but we're changing over to Gitea. Any user accounts with last activities older than 6 months will not be migrated to the new server. If you'd like to get an account on the new git server (once migration is completed) please get in touch with us.

Thank you for bringing this to our attention. Any form of feedback & possible bug report is welcomed I'll be working the STM32LTDC driver in an upcoming project (few days/weeks from now). I will look into it then.

Thanks, we will look into this!

Thank you for bringing this to our attention! Can you supply a minimum test-case that allows reproducing the bug(s) and corresponding patch(es)?

I haven't had time to check out your code yet - just the video. Looking good! What was their reasoning that it wouldn't be possible? if you like we might be able to improve this together and eventually put it into the official µGFX library so it's supported out-of-the-box

For paid support options/discussions, please contact us via e-mail: info@ugfx.io

Hi! As you stated the existing text edit widget only allows for one line of text. The proper way of doing this is creating a new widget called MultilineTextedit and implement the functionality. It might make sense to use the exsting Textedit widget as a base for this (i.e. copy-paste & modify). Other than the API documentation you can find documentation on creating your own widget here: https://wiki.ugfx.io/index.php/Creating_a_widget Alternatively we can implement the widget for via paid support.

Hello & welcome to the µGFX community! Yes that is still true. If you purchased an µGFX 2.x unlimited commercial license you can still use any 2.x release without any additional costs. This also applies if it's a new/different project or product as long as the license holder noted on the licensing document is executing the development/sale.

@inmarket any insights from your side?