DM8148EVM S-Video output

Any idea why there's a difference in behavior between FB0 and FB1 & FB2?  (Perhaps someone from TI hop in?)

Hi,

FB0 is the default framebuffer. Its used by many opensource applications like Qt, Xserver etc. I think in your case FB_CONSOLE may be opening driver. You can try disabling FB_CONSOLE using make menuconfig.

Hardik,

Are you referring to CONFIG_FRAMEBUFFER_CONSOLE (under Device Drivers --> Graphics Support --> Console Display Driver Support)? 

If so, I don't think that's the culprit, as it's not enabled in the ti8148_evm_defconfig that ships with the EZSDK. Furthermore, I double-checked my modifications to the provided defconfig and I did not enable that configuration item.

Nothing in /proc/*/fd/* indicates usespace processes having it open. I still need to review the DM8148 fb driver code though -- perhaps this is simply by design?

Thank you,

Jon

Hi,

Are you running Qt or some application which uses fb node. Also can you see that fb is really disable once you echo 0 to to the sysfs entry. This is strange we have not seen this type of behavior.

Hardik,

I think I may have caused you some confusion by not providing a clear statement of the issue. Let me try to restate the observation, as originally described by Ashwin. I'm mainly looking to understand at a high level why /dev/fbX nodes behave differently.

• If you open /dev/fb0, write a test pattern, close /dev/fb0, the test pattern remains displayed on the output associated with /dev/fb0. The display data is not changed until another application opens /dev/fb0 and overwrites it.
• If you open /dev/fb2, write a test pattern, and close /dev/fb2, the test pattern disappears immediately when /dev/fb2 is closed.

If I remember correctly, fb1 and fb2 exhibit similar behavior. (Ashwin, could you verify that my description matches your observations as well?)

My configuration is: fb0->HDMI, fb1->LCD, fb2->SD (NTSC). To address your advice, I have verified that no additional applications are using the /dev/fbX nodes while performing the aforementioned tests, and the sysfs entries all seem to be working as expected.

Many thanks,

Jon

Jon,

That is exactly what I'm seeing and in trying to determine why the patterns I wrote to fb1 and fb2 were disappearing, I found that the graphics1/enabled and graphics2/enabled are getting setting to 0 while graphics0/enabled stays at 1.

I loaded vpss with 'debug=1' and looking the debug messages shows the following interesting things after all the initial configuration is done (creating the frame buffer memory and all that) I see a series of "VPSS_GRPX : create grpx0", "VPSS_GRPX : start grpx0", "VPSS_GRPX : stop grpx0" and "VPSS_GRPX : delete GRPX0" all while the system is just booting up. I haven't run my test application yet since I haven't even gotten to a prompt yet.

The final thing that happens before I get to the prompt is the "VPSS_GRPX : create grpx0" and "VPSS_GRPX : start grpx0", there is no STOP or DELETE and thus fb0 is left running.

When I run a test application against fb1 or fb2, I see the same sequence of messages, but I always see the STOP and DELETE messages which stops any further communication.

I'm doing all of my testing with the pre-built images that ship with EZSDK 5.04.00.11 and not building the Kernel with my changes or anything.

So at least as long as my application keeps the various fb's open, things should behave properly which is fine with me, but I (like Jon) am just curious as to why fb0 behaves differently without us having to do anything special with it. 

Hi,

fb0 is by default opened by other Linux drivers like console, so even when you call close for fb0, it is close completely, may be you can check open count to see if it is still opened, buy fb2 and fb3 are opened by any other Kerned drivers except the use application, so when you close, it will get removed from the display.

Thanks,

Brijesh Jadav

Normally fb drivers can be opened by multiple applications. Most of the open source application writes the frame buffer once and it remains filled till you do something interactive to change the frame buffer content. Your application will be starting always after some open source application starts, which will be overwriting the buffer filled by previously open source application. So even if you close your application, open source application is still running and since buffer is over written by your application you are seeing your buffer. In our case we have QT running on our board on fb0. You can try disabling QT and than  you will see the fb0 behaving same as fb1 and fb2. Procedure for disabling QT should be there in EZSDK user guide.

Regards,

Hardik Shah

Hardik and Brijesh,

Thank you for your additional advice and explanations.

I'm not sure about Ashwin's setup, but I don't have the Matrix application being started by the init.d scripts (i.e. no QWS servers are keeping fb0 open). After walking through the fd's for each pid in /proc, I can say with pretty good certainty that after the system starts up, no userspace applications have the /dev/fbX nodes open.

Hardik, are you not able to reproduce this after removing the Matrix startup from the load_hd_firmware.sh?

Thanks,

Jon

Like Jon, I'm not running the Matrix or any other graphical application since I'm creating my own Kernel and Filesystem for my custom application. So I haven't gotten around to including my Qt application in there yet but wanted to test out all the video capture/display facilities of the Kernel before I went down the path of implementing what I need so that I'm not chasing down issues that are real and not ghosts..

Either way, at least I know that there is a difference between the various fb's and can accommodate for them within my application.

~ Ashwin

Hi,

Can you please put small printk in the FBDev driver and check if it is opened?

Thanks,

Brijesh Jadav