Joel Bodenmann

Hello Dave and welcome to the community! As @inmarket mentioned the issue is that the window manager doesn't know about your primitive line shape. Therefore, it never knows when to clear and redraw it. Here's an example of a custom rendering function for the container which acts like a background: static void containerDraw_MyBackground(GWidgetObject* gw, void* param) { (void)param; // Clear container area gdispGFillArea(gw->g.display, gw->g.x, gw->g.y, gw->g.width, gw->g.height, gw->pstyle->background); // Draw the elements gdispFillArea(10, 10, 10, 460, silver_studio); gdispFillArea(10, 20, 620, 10, silver_studio); gdispFillArea(30, 10, 10, 460, silver_studio); gdispFillArea(50, 10, 10, 460, silver_studio); } When creating the container, just pass the function pointer to the initialization struct or use gwinSetCustomDraw(): // create container widget: ghContainerPage0 wi.g.show = FALSE; wi.g.x = 0; wi.g.y = 0; wi.g.width = 640; wi.g.height = 480; wi.g.parent = 0; wi.text = "Container"; wi.customDraw = containerDraw_MyBackground; wi.customParam = 0; wi.customStyle = 0; ghContainerPage0 = gwinContainerCreate(0, &wi, 0); And that's it! This way the window manager will always render those primitives in the custom rendering function whenever needed. You can find more information about custom rendering functions here: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routine

May I ask why you change your platform/system all the time? You should be able to use almost any display panel that offers the compatible RGB interface (and works with the electrical specification). Worst case is that you have to create some sort of adapter board. There are literally hundreds to choose from. These are the ones from the same manufacturer as the stock display of the STM32F746G-Discovery board: http://www.rocktech.com.hk/pro.aspx?TypeID=2

@inmarket didn't we encounter some issues with that approach quite a few years ago with some noisier touchscreen controller outputs and decided to "change that"?

Yourread_xyz() function is supposed to return FALSE if the retrieved touch coordinates are invalid. In that case, the GINPUT module won't read the GMouseReadings struct at all and you can simply leave the coordinates and the buttons unchanged. There's not much more to say. I hope that that answers all of your questions. Otherwise, don't hesitate to ask

Hello @timandr, Please excuse the late reply. I'm not sure what happened. It looks like I didn't properly hit the "Submit Reply" button... Did you get everything up and running or do you still have questions?

I'm glad to hear that everything works as expected!

As mentioned in a previous post this definitely seems to be a video mode initialization issue. Stepping through the code might be the most reasonable way to track down & fix this problem. Also, please try, as mentioned, what happens when you call the driver initialization code twice. It would be good to know if this only happens once per startup of the driver or the entire process.

Under which circumstances does the entire keyboard widget get redrawn? That should only happen if visibility and similar things change. If you just press a key on the keyboard (that doesn't change the current layout) it should only redraw that key. Is it possible for you to create a small test-case that allows us to reproduce the problem? That function is supposed to return TRUE if the data in the GMouseReading struct are valid. Otherwise it has to return FALSE. You can have a look at the STMPE811 driver implementation if you'd like to see an example where that function actually can return FALSE under certain circumstances.

The easiest, most flexible & best solution for a use case like this is to write a custom rendering routine. That gives you complete control over how your list gets rendered. There's a guide on that: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routine However, depending on your needs (if the features provided by the list widget are not exactly what you want), you might want to write a custom widget instead: https://wiki.ugfx.io/index.php/Creating_a_widget Don't hesitate to ask when you have any questions. We are happy to help wherever we can.

The distorted image you see on the first startup, is that always exactly the same?

There are two very likely causes to this: You don't have your FPU enabled. The shown demo is a very floating point intensive demo. Your clocks are not setup correctly (eg. your CPU runs way slower than it could/should). That strongly suggests an out-of-memory situation. I'd recommend you to step through the code to figure out why gfileOpen() fails. All in all you might want to ensure that all things you want to do work independently first. Eg: Try to create a project that doesn't do anything but playing your MP3. Once that works, create a project that doesn't do anything but implementing the GUI. Once that works, add all the other stuff (eg. peripherals and what not) and ensure that that works. At the end throw everything together step-by-step so you know exactly where and when something stops working.

We've never heard of such behavior before. I'm not really sure what to tell you... There's nothing obviously wrong in your configuration file. A couple of questions that might help to track down this issue: Is this "new" behavior or did you experience this issue since the first time you used µGFX? Are you getting that behavior only on that specific platform or can you reproduce the same issue running your µGFX application in a Windows / Linux / OS X environment? Are you updating the label/image contents in a loop or does this only happen when the user clicks something? Is it worse when the user is clicking around more? Is the time interval consistent? Is it really just that widget area that gets blacked out or the entire screen / other portions too? Is it a solid black? Does the color change if you use a different widget style (different background color)? Is it possible to reproduce the problem by creating a new, minimal test-case project? Are there other things that stop working during that time? I'm sorry that we can't tell you exactly what the issue is right now. We've never experienced this before.

Information that might be valuable to track down the problem: Does this happen every time you start the program (eg. do you always need to launch it twice)? Does this only happen once after you rebooted and then never again? Do you see any debug message on the terminal? What happens if you call the driver initialization code a second time manually (within the same program)? Anything else that would help to establish a pattern...

Depending on the platform, that might actually be slower. If you have the RAM to spare you might want to consider rendering into a pixmap and then blitting the finished pixmap on the display instead. But again, it depends on the system whether that would actually be faster. For example, on an STM32 using the LTDC that might actually be slower depending on where the pixmap will be located in (eg. if it's in the same memory as the framebuffer then you would slow things down compared to simply drawing multiple times over the same framebuffer).

Hello @paxx and welcome to the µGFX community! We have not been involved into the development of the amazing EMF2016 badge. It's @mbrej who developed the microPython wrapper fro µGFX. We don't have any badges that we could hand out or anything. In fact, we are still waiting for the two that we were promised If somebody (or the entire community) would be interested in developing a similar device, we would definitely be in for the ride. I guess the easiest way to achieve this is to pick a platform supported by microPython (eg. STM32) and build up from there. @mbrej mentioned that he's looking forward pushing the uGFX wrapper upstream to the microPython repository. I'm not sure what the progress on that is - but he's currently definitely very busy.

In that case there is not much you can do other than simply ignoring or turning them off as per the explanation in my previous post. I'm glad to hear that you got it working though! We would love to hear & see more about your project in the User Projects section It's always interesting to see what people build with µGFX.

Thank you very much for your good words, we appreciate it a lot! µGFX has definitely grown far behind of what I ever imagined back when I published it first on the ChibiOS forum as a ChibiOS-only extension. Working together with @inmarket who joined the project later on has been nothing but a real pleasure. Seeing an active community building around the project is one of the main sources of motivations for us. Judging from the screenshot it doesn't compile. You get a lot of errors. Are you sure that the compilation succeeds? One thing to note is that you shouldn't trust the syntax highlighter of IDEs once you start working with uGFX. The build system of uGFX is very complex. We haven't seen a single IDE so far that was able to handle everything correctly. Due to trying to optimize everything as good as possible we rely heavily on pre-processor magic and conditional compilation/linking. Many macros/defines get modified by the pre-processor during compilation - which makes it impossible for the IDE to show you the correct highlighting and error reporting. That was the case at least over a year ago when we first build the support for the STM32F746G-Discovery board. Most certainly ChibiOS will have support for the F7 by now. However, due to the heavy workload we are experiencing at the moment we didn't have time to check ourselves. If you could give it a go that would be nice. Ideally we would add a ChibiOS + µGFX demo for the STM32F746G-Discovery to the example projects download section. When I remember correctly that was possible back with ChibiOS 2.x. I guess it is even a lot easier now where ChibiOS got split up into the OS and the HAL modules. I'd recommend you to check with the people on the ChibiOS forum.

As @inmarket mentioned, using containers is the recommended, easiest & most optimized way of achieving what you want to do. Depending on your use case, this might be interesting too:

Thank you for sharing your experience on getting uGFX working in Kinetis Desing Studio! I am sure other people will appreciate this in the future. Ideally we would write a detailed step-by-step guide for the "Using µGFX with..." section in the wiki.

You are getting that error message because no keyboard driver was linked while GINPUT_NEED_KEYBOARD was set to TRUE. The /boards/base/multiple/Linux-Framebuffer board files don't include a keyboard input driver, neither does /boards/base/multiple/Linux-Framebuffer-Touch. Right now only the Linux board files for SDL (recommended) include the keyboard input drivers. That is due to the fact that SDL provides a common high-level API interface for interfacing keyboards. The Linux framebuffer itself has nothing to do with keyboards and hence doesn't know how to interface them. The most proper solution is writing a generic Linux event input system driver for keyboards, similar (or exactly the same) as the one for the mouse/touchscreen:

Hello @arnonh and welcome to the community! As @chrisjn52 mentioned it would be useful to see some compiler output log and/or screenshots of your setup. There is a step-by-step guide on how to using the µGFX library with ChibiStudio which is Eclipse based. That guide uses the makefile system as well. Did you have a look at that? ---> https://wiki.ugfx.io/index.php/Using_ChibiStudio

This is looking very nice and helpful! Thank you very much for sharing your work! We will have a closer look at this next week. We're sorry for the unexpected delays this week but we got somewhat busy with lots of stuff.

Yes, the GINPUT module has a keyboard input driver. Various drivers can be found in the /drivers directory. You can find a demo for using the GINPUT keyboard interface under /demos/ginput/keyboard. This is somewhat related:

Hello Mano, You can get a single support ticket for the price of (currently) 25 USD. You can access the support system by clicking on "Support" in the top bar on this site. Those single one-time support tickets are there to get any kind of question(s) answered as quickly and as extensively as possible. All questions will be answered within 24 hours guaranteed on week days. If you are interested in more extensive support (for example: writing code, reviewing code, fixing mission critical bugs, adding new features, ...) we offer a per-hour support which you can either purchase as individual hours or blocks (eg. a pack of 10 hours worth of support). Please don't hesitate to contact us directly to get a quote on a support package that fits your needs. The initial response time on any support inquiries is guaranteed to be less than 24 hours on business days. It's needles to say that everything will be handled with the highest priority and as extensively as possible. Support is available through either the support ticket system on this website, e-mail or Skype & Phone calls (scheduled). The technical support is for answering questions and so on as explained above. The license is a commercial license that allows you to use the µGFX library for a commercial application/device/product. µGFX is only free for home, hobby & educational purposes as well as open source projects. You can either purchase a per-device license or an unlimited license which doesn't put any restrictions on the quantity of devices.

If it helps anybody, the display panel of the STM32F746G-Discovery board is a Rocktech RK043FN48H.