LCD Driver query on TI Sitara EVK

Hi Atul,

Thanks for the reply.After correcting the LCD timing parameters the display works perfectly.However the Win CE 6.0 CETK tests fails.

Apart from the changes in timing parameters the modifications for Screen rotation is also implemented in the code base  as described below

1.Registry change-(“C:\WINCE600\PLATFORM\EVM_OMAP3530\SRC\DRIVERS\DISPLAY\DSS\DSS.reg“)

[HKEY_LOCAL_MACHINE\System\GDI\Drivers]

"Angle"=dword:90

2. “omap_ddgpe.cpp” function - OMAPDDGPE::OMAPDDGPE())

Both DDraw tests and GDI tests fails as attached in the log.Please help me out as what
might be the reasons that cause the test to fail?

0576.DirectDraw_Test.log

 3021.DirectDraw_Performance_Test.log

Thanks,

Jithendran

                //  Default to angle 90      

                m_iGraphicsRotate = DMDO_90;

                g_Globals.m_dwRotationAngle = DMDO_90;

                dwWidth  = m_pDisplayContr->GetLCDHeight();

                dwHeight = m_pDisplayContr->GetLCDWidth();

                break;

Jithendran,

As such the failure seems to be due to a failure in DirectDraw.GetObject.

I conclude this from the DDraw log which reports an error

"### Get global DDraw Object [FILE: ddtestkit_modes.cpp LINE: 62]" and from the test source present at:

C:\WINCE600\PRIVATE\TEST\MULTIMEDIA\DIRECTX\DDRAW\TESTKIT\DDRAWTK

Does the test pass if the default angle is 0? I am guessing that the angle should not matter but that just might rule out this reason.

Also, were you able to get some reason for the failure from the GDI test log? The attachments in your post were for DDraw and DDraw_performance.

regards,

Aparna

Also, another data point to check might be the VRFB enabled/disabled setting and if a change to that, modifies the result of the CETK test.

regards,

Aparna

Hi Aparna,

Thanks for the reply.

CETK tests were run after enabling VRFB based screen rotation  .All the TC’s failed.

The lcd pixel format used is OMAP_DSS_PIXELFORMAT_RGB16

The bit masks are *pAlphaBitMask = 0x00000000;  // *pAlphaBitMask = 0x00000000;

                  *pRBitMask     = 0x00f80000;  // *pRBitMask     = 0x00ff0000;

                  *pGBitMask     = 0x0000fc00;  // *pGBitMask     = 0x0000ff00;

                  *pBBitMask     = 0x000000f8;  // *pBBitMask     = 0x000000ff;

