Joel Bodenmann

Hello & welcome to the µGFX community! That's not correct, see below. Did you enable the label widget in the configuration file? If that's not the case you're most likely not including all files properly.

Hello & welcome to the µGFX community! Please excuse the late reply. This issue has been fixed now. There seemed to be a caching issue with the SSL cert where the SSL cert did get renewed but not properly cached. Your account has also been activated. Thank you for bringing this to our attention!

Sorry, I do not understand your question.

Glad to hear that you got everything working

Did you have a look at this? https://wiki.ugfx.io/index.php/FreeRTOS Also make sure that you're using the latest master branch.

It seems that you're confusing transparency and alpha-channel. If you're using GIF then that's expected as GIF doesn't support alpha buy only transparency. If you're using PNG you should refer to the documentation: https://wiki.ugfx.io/index.php/Images#Alpha_.26_Transparency

Hi, You just need to use an image format which supports transparency. The existing GIF and PNG image decoders will handle transparency out of the box.

Hello @chrisdf and welcome to the µGFX community! Thank you very much for sharing your experience here. We appreciate it a lot and I'm sure it will help countless people in the future as well! This is definitely interesting.

Nice, glad to hear that you got everything working! We'd appreciate it if you could create a ready-to-run example for the downloads page and maybe some documentation for the wiki. Have a look at /demos/gos. The scheduler is also used for things like GTIMER which in turn is used by GINPUT and GWIN. As mentioned above, /demos/gos should help.

I'd recommend you to have a look at the buffer in the GConsoleObject object (cast from GHandle).

https://wiki.ugfx.io/index.php/Touchscreen_Calibration#Extreme_coordinates What do you mean by "not very responsive"? What's the behavior in a regular GWIN application like?

That's interesting. Could you please leave some detailed information of the compiler you're using and also your build flags? What does that mean? Can you please give some more details?

Have a look at the /demos directory. Especially /demos/tools in your case.

Nice, much appreciated!

Welcome to the µGFX community! Happy to hear that you managed to get things up and running

Hello and welcome to the µGFX community! Unfortunately, there isn't an existing GINPUT driver for that touch screen controller. However, it's very easy to add a new one. Take the existing drivers as an example. You can simply copy the one who matches your controller the best (eg. don't take the ones which use the microcontroller's ADC to determine the touch coordinates) and modify from there. The entire driver interface is well documented in the corresponding GINPUT documentation. Please don't hesitate to ask if you have any questions - we're happy to help wherever we can!

Thank you for bringing this to our attention. I've modified the documentation accordingly.

Thank you for sharing your progress & files with everybody - much appreciated! µGFX can definitely do a lot better than that. µGFX does provide those kind of features as well (in a much bigger scope even). We basically call those "hardware acceleration". There are a number of functions that a GDISP driver can implement to use hardware acceleration. For rectangles that would be the `fill area` function. You can have a look at existing drivers. As you'll see it's simply a matter of turning the hardware support for a feature on in the drivers configuration file and then implementing the corresponding function. Have a look at the ST7735 driver for an example. You can see that GDISP_HARDWARE_FILLS is enabled in the drivers config file (gdisp_lld_conf.h) and that the drivers implementation file (gdisp_lld_ST7735.c) is implementing the corresponding hardware filling function named gdisp_lld_fill_area(). The actual implementation of such a function varies a lot. Some display controller have a simple command which takes X, Y, width, height and color while other drivers rely on using DMA and similar techniques to speed things up.

@David Thomas is correct. You're missing some board support package files. You will find that µGFX also supplies those as part of the board files for the STM32F746 Discovery board files. You can find them under /boards/base/STM32F746-Discovery. Just add the appropriate files that you're missing (most notably the SDRAM ones) and you should be ready to go After all, board files are completely application specific. You're not forced to use what you find in the /boards directory. If you're using another framework you can either use their board files (if they exist already) or create your own. Board files are just there to give the µGFX driver(s) access to the actual hardware. You'll find a board file template in each driver directory (eg. /drivers/gdisp/STM32LTDC in your case) which you can implement however you want using whatever you want.

Hello @cchilumbu and welcome to the µGFX community! This topic is very old and there has been a lot of improvements in all corners of µGFX. Please make sure that you're using the latest master branch from the official git repository. If you keep having problems, please don't hesitate to open a dedicated forum topic to ask your questions. We're happy to help wherever we can

You will definitely get a lot better performance when using FSMC. We strongly recommend that you do so. It's quite "common" that the FSMC can go faster than the slave (the display controller in this case). For this, the FSMC has plenty of timing registers to make sure that everything stays within the interface specs you can review in the display controller's datasheet.

Thank you for bringing this to our attention!

That what's the board field in the GDisplay struct is there for. See https://wiki.ugfx.io/index.php/Multiple_displays#Board_files So what you propose to do is fine, just use the existing g->board integer.

Did you perform a clean compilation? This should definitely work. There's not much that can go wrong.

Yes that's possible. The existing keyboard widget (virtual on-screen keyboard) has an interface that allows to load custom layouts. You can add whatever keys you want in whatever layout you want. Furthermore, you can use custom rendering functions to make it look the way you want - all without touching any of the logic!