DM355EVM X windows

This sounds like double buffering; for instance, if your widget labels are only being written to one of the buffers, but the system keeps ping-ponging between buffers, this may appear as a flickering effect. 

Juan,

The Widgets use double buffering by default to avoid flicker. I tried
disabling it on the labels, but I still get screen flicker when I
update the text every second. I also see a small logo graphic flash on the screen intermittently
while updating.  I saw this logo before when the unit was booting on the screen. I
assume it's a Davinci logo that gets written to the frame buffer on initialization.
There's no other apps running that touch the frame buffers except X when this happens.

The logo you are seeing is very likely the MV logo the kernel loads during boot process; the fact that you are still seeing this from time to time, tells me nothing is overwritting this buffer data, and somehow this buffer is being ping-ponged in from time to time.  Therefore, we could be looking at a multiple buffer problem.  Can you display a solid VGA picture (with or without X-windows) to ensure this is not a video timint issue?

Juan ,  the screen only flickers when we update the widget labels every second. If I display an X windows app and don't update anything, it looks OK. When I displayed a JPG to the screen via jpegdec it didn't seem to flash, if I recall.

So this means the video frame timing is all correct.  It sounds like not all buffers are being touched by widget tool, but somehow (maybe due to an open call) the buffer pointers are bing reset temporarily (which causes logo to show) before widget tool displays the data its supposed to.  To chase this, you can take a bottom up approach (look at the calls being received by driver) or top-down approach (if you have the widget tool source code, you can look at the actual calls it is making to the driver).

Just curious when you say the widgets 'flicker' is this the whole widget flickering or just the appearance of random lines over the area popping in and out for a frame at a time? I just wanted to bring this up to be sure you are actually seeing a frame buffering issue as opposed to a DDR bandwidth saturation issue, somewhat similar to this post, note that the same effect shown in that post can crop up in lower resolutions when the system is loaded (i.e. when moving around widgets perhaps) if the proper precautions with regard to DDR bandwidth management are not handled (i.e. the PBBPR and TC.RDRATE registers).

Bernie, the whole screen flashes monentarily during the update. I see some black, horiz lines etc. I'm updating 4

text labels every second , so it's not too much of a bandwidth load. Here's the kernel video params I'm using

'davincifb:vid0=720x480x16,2500K:vid1=720x480x16,1350K:osd0=720x480x16,1350K:osd1=720x480x16,1350K'

The display itself is already using a lot of bandwidth on the DDR, particularly having both video and OSD windows active, so the actual text update itself may not be much bandwidth but the continual display drawing and the small extra load from the ARM drawing the text could put it over the top, I have seen displays where it flickers when you move something or open a new gui application.

If the horizontal lines you are seeing look something like the screen shot from the post I mentioned previously than you are likely looking at memory bandwidth saturation and may want to try adjusting the PBBPR register (0x20000020) to see if the effect lessens or dissappears entirely.

Thanks, Bernie and Juan. When I get the time, I'll try the changes in the post you linked and see if it clears up our

problem.

 I finally got back to testing the DM355.  I''ve learned that X windows uses the OSD0 frame buffer, so I disabled OSD1 and VID0/1 via fdset -fb /dev/fb/x -xres 0. This cleared up the screen flashing somewhat. I then tried different values for the PBBPR reg via   echo "20000020" >/sys/class/davinci_system/system/reg and found that 10 cleared up the problem.

 My Gtk+ program paints label widgets to the screen once a second. I am using different font sizes and colors. When I use black, the characters come out fairly clear, but any other color ie red, blue, yellow, they blur. I tried not repainting every second, but they still blur compared to the black font. I also tried reducing the OSD0 color depth to 8, which uses 1/2 the memory of the default 16 bit mode, but it didn't  make any difference. I did notice with the reduced color depth that the screen didn't flash, regardless of the PBBPR value. This seems to indicate the character blurring is not related to the bandwidth problem. I tried adjusting the TC.RDRATE value via echo "01C10140" >/sys/class/davinci_system/system/reg for TC1 and  echo "01C10540" >/sys/class/davinci_system/system/reg for TC1, but the system did not echo back anything, so I assume this reg range is not valid. I found the addr in the tms320DM357.pdf

How can I adjust the TC.RDRATE value and see if it clears up the char blurring ?

 Thanks for the help , John

The bandwidth issues are generally unique looking with the horizontal flickering lines, I do not think the bandwidth issue would be related to such blurring of colors on characters. My suspicion would be that the blurring of the colors is more related to the chroma reconstruction after going through the composite output as opposed to a digitally created phenomenon, unfortunately as the DM355 has only one video DAC and is thus only capible of composite output, if this is the issue than the only way to improve it would be to use an external video DAC (or perhaps a better display). It may also be worth posting up a screen shot of the blurring phenomenon here so we can get a better idea of exactly what you are seeing and perhaps offer alternative explanations/solutions.

Bernie, I'm not sure how to capture a screen shot. Do I  do a "cp
/dev/fb/0 file" from the DM355EVM console port ?

I was thinking more along the lines of a digital camera picture of your display, as my presumption is that the distortion is happening on the display hardware end of things as opposed to in the digital frame buffer you would be capturing with a screen shot.

It would still be a good data point to have, if the screen capture differs from the actual display than that would indicate that the problem is in the display mechanism itself as opposed to the display driving software (i.e. X). You may be able to do this with the import command, however I have never tried it on an MVL install, so I am not sure if it is an included capability.

 Damn, why didn't I think of the digital camera :) Here's a jpeg . Looking at the picture, it's not obvious that the black text, ie Frame1, Frame2 etc, are clearer than the colored text, being the colored text jiggles more in real time.

 The import utility isn't installed on the DM355EVM and I couldn't  find the source online to cross compile it.