Joel Bodenmann

The FT6x06 driver was contributed by a community member. It's likely that not everything in there is optional. We welcome any kind of contribution to improve the state of community-supplied drivers

What GINPUT driver are you using? This might very well be a driver "problem" (or feature). Can you reproduce the problem when you take you application code and compile it into a native Windows, Linux or MacOS application?

Hello & welcome to the µGFX community! There are various ways of achieving this. For example, you can have a look at the /demos/applications/notepad demo which is a small paint-like application. To draw without handling the touch (mouse) inputs through widgets. Instead, it uses ginputGetMouseStatus() to retrieve the current mouse status. You can use the GTIMER module to implement the screen timeout easily.

Did you manage to get this working?

In that case I'd recommend to adjust whatever GDISP driver you have to handle that adjustment for you. How to do this depends on the GDISP driver model used but the overall idea remains the same: shift each pixel before the display controller gets access to it.

Hi, I'll have to look into this at a later point but the mouse wheel is definitely not supported as of now. You should be able to click on the up and down buttons though. Controlling the list via the keyboard requires linking/setting-up the keyboard keys to the list widget using the GINPUT module.

Hi, Check the return code of gdispImageOpenFile(). It will tell you whether the image was loaded properly. The widget will not display the image if it wasn't loaded properly. In general I'd recommend you making sure that you can display the image using the imagebox widget before attempting to insert it into the list widget as this makes it easier to ensure that there are no underlying problems with the filesystem, image decoders and similar.

Can you elaborate a bit on what you want to achieve? It this offset desired to be global to everything the display displays or just for certain widgets? Also, is this a permanent measure or should this offset change during runtime? If this is just a measure to align the UI of a machine with a display behind a panel I would recommend modifying the GDISP driver directly. This way your application remains unchanged and upgrading to future versions of µGFX will not require any changes.

There's a getting started guide available here: https://wiki.ugfx.io/index.php/Your_First_Compile_-_Windows Keep in mind that µGFX is a library. It expects you to have a working development environment to which the µGFX library can just be added. @br64you can furthermore get free support on this community board or obtain a commercial support package. I'll close this question for off-topic.

Hello & welcome to the µGFX community! The µGFX-Studio is not publicly available.

Hello & welcome to the µGFX community! This is a good way to get started: https://wiki.ugfx.io/index.php/Getting_Started Especially the "Integrate uGFX" section would be of your interest.

Thank you for bringing this to our attention. This is now resolved. This was an artefact from a host migration - everything has been migrated except of the git server. We'll do that in the next few weeks (possibly over the new year's period).

The current µGFX release (v2.9) introduces new types to make the interface more consistent and future proof. However, there's a define named GFX_COMPAT_V2 which makes the "old" types still available. This macro is by default on/enabled (in the main configuration file). Therefore, using the existing micropython port with the latest µGFX release should be a comparably easy task. Other than that: We're happy to help where we can. This forum is always at your disposal We'd certainly like to see an updated/active/maintained micropython port for the µGFX library. Late answer to your initial post: The badge is STM32L4 based.

Hello and welcome to the µGFX community! The EMF2016 badge team used µGFX and created a micropython port for it: https://badge.emfcamp.org/wiki/TiLDA_MK3/ugfx Most likely that port was not maintained after but should certainly be a good starting point. https://community.ugfx.io/topic/521-micropython-name-badge/

There are currently no ready-to-use board files for the STM32F769i discovery in combination with ChibiOS. You'd have to write those board files yourself. ChibiOS itself is supported by µGFX. In fact, the µGFX library started out as a ChibiOS-only extension. We haven't checked out the latest release of ChibiOS but in general very little things change over time. Modifications would need to occur in /src/gos/gos_chibios.[ch]. The error you're receiving originates from /src/gos/gos_chibios.c:15. Most likely you're able to just modify line 14 and things will work but better check the ChibiOS changelog to figure out whether type definitions etc. changed. The µGFX v3 library is currently not available to the public.

Nice to hear from you again! :) Thank you for bringing the broken links to our attention. We'll look into that the following days. µGFX v3 is still in the works. As back then we have no deadline on it. We prefer quality of quantity. µGFX v2 is still active & being maintained of course.

Welcome to the µGFX community & welcome for sharing your workaround, @Matteo Vigni!

Hello & welcome to the µGFX community! The Zephyr port definitely needs a port to v2.9 to cover for the problem you listed (mainly the type updates) and making it therefore future proof for µGFX v3.0. We would greatly appreciate it if you could provide an updated version of the Zephyr port The Zephyr port was provided by the community member @nathan.loretan and I think µGFX 2.7 or 2.8 was the latest release at that point. However, porting to the current v2.9 version should be very easy as not much changed on µGFX's side (see changelogs). The board files are completely independent from the GOS layer. You should be able to use any board file no matter what underlying system you're running µGFX on.

If the memory of the image you're passing is correct then the following two cases seem the most likely: Your GDISP driver / display controller / display module setup has an issue. Perform tests as explained in my previous post to check. There's an issue in the PNG decoder. You can simply test another PNG image to see whether you have the same issue.

Unfortunately nothing comes to mind. Things you can do to proceed: Try to display the same PNG file in an µGFX application you compile as a native desktop application (Windows, Linux, Mac OS...). If that works without any problems there's a good chance that the image you're loading into memory is corrupted at which point you'd need to revisit your USERFS implementation. The PNG decoder is in general known to work although it is not used as often due to large memory requirements for the decompression algorithm. Before all of this it might be worth confirming that your display driver is working correctly. Run some tests (eg. color fills, drawing rectangles, circles & text) to see whether the issue is actually in the image loading/rendering and not somewhere else.

It's a bit difficult to judge based on the image with the angle & blury-ness but it looks like there's an issue in the setup of the display controller scanlines. The ili9341 display controller families are known to have various issues such as mis-matching silicon revisions and suppliers simply shipping a slightly different chip. This usually results in incompatible initialization routines. Check out the GDISP driver file (inside something like /src/drivers/gdisp/ili9341/) and check the initialization routine. Usually the manufacturer and/or supplier of a display module will provide you with minimal sample code. Simply take the initialization routine you get from the sample code and plug it into the GDISP driver. I'd also recommend you to use the forum search - there's plenty of these issues regarding ILIxxxx display controllers around.

Hello & welcome to the µGFX community. Please excuse the inconveniences you experienced. µGFX is very much alive and active. There has simply been an error in the automatic ordering system. All of your orders were received and by now you should have received a manual response to your purchase inquiry. Please do not hesitate to contact us again should you still not have received anything.

I've never heard of anyone writing a µGFX GDISP driver for the NT35510 driver. However, writing a driver is very easy! You can find the corresponding documentation here: https://wiki.ugfx.io/index.php/Display_Driver_Model You can find examples in form of dozens of existing drivers in the µGFX library directory under /drivers/gdisp Furthermore, we're happy to help wherever we can! Just ask if you have any questions.

The imagebox should automatically redraw when necessary. The only thing you have to make sure is that the image remains opened. The imagebox widget will simply clear the area if the assigned image is not opened (i.e. "nothing" will be rendered).

We're happy to help where we can - don't hesitate to ask on the forum. I assume you're referring to the attachment of a few posts above yours? I had no issues downloading it. I've re-attached it to this post. Let me know if the issue persists.ArduinoIDE_ESP32_ILI9341.zip