GUIX screen rotation in SDK Example

[Burjak]

Hello, I'm learning how to use Azure GUIX on an example from SDK. 

There is only one example that uses display 720x1280 its OK for me, but I'm looking at how to rotate it. So far I created my own project, changed resolution, and selected rotation clockwise

Generated resource files and included them in the project. Actually, it's not worked as it is. So I tried to follow advice from this thread on renesas forum GUIX rotation - Forum - RZ/A Azure RTOS - RenesasRulz 

1. I changed the call setup function to call rotated_setup

UINT gx_display_driver_imxrt11xx_565rgb_setup(GX_DISPLAY *display)
{
...
//_gx_display_driver_565rgb_setup(display, GX_NULL, imxrt_buffer_toggle);
_gx_display_driver_565rgb_rotated_setup(display, GX_NULL, imxrt_buffer_toggle);
...
}

2. In the file display_support.h I changed next define

#define DEMO_PANEL_WIDTH  (720)
#define DEMO_PANEL_HEIGHT (1280)
...
//#define DEMO_BUFFER_STRIDE_BYTE (DEMO_PANEL_WIDTH  * DEMO_BUFFER_BYTE_PER_PIXEL)
#define DEMO_BUFFER_STRIDE_BYTE (DEMO_PANEL_HEIGHT * DEMO_BUFFER_BYTE_PER_PIXEL)

As result, I got a rotated screen but it occupied only half of screen. 

On the thread, there is another thing I needed to change 

Change 1:

#define DISPLAY_XRES 800
#define DISPLAY_YRES 480

 ↓

#define DISPLAY_XRES 480
#define DISPLAY_YRES 800

I recognized it as the next structure in the same file 

