Joel Bodenmann

JoVM, I found an unused KS0108 module in my drawer. However, as you mentioned you are still working on the driver. Can you let us know when you have finished tweaking everything? In the meantime we keep yourselves busy working on the uGFX-Studio and the F7 Discovery board support. ~ Tectu

As I am getting many requests by people asking for a working STM32F7 Discovery project I decided to put mine in a repository so it is available to everybody. You can find the repository here: https://bitbucket.org/Tectu/stm32f7-discovery I just pushed the current state of the project without cleaning up as the demands are really high. Sorry for the mess. Important uGFX itself is not part of the project. You will need to download this separately and adjust the GFXLIB variable in the Makefile accordingly. You can either just use a text editor & Make or you can use the Em::Blocks IDE (Make sure that you actually download Em::Bitz, not Em::Blocks). The project and configuration files for the Em::Bitz IDE are included in the project repository. Please contribute your changes by sending pull requests so everybody can benefit. Please leave all questions, comments, contributions and other feedback below. ~ Tectu

Hello JoVM, I am very sorry for my previous stupid forum post. I was sitting in the waiting hall in the airport and I wanted to look at your drivers before I take off and loose the internet for couple of days. One should not review any code when there are only five minutes left. Please ignore it, your driver obviously uses the other GDISp driver model. We will take a look at this and let you know. ~ Tectu

Hello JoVM, I took a look at your files and things don't seem quite right. In order to use the uGFX library you need to write a GDISP driver. The GDISP driver knows how to talk to the KS0108 controller. The next thing you need is the board file. The board file is what your driver uses to actually talk to the display controller through the microcontroller's peripheral interface. This is what you posted in your first post. Please have a look at some of the existing GDISP drivers. You can find them under /drivers/gdisp/. Furthermore, this article contains a few informations about the different GDISP driver models. Don't hesitate to ask when you have some questions. We are happy to help where we can. Just have a look at the existing drivers first ~ Tectu

Hello Alba800 and welcome to the community! Right now we do not provide high level API for this. However, you are already the second user/customer who requests this feature. It is now on our ToDo list and we try to get it done within the next few weeks. The only thing that would be easy to do right now is to use the image caching feature and re-routing the gdispImageAlloc() function so this uses your external RAM. You can find that function in /src/gdisp/gdisp_image.c:197 Maybe inmarket hat another smart solution ~ Tectu

Hello JoVM and welcome to the community! Thank you for sharing your driver, we will take a look at it as soon as possible. Can you please, just for completeness, also add your drivers config file and the board file template so we can take a look at the whole picture? ~ Tectu

DMA2D done, see viewtopic.php?f=9&t=248 ~ Tectu

We have added built-in support for the DMA2D hardware acceleration unit found in some STM32 devices. DMA2D hardware acceleration support is built-in to the corresponding GDISP driver and it can be enabled or disabled in the drivers configuration file. It is enabled by default. ~ Tectu

DMA2D support will be the first thing we will be working on. ~ Tectu

We added documentation regarding the pixmap feature of the GDISP module which provides dynamic frame buffers: http://wiki.ugfx.org/index.php?title=Pixmaps In case of somebody of you was already using the pixmap feature is is important to note that we adjusted the function calls of the pixmap API slightly to have a consistent API. The new API can be found here: http://api.ugfx.org/master/group___pixmap.html (We just renamed the four functions, nothing else).

We added the corresponding wiki article: http://wiki.ugfx.org/index.php?title=Tabset ~ Tectu

We added a new demo for the tabset widget. The wiki documentation will follow in the next few days but at least there's now a proper demo. The new demo can be found under /demos/modules/widgets/tabset. ~ Tectu

And I am currently in the middle of my final exams. I will have vacation from Wednesday next week on but the plans are that i will focus 100% of my time on the uGFX-Studio so we can get the beta release out ASAP. However, I will definitively have more time if you need any help. ~ Tectu

Our community member jithurbide created a wiki article which is a complete beginners guide / tutorial / step-by-step guide for using ChibiStudio with uGFX. The article shows everything from downloading the required software to executing the software on the hardware. You can find the article here: http://wiki.ugfx.org/index.php?title=Using_ChibiStudio Thank you jithurbide! ~ Tectu

We added the possibility to flip the display horizontally and/or vertically for the SSD1963 driver: https://bitbucket.org/Tectu/ugfx/commit ... 32c2114113 ~ Tectu

We have created a new article about touchscreen calibration and how to store calibration data: http://wiki.ugfx.org/index.php?title=To ... alibration Any feedback is welcomed. ~ Tectu

We're sorry, inmarket and I are currently both very busy. I put your issue on my ToDo list and I will get back to you before Monday. ~ Tectu

Chatting with inmarket it just turned out that we actually have an official demo showing how to rotate, scale and transform a polygon. You can find the demo under /demos/modules/gdisp/polygons/. ~ Tectu

Polygon functions do indeed provide parameters for translation. However, scaling is not implemented. The GMSIC module provides some magic like gmiscMatrixFixed2DApplyScale() which you might (should) be able to apply on the array of points which is being passed to the polygon drawing functions. You can find the API reference of the GMISC module here: http://api.ugfx.org/master/group___g_m_i_s_c.html Note: The GMISC module is not really heavily tested. However, we don't know of any issues so far. ~ Tectu

The pixmap is created using the exact same color format as your display controller. Otherwise you would have to translate each pixel and the main idea behind a frame buffer is that it uses the same parameters as the actual display so you can quickly transfer the frame buffer information to the display using burst writes. ~ Tectu

Perfect! Thank you Sir ~ Tectu

Sorry for the off-topic but can you from now on please use the "Post Reply" button at the bottom of each thread page to reply? Using the "Quote" button will add the previous message to your post and in well structured threads like this one it becomes messy. I removed the quotes from your previous posts. Thank you for your understanding. ~ Tectu

Let us know should you face any problems. Good luck! ~ Tectu

May I ask you why you would not want to directly run a proper X setup on your Pi? Anyway: People have already successfully run uGFX on the Pi. We provide a linux framebuffer driver so you don't need any X. That part should definitely work and set-up quite quickly for you As you have the required memory here is what I would do: I'd create one large pixmap frame buffer that is the size of all your displays. Then when rendering you can write the frame buffer to each display using the gdispGBlitArea() function. The parameters of said function allow you to easily draw just that part of the frame buffer that should go on each individual display. To simplify things you could create your own rendering routine called something like renderPixmap() and it would automatically to through all your displays and split up the frame buffer correctly. ~ Tectu

I'm sorry but I have to clear things up a bit first: Do you need to display one big image across smaller screens or will each screen display a different image? Is each display an exact mirror copy of the other displays or will each display need to be able to display different things? Also, can you tell us about your hardware resources? What system are you using? Do you have sufficient RAM to create a frame buffer for each individual display? ~ Tectu