EBC Exercise 20 The Display SubSystem (DSS)

From eLinux.org
Revision as of 12:57, 2 September 2011 by Yoder (talk | contribs)
Jump to: navigation, search


This is the first of N labs that explore the video system drivers. The labs demonstrate the Linux V4L2 and FBdev drivers as well as basic file I/O, through four small applications: on-screen display (OSD), video recorder, video player, and video loop-thru (video-capture copied to video-display). It's based on the materials used in TI's DaVinci System Integration using Linux Workshop. The workshop is based on the DVEVM. I've converted those materials to the BeagleBoard.

This lab shows three ways to write directly to the framebuffer (/dev/fb0) on the Beagle:

  1. Write a single value to the entire framebuffer
  2. Write the pixel values based on a formula
  3. Read a bmp image and write it

The following labs will show how to bring in live video from a web cam via V4L2 and save it to a file, write video from a file to a video framebuffer (/dev/fb1), and finally move live video from a web cam to the framebuffer. A future lab may show how to process the video on the DSP before displaying it.

This is the first of 4 exercises:

  • Part a: You will build an on-screen display for the your device using the FBDEV
driver – INSPECTION LAB only.
  • Part b: Examines v4L2 video capture via a simple video recorder application – INSPECTION LAB only.
  • Part c: Examines the v4L2 display driver using via a video display application. This application plays back the file captured in lab 07b – INSPECTION LAB only.
  • Part d: You will combine the recorder and player applications into a video loop-thru application using memcpy to transfer data between capture and display drivers.
  • Part e: You will modify lab07d to perform video loop-thru via pointer passing between capture and display drivers. (More efficient)

Part a - OSD Setup

The goal of this part is to build an on_screen display for the Beagle using the FBDEV driver. From a coding perspective, it’s an inspection lab only.

Part a Procedure

  1. Create your own custom picture for the OSD window (using gimp), saving the picture to 32-bit format RGBA.
  2. Inspect video_thread.c and helper functions (inside video_osd.c).
  3. Build, run. Result: see your custom banner displayed on screen (no video yet…).
  • Copy the VideoThru files from here to your Beagle.
  • Change to the directory: VideoThru/lab07a_osd_setup
  • Open the Gimp (open-source) paint program by typing “gimp Rose640x480a.bmp” in the terminal.
  • Edit the file to create a custom banner picture.

This file is 640 (width) by 480 (height). All the code that follows assumes the image is this size. (You may change the size, but you'll also have to change the code.)

  • Paint something for your OSD banner. You can create a simple graphic quickly using just three of the many tools.
    • Before clicking any of the tools, you can choose a color first using the color box.
    • Start with the gradient tool to create a background. Select the tool, then click and drag the mouse over the 640x80 image area.
    • Add text or paint something over the gradient with either of these tools, respectively.

GimpTools.png

  • Save your file and exit Gimp.

SaveasBMP.png

When you are finished, save with File:Save. Then exit Gimp. The file should save as RGBA, that is red, green blue, alpha. Where alpha is the transparency. It DOES matter what you name the file because later, during the building process, this file is specifically copied to the target. This name also makes it easy to remember it’s a 640x80 Bitmap image in 24-bit RGBA.

  • Make sure your file is saved to your lab folder.
  • List the contents of the lab folder
  • Examine two of the video files.

video_osd.c

video_osd.c contains a number of functions for manipulating the on-screen display. These functions are not part of an official package, but were developed for these lab exercises to demonstrate the capabilities of the on-screen display hardware. • video_osd_place(): places a picture on the OSD display. Assumes data is provided in 32-bit ARGB (8-bit attribute transparency, 8-bit red, 8-bit blue 8-bit green per pixel). • video_osd_scroll(): a more complex version of video_osd_place() that will offset the OSD display by x and/or y scroll values. This can be used to scroll a banner or picture horizontally or vertically. • video_osd_circframe(): draws a circular alpha-blended frame around the video output. osd_thread.c The thread function in osd_thread.c is video_thread_fxn() which uses the helper functions from video_osd.c as well as an extension of the DMAI Display module (myDisplay) which supports alpha blending: • calls myDisplay_fbdev_create() to open the OSD window. This window is memory mapped (mmap’ed) into the application space and a handle to the Display object is returned and stored in hOsd. • calls readPictureBmp() to read the custom banner picture (as created in gimp and stored in a 24-bit RGB bitmap file) and store a handle to a buffer object containing the picture into the bannerBuf Buffer handle (which is passed by reference). In addition to reading the 24-bit RGB data from the file, it appends an 8-bit transparency value before each pixel, which in this case is a constant value specified by TRANSP and equal to 0xFF (fully opaque). • Inside the initialization for() loop, all OSD buffers are initialized by placing the bannerBuf picture buffer using video_osd_place(), which places the picture on the OSD window with a y offset of 480 (screen height of 480 minus picture height of 80). • Also inside the initialization for() loop, a call is made to video_osd_circframe() to initialize all OSD buffers with a circular semi-transparent (0x80 is 50% transparency) blue frame (0x0000FF is blue, 0x00FF00 is green, 0xFF0000 is red). • Drops into a while loop (testing on env->quit, which is changed to 1 when ctrl-C is pressed) in which it scrolls the OSD banner by calling myDisplay_fbdev_get to gain access to the next OSD buffer, calling video_osd_scroll to update the scrolling buffer, and calling myDisplay_fbdev_put to display the updated buffer. The application assumes the picture is supplied in a 640 x 80 24-bit RGB (8-8-8) format, which should be the case if you followed the previous gimp instructions.