static UINT imxrt_display_layer_initialize(INT layer, GX_CANVAS *canvas)
{
    dc_fb_info_t fbInfo;

    g_dc.ops->getLayerDefaultConfig(&g_dc, 0, &fbInfo);
    fbInfo.pixelFormat = DEMO_BUFFER_PIXEL_FORMAT;
    fbInfo.width       = DEMO_BUFFER_WIDTH;
    fbInfo.height      = DEMO_BUFFER_HEIGHT;
    fbInfo.startX      = DEMO_BUFFER_START_X;
    fbInfo.startY      = DEMO_BUFFER_START_Y;
    fbInfo.strideBytes = DEMO_BUFFER_STRIDE_BYTE;
    g_dc.ops->setLayerConfig(&g_dc, 0, &fbInfo);

But no success for me with playing with this structure. 

What have I missed? 

[Burjak · Accepted solution]

@diego_charles 

My teammate bypassed this problem.

Basically, he returned the GUIX project (in Studio) to the default state, with 1280 width and 720 height without rotation.

I have used offset after rotation, to move down my window. But RT1170 has PXP module, so a better solution is to reset the display resolution to default without rotation, but for rotation use PXP module.

P.S. we moved GUIX to CM4 core, and PXP very much helping with the speed of drawing.

P.P.S. SDK doesn't have azure libs for CM4 (i tried threadx and guix) and it adds to the project port for CM7. So I needed to compile outside and change headers.

[diego_charles]

Hi @Burjak 

Thanks for sharing this information. 

Regards, 

Diego

[diego_charles]

Hi @Burjak 

There is now guix screen rotation macros on gx_api.h

	
/* Define screen rotation types. */	
#define GX_SCREEN_ROTATION_NONE   0	
#define GX_SCREEN_ROTATION_CW    90	
#define GX_SCREEN_ROTATION_CCW  270	
#define GX_SCREEN_ROTATION_FLIP 180

Can you try to take a look?

Diego

[Burjak]

Hello, it's me again. I continue fighting with the screen rotation problem.

This picture is how I visualized in my head what doing GUIX when trying to 

display->gx_display_driver_canvas_copy(canvas, &canvas_frame);

So I dived into GUIX docs again and found offset function: adding that call to buffer_toggle helped me 
_gx_canvas_offset_set(canvas, 0, (1280-720));

static VOID imxrt_buffer_toggle(GX_CANVAS *canvas, GX_RECTANGLE *dirty)
{
    GX_DISPLAY *display = canvas->gx_canvas_display;

    if (canvas == NULL || dirty == NULL)
        return;

    gx_frame_done = false;
    g_dc.ops->setFrameBuffer(&g_dc, 0, (void *)s_frameBuffer);

    while (!gx_frame_done)
    {
    }
    _gx_canvas_dirty_mark(&canvas_frame, dirty);

    _gx_canvas_offset_set(canvas, 0, (1280-720)); //this one is new call

    display->gx_display_driver_canvas_copy(canvas, &canvas_frame);
}

 To resume, here are the steps what I did to rotate screen counter-clockwise:
1. Change properties of display in GUIX studio, from 1280x720 to 720x1280 and enable CCW rotation.
2. Replace _gx_display_driver_565rgb_setup call with _gx_display_driver_565rgb_rotated_setup call
3. Change DEMO_BUFFER_STRIDE_BYTE from 720x2 to 1280x2. 
4. Add _gx_canvas_offset_set(canvas, 0, (1280-720)); to imxrt_buffer_toggle function

Is it actually what I am supposed to do? 

[diego_charles]

Hi @Burjak 

Thank you for  providing further details, I am currently trying  this on my side, checking if this screen rotation is possible.

Diego,

[Burjak]

Well, what happens in my point of view:

I see that s_frameBuffer is low-level where I can directly write information via memset and get France flag. 

memset(s_frameBuffer, 0x0033, DEMO_FB_SIZE/3);
memset(s_frameBuffer+DEMO_FB_SIZE/3, 0x0055, DEMO_FB_SIZE/3);
memset(s_frameBuffer+2*DEMO_FB_SIZE/3, 0x00AA, DEMO_FB_SIZE/3);

From other examples (which use only driver, without guix or other frameworks) I also got the impression like its the last stop where it all works and I don't need to go to any lower levels. 
Another important thing is the next parameter:

fbInfo.strideBytes

 On the Microsoft site I found a nice picture which describes how stride works

So I have a width of display which is 720p (or 720x2 bytes) and stride which is 1280x2 bytes. So in my point of view, it means next:

s_frameBuffer[0] ... s_frameBuffer[720x2] - is first row
s_frameBuffer[720x2+1] ... s_frameBuffer[1280x2] - outbounds
s_frameBuffer[1280x2+1] ... s_frameBuffer[1280x2+720x2] - the second row

It is like basic things, but I still learning. 

So i dumped s_frameBuffer memory after imxrt_buffer_toggle() function ends. I think it's the place where GUIX changed the frame (because I have an animation there, the function is calling every time). I looked at the first two rows. 

First 0x460 bytes filled with 0x3333 - in rgb565 it means blue color. 
Range from 0x460 till 0x640 filled with zeros - it means black color
Range from 0x640 till 0xA00 filled with 0x494A - it means gray color which used in my window.

According to stride of 1280x2 i should have a next row: 
560 pixels of blue color - 240 pixels of black - 480 pixels of gray

That I actually see. And it means the function display->gx_display_driver_canvas_copy(canvas, &canvas_frame); making wrong things or I'm still missing some settings.

Next step is to look into Azure GUIX source code.

[diego_charles]

Hi @Burjak 

I hope that you are doing well!

Yet , I can not tell what you are missing here. What it is the RT device you are using? 

[Burjak]

Hi, im working on MIMXRT1170-EVK evaluation board. And with vertical aspect display, so basically example working perfectly without any exceptions, but I need to rotate it in horizontal aspect.

Still not found solution, this is what I got so far. 
- clockwise and counter-clockwise rotation work different.
Clock-wise looks like this. Color part is left from initialization, its simple memset of random colors 

static UINT imxrt_display_layer_initialize(INT layer, GX_CANVAS *canvas)
{
...
memset(s_frameBuffer, 0x0033, DEMO_FB_SIZE/3);
memset(s_frameBuffer+DEMO_FB_SIZE/3, 0xFF55, DEMO_FB_SIZE/3);
memset(s_frameBuffer+2*DEMO_FB_SIZE/3, 0x00AA, DEMO_FB_SIZE/3);
...
}

And grey+black part is from GUIX things, updated by imxrt_buffer_toggle function. So GUIX don't redraw right part of the screen, and colors left there. 

And counter-clock-wise looks like this, it's different. I also have the color part from the initialization. But black part is bottom of my window

So I used a little trick to make it work:
1. Stride parameter = 1280x2
2. Screen resolution in GUIX Studio changed to 1280x1280
3. s_frameBuffer size changed to 1280x1280x2
4. Moved my window to bottom part

Now CCW rotation shows my window on my screen. But I don't think it should work this way, on this moment I think it's some GUIX bug with rotation. Or I missed something