imx6 android - dithering 24bit graphics on 18bit panel

[mrabe]

Hi,

We have a few problems with dithering in Android.

In our test arrangement, we've connected a 18bit panel via LVDS to an i.mx6 Quad.

Running Android 5.0 on it, a gradient test image shows a lot of chunks (as limited by the 18bit panel) - So It seems like dithering is not working. - But if we enable "Disable HW-Overlay" in the developer settings, everything get's dithered correctly.

Has anyone experienced similar problems, and/or got any idea on how to fix this problem?

Thanks in advance.

[Bio_TICFSL · Accepted solution]

This can be closed

[rogerio_silva]

The issue was escalated to Android R&D team and the solution is not complete yet.

[gary_bisson]

Hi,

Well some customers already received updated hwcomposer libraries from NXP with the fix:

Android ICS -> Lollipop upgrade on IMx6 creates image binding

Regards,

Gary

[rogerio_silva]

Hi Gary,

After that message, customer noticed some issues on image quality. This was reported on our internal ticket.

Would you like to test this preliminary composer library?

Best regards,

Rogerio

[gary_bisson]

Hi Rogerio,

Sure, if you have Marshmallow libraries I'd be happy to try them out.

Regards,

Gary

[rogerio_silva]

Hi Gary,

See attached hwcomposer_fsl.imx6.so file that fixes the issue, please replace device/fsl-proprietary/fsl-hwc/hwcomposer_fsl.imx6.so with attached binary.

Please, let me know about your tests and results.

Best regards,

Rogerio

[mrabe]

Hi Rogerio,

Thank you for the new lib - But If I try to use it with Android 5.0, I get this error:

E/HAL     (  151): load: module=/system/lib/hw/hwcomposer_fsl.imx6.so
E/HAL     (  151): dlopen failed: cannot locate symbol "g2d_getTiling" referenced by "hwcomposer_fsl.imx6.so"...
E/FslHwcomposer(  151): Error! hw_get_module fsl_hwc failed

After some research I've copied the libg2d.so from your android_L5.1.1_2.1.0 BSP, now it seems to work great with 16Bit, but I still get a lot of error messages in logcat

E/        (  152): g2d_open: fail with status -7 
E/FslHwcomposer(  152): hwc_prepare invalid g2d_handle 
I/FslHwcomposer(  152): hwc_set invalid g2d_handle

What am I missing here?

Best regards,
Matthias

[daiane_angolini]

Hi mrabe​, as you're facing some android issues now I'm going to followup from here.

When you say you are testing Android 5.0, what do you mean? How this is different from android_L5.1.1_2.1.0 BSP, for example (besides your customer board changes)

What I understand from your log is that your BSP does not have the 2D enabled somehow, and when updating hwcomposer_fsl.imx6.so it was expecting this lib.

Meanwhile I'm going to talk to the internal Android team to understand what is the expectation on hwcomposer_fsl.imx6.so

[mrabe]

Hi Daiane,

currently we are using Android 5.0 based on your REV L5.0.0_1.0.0 Android BSP.

As far as I can tell, the libg2d.so bundled in there doesn't provide the g2d_getTiling required by the new hwcomposer_fsl.imx6.so lib. After digging around I tried the lib from your android_L5.1.1_2.1.0 BSP with some success. (Sorry for the mix-up)

How can 2D be disabled/enabled in the BSP?

[daiane_angolini]

> How can 2D be disabled/enabled in the BSP?

When the developers mode is enabled, there is a submenu for disabling 2D.

However, I agree with you, I think it's a missing symbol due to mismatch of libraries version. I was not able - so far - to learn what is the assumed baseline version. I'm going to work on this today and as soon as I have an update I let you know.

[gary_bisson]

Hi Rogerio,

I've tested it on Nitrogen6x + Hannstar display.

It works fine with a 16bpp framebuffer but the problem still exists with a 32bpp framebuffer.

Regards,

Gary

[rogerio_silva]

Hi Gary, did you also tested on HDMI 32bpp? Is it ok on HDMI?

[gary_bisson]

No, as I said I only tested LVDS, since not every case is working I didn't even try HDMI.

Gary

[rogerio_silva]

I understand. I'll check it.

[rogerio_silva]

Hi,

I reproduce the problem on i.MX6Qsabresd + android and also on i.MX6Q Auto + Linux from NXP Yocto BSP.

Sending the gradient image to the both layers, background (/dev/fb0) and foreround (/dev/fb1), the image is correctly displayed.

When using a video player to display the png, the image is degraded as shown by the pictures sent by Matthias.

I'm supposing that the problem happens when the picture is displayed using v4l2 output (/dev/video17) and the color format set on v4l2 may be wrong.

I`ll make some tests and post the results here.

[SergioSolis]

Hello Matthias,

I am unable to reproduce the problem since I don't have an 18bit panel, but can you please send me a photo of how it looks?, with and wihtout hardware overlays... if you disable to overlays, does it look good on any circumstance? (photos, videos, general UI, etc).

I would appear that the problem is the pixel clock and you would need to modify the settings to match with the 18bit panel.

[gary_bisson]

Hi SergioSolis​,

Do you have a Hannstar 10" display (the one present on the Sabre SD Platform)? This latter is 18-bit LVDS display and the issue can be reproduced with it.

linux-2.6-imx.git - Freescale i.MX Linux Tree

Also I suggest downloading DisplayTester app and use the gradient test to see the issue.

As a FYI, once the bpp is set to 32, I couldn't reproduce the issue on HDMI display but it is still present on LVDS.

Please advise.

Regards,

Gary

[mrabe]

Hi,

Thanks for the support.

The overall looks are improved by disabling hw overlays. - But our customer noticed that there is a problem with certain types of fonts. However I haven't been able to reproduce this for myself by now.

Here are the pictures you asked for.

"normal operation" with Display configured as RGB666 on an 16Bit Framebuffer.

Here with disabled hw overlay:

Any ideas what might be off?

[SergioSolis]

Hello Matthias,

It appears that the "chunks" are not identical between R G and B. R and B look to be the same and G is a bit more granular. Because of this, an immediate thought is that there is a mismatch in the RGB config somewhere, most likely the FB or the overlay. Something is likely configured for 565 rather than 666, can you check this?

[mrabe]

Hi Sergio,

thanks for the response.

You are correct - Since RGB666 needs 2bit more, than a 16bit Framebuffer can offer, everything falls back to RGB565. But a 16Bit FB get dithered correctly if HW Overlay is disabled. That's why I took those example images for you.

A 24Bit/32Bit Framebuffer, that fits RGB666 doesn't get dithered, neither HW Overlay is enabled nor disabled.

I attached a picture for you, that shows RGB666 with 32Bit Framebuffer (sorry for the image quality, but you can still see the chunks),