Configure a WVGA display in Apalis iMX6

[Joao]

Hello.
I have been trying to integrate a WVGA (800x640) display in my environment via the Unif. Interface Display port in Ixora.

Following the guide provided here, by modifying the vidargs u-boot variable to the closest i could find - FusionF07. It kinda works, it flicks a lot as soon as i deploy XServer and any kind of application that runs on top of it.

After some research i found the file: mxc_lcdif.c and there i noticed that the FusionF07 block bus was triggered on falling edge but my display is rising edge, so i modified it to use vsync = 0. I tried creating a separate display there, didn’t go too well, hence I am modifying the FusionF07 to my needs. Additionally, I adjusted all other timings to my display.

Still, after compiling and testing, it doesn’t improve much. Actually, if i put the clock just as my display’s datasheet indicates, it flicks even more.

I even read that VIvante does not like 24bpp very much in this question, switched to 32bpp, no dice.

I think my U-boot and fb is detecting the data i have in the structure. All values match in [ 7.462870] mxc_sdc_fb fb@0: 800x480 h_sync,r,l: 30,210,46 v_sync,l,u: 13,22,10 pixclock=33333000 Hz

My vidargs at the moment is: vidargs= mxc_hdmi.only_cea=0 video=mxcfb0:dev=lcd,FusionF07A,if=RGB24 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off fbmem=32M

I think the error comes from the framebuffer (X and such). Before i deploy X (Console prompt) it looks good. The linux logo at bootup looks nice too. As soon as I use X, it starts flickering.

Did i follow the right steps? What can I do to fix this? Do I need another approach? Any guidance is welcome!

Best regards,

[max.tx]

Hi

There are three settings which give you WVGA resolution:

EDT-WVGA
800x480M@60
FusionF07A

Of them only the FusionF07A has the pixelclk polarity inverted, the other two probably already provide the timings you need.

---

What do you mean by flickering?

Could it be that this is releated to the backlight, e.g. what happens if you change the backlight PWM?

Could the difference between with X started and without X started be that one has most pixels black?
e.g. what happens if you stop X if you overwrite the framebuffer to be black, white or random:

cat /dev/zero > /dev/fb0
...
tr '\000' '\377' < /dev/zero > /dev/fb0
...
cat /dev/urandom > /dev/fb0

---

I even read that VIvante does not like 24bpp very much in this question, switched to 32bpp, no dice.

Note that this is about the framebuffer resolution, i.e. a pixel should be represented by either 2 bytes or 4 bytes in the RAM, not by 3 bytes. I don’t think that your current issue is releated.

Max

[Joao]

Hello Max, thank you for your answer.
I forgot to add some details, i changed the PWM backlight to 10kHz from the default 500kHz, it didnt change much.

EDIT: if i put brightness to 7 - screen goes black. If i put one, goes back to what it was before. Increasing the value gets me less brightness. I assume it works as intended

As of Fusion, you are right, it’s the only one with inverted clock. I modified it to my display’s needs so I’m keeping that, maybe i’ll add a custom later.

By flickering i mean the image starts losing color, unstable. If only X is open (I use --retro --noreset) it gets some noise in the screen, I would describe it like a camera filming a monitor a few years ago. When I open a video with gstreamer, the image moves slightly up, getting a black line on the bottom, it stabilizes sometimes then goes back to that…

I tried your cat commands,

1 - it goes pitch black, it gives an error though cat: write error: No space left on device

EDIT: Vanilla X and this cat command give the exact same output - pitch black

2 - progressively gets white, but i get some black columns in the left side corner of the screen and a thin one on the right (near the right end), i.e. goes (B B B W W W W W W W W W W B W) being B black and W white if i roughly divide the screen. Output - tr: short write