Output format In lcd_vga.c      OUTREG32( &g_pDispRegs->DISPC_CONTROL,

                        DISPC_CONTROL_GPOUT1 |

                        DISPC_CONTROL_GPOUT0 |

                        DISPC_CONTROL_TFTDATALINES_24 |   // DISPC_CONTROL_TFTDATALINES_18

                        DISPC_CONTROL_STNTFT

Can we conclude that the CETK tests always fails with screen rotation enabled?

Please find attached the logs.

Thanks,

Jithendran

2146.vrfb.txt

Jithendran,

I used the "do rotate 90" command on the baseline code to rotate the screen. The GDI and Ddraw tests pass. Is it possible that there is some other window open on the foreground while you are executing this test? If so, could you minimize or close it and try the test again? Typically, the failure that you are seeing now is related to an unexpected window present in the foreground. I can recreate a similar failure if I open the keypad from the desktop and then run the GDI cetk test.

regards,

Aparna

Hi Aparna,

There is no window open on the foreground. We also tested without any screen rotation as described below

(16pixel format and 24 bit output )

  The test suite runs successfully on the sharp LCD that ships with the Mistral EVK.However the test suite fails when the sharp LCD is replaced by 24 bit NEC LCD but the display works perfect(MFC/.NET GUI ).Also attached the log .

Thanks,

Jithendran

2843.log_NEC.txt

Hi Jithendran,

Could you try to set the surface type in your test command-line to reflect the 24-bit format you are using? List of types of surfaces can be found at the msdn link below. Another suggestion would be to turn on manual verification from the command-line (one of the parameters mentioned on the same msdn page) and see how it goes. If these ideas do not help in resolving/debugging the issue, you might want to check with microsoft about this cetk test. Maybe, the test assumes some default setting in the display hardware.

http://msdn.microsoft.com/en-US/library/ee505759%28v=WinEmbedded.60%29.aspx

Regards,

Aparna

Jithendran

To specify 90 degree rotation, you have to set the Angle registry key to 1 and not 90. See the note in dss.reg.

    ; sets initial screen rotation
    ; use 0 for 0 degree, 1 for 90 degree, 2 for 180 degree and 4 for 270 degree
    ; Note: Rotation should not be used with the flat frame buffer, memory/bus bandwidth may
    ; be exceeded by display scanning requirements causing display to flicker and/or lock up.
    "Angle" = dword:0

Please undo the changes in OMAPDDGPE, set the registry correctly and run your tests again. Also, just to be clear in your following quote:

(16pixel format and 24 bit output )

  The test suite runs successfully on the sharp LCD that ships with the Mistral EVK. However the test suite fails when the sharp LCD is replaced by 24 bit NEC LCD but the display works perfect(MFC/.NET GUI )

Does this mean that with rotation angle 0 and your 24 bit NEC LCD, the CETK tests fail or is this with rotation angle 90 and 24 bit NEC LCD?

-Madhvi

The DVI mode supported by the BSP uses the 24bpp format. I could run the GDI tests successfully using 1280x720 display mode and without specifying any display format options in the command-line. Command-line used was tux -o -d ddi_test.dll -c "/OutputBitmaps".

So, we know for sure that there is no issue with the 24bpp mode with the driver or with the CETK test suite.

Regards,

Aparna

A small correction in the command-line in previous response. Test dll would be gdiapi.dll and not ddi_test.dll as mentioned.

regards,

Aparna

Hi Aprana/Madhavi,

Thanks for the help and suggestions.But couldn't resolve the issue .

Please find the various options tried out and the results without any screen rotation consolidated below  below.

Any changes to be done for DISPC_GFX_ATTRIBUTES ?.

Thanks,

Jithendran

------------------------------------------------------------------------

Jithendran

From your experiments, it seems like there is some connection issue between the AM37x and your LCD panel. On our EVM, we have tested case 1 (LCD) and 2 (DVI) and both CETK results and LCD appearance are good. Looking at the case 2 and 4 on your h/w, suggests that if you try case (2) with Pixel Format = RGB16, Output Format = 24, Mask=555, then your LCD would be good but CETK would obviously fail due to wrong mask.

All we can suggest to you is to check the data lines between the DSS out and your LCD panel.

FYI - we don't validate RGB32 pixel format on our setup and are not sure what performance impact it may have.

-Madhvi

Hi Jithendran and Atul,

I have an OMAP3530/WinCE/BSP_A8_01_01.  I am trying to to the same - modifying the driver to support 24-bit LCD - but without success.  I make the same changes as Jithendran did but the color is still all wrong.

I have some questions for both of you.  Why is pixelFmt still DISPC_PIXELFORMAT_RGB16 even though you are using 24-bit?  Should it be DISPC_PIXELFORMAT_RGB32?

I also tried DISPC_PIXELFORMAT_RGB32 but did not get it right either.  Are there more changes I need to do in the display drivers?

I appreciate any help that you can give me.

Thanks,

Luan

Yes you "should" use pixel format RGB32 although RGB16 should work as well (you will just have less bits for each color). Since we don't have the HW, you will have to debug the issue yourself - fill frame buffer with solid colors (red, green, blue one at a time) and probe LCD color lines to check if appropriate ones are changing. 

Atul

Hi Atul,

Thanks a lot for a quick reply.  I am trying to understand a little bit about the display driver so that I can debug the issue.  One thing I don't understand is how it worked for Jithendran when he used RGB16 and the maskings

case OMAP_DSS_PIXELFORMAT_RGB16:

            *pAlphaBitMask = 0xff000000;

            *pRBitMask     = 0x00ff0000;

            *pGBitMask     = 0x0000ff00;

            *pBBitMask     = 0x000000ff;

            bResult        = TRUE;

            break;

I appreciate your insights on this.

Besides using RGB32 instead of RGB16, would you please tell me what else I need to change to work with 24-bit LCD?  Should I set bits per pixel to 24 or 32?  The driver sets it to 32.

Thanks,

Luan

Use pixel format 16 or 32. Pixel format and LCD lines are different concepts - former controls how pixels are organized in framebuffer (more bpp will require more data movement and slower performance). Just because you have 24 bit LCD does not mean you have to use 24 bpp in representing data (really depends upon color range you want). See file lcd_vga.c - for DVI mode it sets up the controller in 24 bit mode but still uses 16 bpp pixel format. Here is what I would recommend:

1. Leave pixel format as 16 bpp

2. Verify timing parameters for your panel and modify code accordingly

3. Just like DVI, setup controller for 24 bit lines

Once you have this configuration working, then you can move to the next step of messing around with pixel format (if desired)

Atul 

Thanks Atul.  I understand the concepts better now.  Just to confirm with you - if I use pixel format as 16 bpp and 24 bit lines, I should be able to use the existing maskings as

case

OMAP_DSS_PIXELFORMAT_RGB16:

*pAlphaBitMask = 0x0000;
*pRBitMask = 0xf800;
*pGBitMask = 0x07e0;
*pBBitMask = 0x001f;
bResult = TRUE;
break;

Thanks,

Luan

yes - this is 5:6:5 format.

Also refer to GFXREPLICATIONENABLE bit in DISPC_GFX_ATTRIBUTES register - if you set it to 1, controller will replicate MSB color bits into lower color lines otherwise they will remain 0 (since you have RGB16). Either way it should be fine but play around with it - if In understand this correctly, setting bit to 1 should give more intense color

Atul 

One more question - when I am using RGB16 with 24-bit lines, would you please tell me which data lines contain the RGB colors if I have GFXREPLICATIONENABLE set to 0?

Thanks,

Luan

Luan,

DSS data lines are left aligned. This means the the upper bits(MSB part ) should be used. When GFXREPLICATIONENABLE is set to 0, the LSB part is filled up with 0s.

RED: DSS_16(LSB) - DSS_23(MSB)

GREEN: DSS_8(LSB) - DSS_15(MSB)

BLUE: DSS_0(LSB) - DSS_7(MSB)

Thanks,

Tao