LCD low quality images

Hello, Liran Ritkop

Are you modifying load-hd-firmware.sh, or that is a new script?

BR

Vladimir

I modified the load-hd-firmware.sh . Also i corrected some fields according to the 800X480 LCD i use:

firmware_loader 2 dm814x_hdvpss.xem3 start
sleep 1
 modprobe vpss sbufaddr=0xBFB00000 mode=dvo2:800x480@60 i2c_mode=1 debug=1
 modprobe ti81xxfb vram=0:16M debug=1
  echo 1:dvo2 > /sys/devices/platform/vpss/graphics0/nodes
 echo 0 > /sys/devices/platform/vpss/display1/enabled
  echo 30000,800/40/88/48,480/13/32/3,1 > /sys/devices/platform/vpss/display1/timings
  echo triplediscrete,rgb888 > /sys/devices/platform/vpss/display1/output
  echo 1 > /sys/devices/platform/vpss/display1/enabled
  fbset -xres 800 -yres 480 -vxres 800 -vyres 480
  fbset -depth 32 -rgba 8/16,8/8,8/0,8/24
  cat /dev/zero > /dev/fb0

I still have the low resolution issue. I find that there is light green pixels in some places in the pictures, and that the PNG pictures i am trying to show are with bad resolution. Also i found a similar post with that issue:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/203612/739929.aspx#739929

I suspect the problem is not in the script, but something in the VPSS / FB configuration, or worse, in the firmware binary.

I use EZSDK 5.04.

Hello, Liran Ritkop

Please, can you try to load some pictures [PNG] with:

# /usr/bin/qtopia/examples/widgets/imageviewer/imageviewer -qws

without any change to the source code/scripts/configurations. Double check that your system is clear from modifications (all defaults).

What is the quality now? On my side the quality is normal.

If it is normal on your side as well, add all desired modification one by one to track the problem.

You can examine that demo code (imageviewer + board's default video configuration), it could be nearly enough for your job to be done.

Sorry, if I don't understand your problem right. Please, write again what is your progress.

BR

Vladimir

Ok, After some progress, and trying to change a lot of configurations of :

/sys/devices/platform/vpss/display1

/sys/devices/platform/ti81xxfb/graphics/fb0

I still get the same result.. I changed modes, timings, orders, outputs, and etc.. But still, The problem is not fixed.

Altough the 'saFbdevDisplay' results are good, there is a problem in the 'changing' between nearby pixels

I try to show gradients of the three colors, and i see that in the blue and green colors there is something wrong.

When there are changes of specific colors, it seems like other bits in the next pixel are different.

Any idea?

This is the R/G/B gradients:

I'm facing the same problem, in a slightly different way. Some gradients also have what it looks like 'stuck' oversaturated pixels, pretty much exactly as you display here.

Have you ever found a way to fix that?

Hello,

I try it with EZSDK 5.05.02

dm814x-evm login: root
root@dm814x-evm:~# /etc/init.d/matrix-gui-e stop
Stopping Matrix GUI application.
root@dm814x-evm:~# /etc/init.d/pvr-init stop
Stopping PVR
root@dm814x-evm:~# echo 0 > /sys/devices/platform/vpss/display1/enabled
root@dm814x-evm:~#   echo 30000,800/40/88/48,480/13/32/3,1 > /sys/devices/platfo
rm/vpss/display1/timings
root@dm814x-evm:~# echo triplediscrete,rgb888 > /sys/devices/platform/vpss/displ
ay1/output
root@dm814x-evm:~# echo 1 > /sys/devices/platform/vpss/display1/enabled
root@dm814x-evm:~# fbset -xres 800 -yres 480 -vxres 800 -vyres 480
root@dm814x-evm:~# fbset -depth 32 -rgba 8/16,8/8,8/0,8/24
root@dm814x-evm:~# cd /usr/share/ti/ti-omx
root@dm814x-evm:/usr/share/ti/ti-omx# ./saFbdevDisplay

Fix Screen Info:
----------------
Line Length - 3200
Physical Address = b0a00000
Buffer Length = 25165824

Var Screen Info:
----------------
Xres - 800
Yres - 480
Xres Virtual - 800
Yres Virtual - 480
Bits Per Pixel - 32
Pixel Clk - 33333
Rotation - 0

I am able to run the demo and the output is correct.

Michael Po what is the software release version that you are using here?

Best Regards,

Margarita

I think we figured out what it is. the pixel clock is inverted (it's in the errata) and theres just enough skew in the signal on some color changes to have the sampling done on the wrong edge of the clock, creating these artifacts.

We're hacking the board to add a transistor to see if that makes the problem disappear.

Pretty amazing than in such a fancy processor with billions of transistor, ONE is missing to allow inverting the pixel clock ;-)

Hello,

I am glad that this issue is solved.

Best Regards,

Margarita