3 - it goes random, but some itermittent black lines on the left side appear (where the black column was on #2) and a small black square at the bottom of the screen. Then again, I get cat error: cat: write error: No space left on device.

EDIT: the itermittent stuff is due to the console being in the background, ignore that.

What could be the cause?
Regards,

[max.tx]

Hi

i changed the PWM backlight to 10kHz from the default 500kHz, it didnt change much.

Note that PWM in the device tree takes a periode, not a frequency. So our default in the device tree is 200Hz. I don’t know what your display needs.

I tried your cat commands

I’m aware that these commands end with an error once all of the framebuffer has been written with ‘black’, ‘white’ or random data.

I’d be more interested if the same ‘flickering’ you see with X is also visible when in console mode.

Max

[Joao]

Hello

My mistake, i instinctively assumed it was a frequency. I’ll check that, but since the backlight works I don’t think the issue comes from there.

The display artifacts only appear as soon as X starts. I think the Xorg changes any display configuration and creates the artifacts. Console mode is all good. If I am not missing something here, U-Boot has the right definitions but X ruins it with the auto detect / configuration. How can I override the X configurations? I’ll try to create a screen section in xorg.conf and see if it solves the issue.

EDIT: I added a configuration file with a screen and let him auto-add the device. It happens the same thing.
Another thing. If I rotate a video playing in X by 90 or 270 deg. it works just fine. It only ‘flickers’ in the horizontal. I suspect on any vivante created artifacts, I just don’t know where to work them out.

[max.tx]

What do you mean with playing a video. Is this whole ticket about playing video on top of a X surface and then you’re not happy with the video appearances?

[Joao]

When i’m playing a video OR with X mounted (as retro so it has some output other than just a black screen) it has a lot of artifacts, such has instability, top of the image sometimes appears in the bottom, wrong colours, etc.
This ticket is about X AND the video artifacts.

I messed with the hardware and i lost some display capabilities. It turns on but it gives only but noise / garbage. I can post here a video of what I mean exactly once i recover from this.

Another point that I should’ve said a long time ago is that we’re trying to adapt a touchRGB565 display to the Unif. Display. I messed with the adapter board and lost the display, so this might be only a hardware problem.

Sorry for all the inconvenience, i’ll make updates when I recover from this and any software related solutions (assuming it is not simply a hardware problem) are welcome (Since console only was working fine I still think there’s a software missconfiguration)

[Joao]

Hello Max,

Here’s my major update:
I found out that I had a faulty flat cable, that’s why i had some hardware issues. Now i’m back to the point i’m trying to get help on.

I got some picture for you. Images are worth more than a thousand words and they explain what I mean way better than I do

[upload|OW+9Qkoq++PtQlni15nf2XD78e0=] - all appears as expected

[upload|VamjO6PtXhXpdc+1yJbYaYjamAA=] - same as booting - all good

[upload|W/6htykJrev5WQfKbS8uo+/AK3Y=] - Tons of artifacts, that’s just an example. Some frames appear better than others. Some don’t even appear (just a white screen) while others are close to acceptable

[upload|VSm5TGJvxXmnh/7P5U2831ImgsI=] - this is what i tried to explain. It should be a black + white dotted screen with the ‘X’ in the middle, but all frames have some kind of artifacts like those (not as bad as the video, this is ‘kinda stable’).

I hope I made the problem clearer for you

Best regards,
João Rodrigues

[max.tx]

Hi Joao

I guess you forget to add the pictures.

Max

[Joao]

I guess i only added them locally. Here you go.
][1]

[max.tx]

Hi Joao

I see what you mean with the poor picture quality, however I don’t know what the reason is.

---

What timings get logged when the framebuffer is configured,?
e.g. after X is started by you execute:

ps ax | grep fb  

Does /etc/xorg.conf in your rootfs match the one from meta-freescale for the Vivante X Driver?

Do you have the possibility to measure with an oscilloscope? Pixelclock / Hsync one of the data signals?

Is your cable long?

Does increasing drive strength help?
http://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/boot/dts/imx6qdl-apalis.dtsi?h=toradex_4.1-2.0.x-imx#n788

