2018-11-27 01:44 AM
QUESTION - TouchGFX Community repost - Eyal goltzman - July 2016
Hello,
Following Yossi question from today and Martin reference to Soren answer in https://touchgfx.zendesk.com/hc/en-us/community/posts/206708899--orientation-180-degree
We are using LCD without SPI interface, only parallel RGB interface through the LCD-TFT Controller peripheral, so controlling the LCD as describe in your answer to the above link is not an option.
Since our customers have a mechanical issue with the display orientation (the flat cable position) we are trying to address it with SW solution.
As I see it, there is an option to rotate the frame buffer just before calling swapFrameBuffers, what do you think? It could be done? performance issues? Can we do it ourselves? How?
Thanks,
Eyal
ANSWER - TouchGFX Community repost - Soren Pingel Dalsgaard - July 2016
Hi Eyal,
How unfortunate! You could do the rotation manually, but the performance penalty will be very significant, to the extent that only very simple UIs can be realized.
This is due to two things:
I think the right place to do such a rotation would be by overriding HAL::endFrame. Something like this:
void MyHAL::endFrame()
{
dma.flush(); //wait for all dma operations to have completed
rotateFb(getClientFrameBuffer()); //apply rotation on the fb
HAL::endFrame(); //call base impl when rotation is done.}
Apart from this you would need also to invert the coordinates in your touch controller driver.
You can give it a shot, but I am not too optimistic to be honest. Hopefully you could convince your customer to switch to another display that can either be mounted normally or supports scan direction swap.
Solved! Go to Solution.
2019-01-02 06:02 AM
Hi Daniel,
Okay, here it is. It only supports 180 rotation, but you could port it to do all rotations easily if you wanted - You should be able to tell from the code.
So just to summarize - This rotation is done at a significant performance cost. It is an expensive operation since pixels must be swapped on both X and Y axis. It leads to very inefficient RAM accesses.
Mirror.hpp is a custom widget which will just reverse the pixels on both X and Y axis. To use it you must:
- #include it in your view, and add a member of type Mirror to your View class.
- Place it at (0, 0, HAL::DISPLAY_WIDTH, HAL::DISPLAY_HEIGHT) so it covers the full screen area
- Make sure it is on top (make it the last widget you add() to your view)
In addition you need to add the following function to your FrontendApplication.hpp:
// Force redrawing entire screen
virtual void draw(Rect& rect)
{
if (drawCacheEnabled)
{
// Invalidate entire screen instead of requested rect.
Rect r(0, 0, HAL::DISPLAY_WIDTH, HAL::DISPLAY_HEIGHT);
Application::draw(r);
}
else
{
// Use original rect if we are *actually* drawing and not just invalidating.
Application::draw(rect);
}
}
Lastly, you need to revert the X and Y coordinates in your touch controller sampleTouch() function. Something like this (Assuming a 480x272 display):
x = 479-x;
y = 271-y;
If you are on a different resolution you need to also change a constant at the bottom of the Mirror.hpp file!
The Mirror class is assuming 16bpp frame buffer. You can probably figure out how to modify it if you are using 24bpp frame buffer.
Hope this helps!
Best regards,
Martin
2018-12-27 07:01 AM
Hello,
is there already some progress to this topic.
I'm just rewriting an application from emWin to TouchGFX which is using a Stm32f746 Discovery board in portrait orientation.
All mechanics are fixed and the units are already in use with current emWin implementation.
Unfortunately the picture is upside down now with "HAL::getInstance()->setDisplayOrientation(ORIENTATION_PORTRAIT);"
Why does this function not allow 180° and 270° as well, when 90° is already implemented.
Thanks,
Daniel Schramm
2019-01-02 01:39 AM
Hi Daniel,
Back when we designed rotation we did so knowing that for a lot of displays it was possible to configure, at the driver level, a 180 degree rotation. We will be looking into whether or not to support 180 degree rotation, especially since other offers like STEmWin do so and perhaps also 270.
The original post outlines how to perform the rotation in endFrame(). If it is of any interest, i have a Custom Widget (that you add() to your Screen as the last element) that will rotate the framebuffer for you. This is an expensive operation, but it will perform the rotation none the less.
Best regards,
Martin
2019-01-02 05:36 AM
Hello Martin,
I would be very pleased if you can provide the source.
Support for 90, 180 and 270 degree is really useful for the discovery boards since the rotation in the projects is mainly selected depending on the connectors.
I'm currently working on the successor of this project: http://pinguin.sauerland.de/mp3player.html#mp3
The current EmWin implementation is not satisfying but having the screen upside down is also not nice ;)
There is not much animation implemented so rotation in software will be fast enough.
Do you allow to publish your code snippet when I publish the project as open source later?
Thanks,
Daniel
2019-01-02 06:02 AM
Hi Daniel,
Okay, here it is. It only supports 180 rotation, but you could port it to do all rotations easily if you wanted - You should be able to tell from the code.
So just to summarize - This rotation is done at a significant performance cost. It is an expensive operation since pixels must be swapped on both X and Y axis. It leads to very inefficient RAM accesses.
Mirror.hpp is a custom widget which will just reverse the pixels on both X and Y axis. To use it you must:
- #include it in your view, and add a member of type Mirror to your View class.
- Place it at (0, 0, HAL::DISPLAY_WIDTH, HAL::DISPLAY_HEIGHT) so it covers the full screen area
- Make sure it is on top (make it the last widget you add() to your view)
In addition you need to add the following function to your FrontendApplication.hpp:
// Force redrawing entire screen
virtual void draw(Rect& rect)
{
if (drawCacheEnabled)
{
// Invalidate entire screen instead of requested rect.
Rect r(0, 0, HAL::DISPLAY_WIDTH, HAL::DISPLAY_HEIGHT);
Application::draw(r);
}
else
{
// Use original rect if we are *actually* drawing and not just invalidating.
Application::draw(rect);
}
}
Lastly, you need to revert the X and Y coordinates in your touch controller sampleTouch() function. Something like this (Assuming a 480x272 display):
x = 479-x;
y = 271-y;
If you are on a different resolution you need to also change a constant at the bottom of the Mirror.hpp file!
The Mirror class is assuming 16bpp frame buffer. You can probably figure out how to modify it if you are using 24bpp frame buffer.
Hope this helps!
Best regards,
Martin
2019-01-03 12:34 AM
2019-01-03 01:18 AM
Glad it worked for you, Daniel. And thanks!
2019-01-03 01:20 AM
Also, would you mind accepting the post you feel helped as the correct answer? It's a very helpful indicator to other readers. Thanks!
2019-02-18 10:43 AM
Just wanted to chime in as we require this feature also. Any progress on this topic?
2019-02-18 01:14 PM
Hi @Philippe Laramée,
Nothing has been done yet to fully support 180 degree rotation in software.
Just a note: If you're running the STM32L4R9 - The GFXMMU on the L4R9 can flip the display vertically (mirroring top/bottom) by changing the programming order of the LUT (Look up table)