stephen.thompson@neoventus

I implemented a work around for this, by stopping timers before updating the datetime and then starting the timers again afterward. I also had to ignore the geventEventWait() function until the timer had restarted and then allow it to look for events again. I didn't pinpoint the exact culprit, but at least it is working for now.

Thank you for your help. When I execute on the command line I don't have uGFX running. I have tried writing a script that does 'date -s 2017-10-24' and called it from system() which gives the same lock up. I don't think the date is being set backward because I get an invalid date exception thrown if I try to set it backward. I am using Linux. If changing the date has affected the timing calls, what should I be looking for? I've verified that geventEventWait is timing out and played with the ms timeout parameter. I also tried printing out the gfxSystemTicks() delta between cycles through the gui event loop and the number stays consistent before and after changing the date. Another oddity is if I wait a couple of minutes, then uGFX suddenly sees the event and things go back to normal. Is there something I should be looking for specifically with the sleep and semaphore wait functions in GOS? I'm not really using any of these functions currently.

I'm not sure if this is a uGFX issue or not, but when I do a system("date -s 2017-10-24") call I only get NULL values returned from geventEventWait. If I call this same command "date -s 2017-10-24" from terminal, it updates the datetime with no issue. If I do a system() call with any other command from uGFX, it executes with no issues. Just date updates seem to lock me in to null events. I've also tried stime() and settimeofday() calls, but these lock the events to null as well. If you have any insight, I will really appreciate it. Thank You.

Got it working. It turns out I was doing the geventAttachSource before creating the keyboard widget.

I am running on a Yocto distribution with 3.9 kernel. The hardware is an armv7a Dual CortexA9. The compiler is custom from our hardware vendor. I believe it a Yocto toolchain (/opt/poky/2.1.2/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-). Attached is the config file. I'm not familiar with how to use the debugger. Do you mind pointing me to some documentation on this? Thank you for your help. gfxconf.h

When I add geventAttachSource(&glistener, gwinKeyboardGetEventSource(ghKeyboard), GLISTEN_KEYTRANSITIONS|GLISTEN_KEYUP); to my app, the GUI comes up as a black screen after completing the calibration screen. Otherwise, if I remove the geventAttachSource line, everything works fine and I have a working virtual keyboard, but cannot get any events on GEVENT_KEYBOARD or GEVENT_GWIN_KEYBOARD.

I have been trying ugfx for the first time and have had success in cross compiling for arm, but am seeing run time errors. I am trying to run ugfx on armv7 cortex a9 and followed the instructions for single file inclusion. The error messages at run time are usually "The display pixel format is not RGB" or "segmentation fault". I have also seen "The display is 32 no 16 bits per pixel". I have tried using both GFX_USE_OS_RAW32 and GFX_USE_OS_LINUX, both with GFX_USE_DISP, GDISP_NEED_VALIDATION, and GDISP_NEED_CLIP set to TRUE. With the linux board file I have tried board_framebuffer.h with GDISP_PIXELFORMAT_RGB888 and GDISP_PIXELFORMAT_RGB565 (It should be 565). With the RAW32 setup I tried the ugfx/drivers/gdisp/framebuffer/board_framebuffer.h file and modified the width and height for the correct screen resolution. One thing I wasn't sure of here was the "//TODO: Initialize your frame buffer device here" comment. My framebuffer is /dev/fb0 but I'm not sure how I indicate that here syntactically. I would be very grateful for any help. Thank you.