What happens if you use our standard LXDE Image and set the following display timings (i.e. you do not use your changed kernel):

vidargs=video=mxcfb0:dev=lcd,EDT-WVGA,if=RGB24 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off fbmem=32M 

vidargs=video=mxcfb0:dev=lcd,FusionF07A,if=RGB24 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off fbmem=32M

Then you use gpicview to display some testpictures fullscreen. I attach some for your convinience.
Also what timings get logged here?

Max

[Joao]

Hello Max,

We must’ve reached the max nr of comments so I need to add another answer.

I performed some of your tests and so far i got the following results

• Xorg.conf is the same as meta-freescale’s
• My cable is a little bit long, if I think the noise would be everywhere if it was from a faulty cable
• DSE did not change anything
• LXDE image with the Fusion settings Desktop looks good, test images look good as well. Different timings from the ones I have in my image but it works just fine

mxc_sdc_fb fb@0: 800x480 h_sync,r,l: 128,40,88 v_sync,l,u: 2,10,33 pixclock=33260000 Hz

The problem narrowed down:

At this point my nemesis is Gstreamer. Desktop, X and even chromium perform just fine (As long as I don’t use X as retro) The autodetect pipeline it constructs it makes the artifacts as seen in the video. In the LXDE image, i used the imxv4l2sink, which is the one he thinks is best: gst-launch-1.0 videotestsrc ! imxv4l2sink Artifacts arise!

The thing that is messing with me is that I installed the imx-test recipe in my image and ran the autorun-vpu.sh which runs a sample video in the screen. This video works just fine! Every time i try to run a video through gstreamer all kinds of artifacts appear. Since this application is not using GStreamer, I assume GStreamer’s sink for vpu is not properly done.

When I get videos working just fine in the display i’ll be done here and move on to the touch part of this display.

Now the questions I present are: This is probably not the right place but…

If you don’t think I skipped a crucial test, do you know a set of gstreamer pipeline tests I could do? Can I get access to the pipeline used by the imx-test vpu video?

Here are 3 images. These tests were performed in LXDE:

• Desktop looking just fine
• Gstreamer imxv4l2sink test ruining everything.
• Gstreamer ximagesink - how it should look like but I want fullscreen.

And another thing. If i flip the video 90 / 270 deg… with the imxv4l2sink It works just fine…

Thank you for your help so far, I’m almost there
Joao

[Joao]

I found a workaround, which makes me satisfied.

The understanding i can take of this is that for some reason gstreamer overflows the display’s pixels.

With the following pipeline, I think i subtract 1 to the horizontal pixel count. It is “fullscreen”, since there’s a tiny column in the right which is not used, barely noticeable.

gst-launch-1.0 filesrc location=bbb_sunflower_1080p_60fps_normal.mp4 typefind=true ! video/quicktime ! aiurdemux ! vpudec frame-drop=false ! queue max-size-buffers=3 ! imxv4l2sink sync=false force-aspect-ratio=false overlay-width=799

For now, I am happy with this result.

Now, onto the touch part.

Thank you for the time you spent assisting this pecular problem.

Kind regards,

João

[max.tx]

Hi

We don’t have documentation of several gstreamer pipelines.

I guess this can help you getting the pipeline used in imx-test. I expect setting the GST_DEBUG GST_DEBUG_DUMP_DOT_DIR environment variables will reveal this.

You could test the available image/video sink optimized for i.MX 6 with

gst-inspect-1.0 | grep imx | grep

And then check what additional properties might make the sink outputting fullscreen with e.g.

gst-inspect-1.0 imxeglvivsink

Which would e.g. give a pipeline like this:

gst-launch-1.0 videotestsrc ! imxeglvivsink fullscreen=true

Personally I would not yet rule out long cables as the cause of all your troubles. I would order shorter FFC cables and try again.
Additonally I would try a video source without a ‘high frequency’ picture, e.g.

gst-launch-1.0 videotestsrc pattern=23 ! imxeglvivsink fullscreen=true

Max