Joel Bodenmann

> I am working with a recent git version of ugfx and Chibios 18.2. How recent is recent? There has been a text edit fix two months ago: https://git.ugfx.io/uGFX/uGFX/commit/509fc7501e7bd30b1b314fc0d4838d7cdf6ac621 I'm currently on the road so I can't dive into this right now. But can you reproduce it with the most minimal test case? Eg. using gwinSetText() with a simple string parameter (no runtime buffer stuff) and setting the last argument to TRUE? So I guess the response to your "I suppose using dynamic text could provide a workaround, but I thought I would ask before trying too many things." statement is pretty much: That's exactly what I'd recommend you to try to track down the problem.

Hmm... the board file template is definitely missing. Thank you for bringing this to our attention. Many of the drivers are community driven and do not originate from the official µGFX developers. We're definitely going to take better care of this in µGFX 3.0. We're thankful for any kind of bug reports and/or patches. Usually a forum post will do - if possible with a patch that we can just apply. Alternatively you can make a pull request on the µGFX git server. It's correct that those functions will actually write data to your display controller (in your case) through your SPI peripheral. Most displays that are in the style of the ILI9225 have a pin called D/C or similar - sometimes it's an additional bit in the SPI frame. That bit will tell the display controller whether the data it's receiving is actual pixel data (write_data()) or commands such as changing the viewport, changing rotation or setting any other kind of register value (write_index()).

I'm currently on the road so I can't easily check, but I'd say it's rather likely that the board file can be found in the /boards directory of the library or in the downloads section of this forum.

Thank you for bringing this to our attention. We'll fix it ASAP.

Are you able to supply a patch (diff)?

Thank you for bringing this to our attention! As you mentioned yourself there is the need to clean the widget initialization structure prior to using it. We have updated the example code in the wiki.

That sounds like a content-size / timeout related issue. I'll dive into this ASAP.

If I understand you correctly the return value of the ioctl() function call is different from your observation. Could you check the value of fb-fix.line-length before passing it to the ioctl() function? Also, I am bit surprised that you mentioned multiple calls to the framebuffer driver initialization. I don't have all the code in my mind but that seems a bit fishy - are you using two displays?

Sorry for the late reply - not sure how this didn't show up in my notifications list. That's certainly possible. We have several customers who use µGFX for overlays / OSDs. I'd recomment that µGFX provides its own video output that you then mix together / on-top of the video using gstreamer.

I'm having serious trouble reproducing this - could someone else give it a try?

Hello and welcome to the µGFX community! I'd have to check the code to be sure but if I remember correctly the vfnprintg() implementation doesn't support leading zeros at the moment. If that's the case we'd be more than happy if you decide to add support for that.

Did you try to debug to figure out where the segmentation fault origins from? It will most likely be due to an issue in the GOS abstraction as everything else is high-level code that builds on top of that.

I'll have to look at this when I got a bit more time to understand this properly. However, unless you're in a serious memory shortage I'd recommend you not to destroy & re-create the widgets. Instead, just use gwinShow() and gwinHide() (alternatively gwinSetVisible()) to make the appropriate widget become visible.

Thank you for sharing this - much appreciated!

We've tracked the problem down to a source-IP based load-balancing issue. It should be fixed now.

If you just want to change the colors you can use widget styles: https://wiki.ugfx.io/index.php/Widgets#Widget_Style Alternative you can write a custom rendering function for the widget: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routine Or even write your own widget that does exactly what you want: https://wiki.ugfx.io/index.php/Creating_a_widget

The error is indicating that the compiler cannot find the GDISP driver's configuration file which is located in the driver's directory. I'm not an Eclipse expert but most likely you forgot to include the GDISP driver directory in your compiler/linker include path: https://wiki.ugfx.io/index.php/Using_Eclipse#Adding_driver_resources Maybe @cpu20 can help.

To get the system itself working it's strongly recommended to disable all modules (including the GDISP module). You have the RAW32 subsystem enabled. You might want to have a look at the corresponding documentation: https://wiki.ugfx.io/index.php/BareMetal

The first error is because you enabled the GDISP module but you haven't added any GDISP driver. To get started simply disable the GDISP module (and any other module!) in the µGFX configuration file (gfxconf.h). The other errors are most likely indicating that you haven't enabled a GOS port. You need to specify the underlying system you're using in the configuration file.

Your content has nothing to do with this forum topic. Please don't spam existing topics.

There's currently no built-in driver for the GT911 touch controller. You'll have to write a GINPUT driver for it. Have a look at the interface documentation and the various existing driver implementations.

Alternatively, you can use the forum search and find this:

I'd like to add some info: This is not a hardware problem but how your uGFX board file(s) are configured. That's the reason why you're getting better performance with a different solution. The LTDC stuff allow for a lot of different configurations - You have to go through everything and figure out what the right ones for your hardware are. Especially check on DMA2D. Also don't forget to set your CPU and compiler in the uGFX configuration file.

There's currently no high-level API for that. I think you'll just have to extend the existing list widget to provide that functionality.

There are plenty of board files available in the /boards directory. You'll also find plenty of examples by google. Furthermore, every driver has a board file template in the driver's directory.