Graphics Display Getting Started Guide

From Texas Instruments Wiki
Jump to: navigation, search

TIBanner.png

Running OMAP DRM DSS Examples

The drmclone, drmextended, and modetest examples demonstrates how to create a CRTC (i.e. FB) and display planes (overlays) on the CRTC. Additionally, drmtest demonstrates similar functionality as the previously mentioned demos, along with dynamic plane updates for 2 CRTCs.

Retrieve the omapdrm-tests source

 git clone https://github.com/tomba/omapdrm-tests.git
 cd omapdrm-tests

Run (or example planescale)

./planescale

Graphics Demos from Command Line

The graphics driver and userspace libraries and binaries are distributed along with the SDK.

Graphic demos can also run from command line. In order to do so, exit Weston by pressing Ctrl-Alt-Backspace from the keyboard which connects to the EVM. Then, if the LCD screen stays in "Please wait...", press Ctrl-Alt-F1 to go to the command line on LCD console. After that, the command line can be used from serial console, SSH console, or LCD console.

Please make sure the board is connected to atleast one display before running these demos.

Finding Connector ID

Note: Most of the applications used in the Demos would require the user to pass a connector id. A connector id is a number that is assigned to each of the display devices connected to the system. To get the list of the display devices connected and the corresponding connector id one can use the modetest application (shipped with the file system) as mentioned below:

  target #  modetest

Look for the display device for which the connector ID is required - such as HDMI, LCD etc.

Connectors:
id  encoder status      type    size (mm)   modes   encoders
4   3   connected   unknown 0x0     1   3
  modes:
    name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  1280x800 60 1280 1328 1360 1404 800 804 811 823 flags: nhsync, nvsync; type: preferred, driver
...
16  11  connected   HDMI-A  700x390     31  11
  modes:
    name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  1280x720 60 1280 1390 1430 1650 720 725 730 750 flags: phsync, pvsync; type: preferred, driver

Usually LCD is assigned 4 (800x480), HDMI is assigned 16 (multiple resolutions).

Finding Plane ID

To find the Plane ID, run the modetest command:

  target #  modetest

Look for the section called Planes. (Sample truncated output of the Planes section is given below)

Planes:
id      crtc    fb      CRTC x,y        x,y     gamma size
19      0       0       0,0             0,0     0
 formats: RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24 NV12 YUYV UYVY
 props:
 ...
20      0       0       0,0             0,0     0
 formats: RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24 NV12 YUYV UYVY
 props:
 ...

kmscube

Run kmscube on default display (LCD):

  target # kmscube

Run kmscube on secondary display (HDMI):

  target # kmscube -c <connector-id>
  target # kmscube -c 16 #Usually, the connector id for HDMI is 16.

Run kmscube on all connected displays (LCD & HDMI & FPDLink(optional)):

  target # kmscube -a


kmscube with video

This demo allows a video frame to be applied as a texture onto the surface of the kmscube. The user can invoke the demo by following the syntax below:

  target # viddec3test <path_to_the_file> --kmscube --connector <connector_number>

Run kmscube with video on default display (LCD):

  target # viddec3test <path_to_the_file> --kmscube

Run kmscube with video on secondary display (HDMI):

  target # viddec3test <path_to_the_file> --kmscube --connector 16 #Usually, the connector id for HDMI is 16.


Additionally, to change the field of view of the rotating cube, the user can specify the same on the command line like below:

  target # viddec3test <path_to_the_file> --kmscube --connector <connector_number> --fov <number>


Wayland/Weston

The supported Wayland/Weston version brings in the multiple display support in extended desktop mode and the ability to drag-and-drop windows from one display to the other.

To execute the demos, the graphics driver must be initialized by running start weston, if this has not been done earlier.

  target # /etc/init.d/weston start

To launch weston without using systemd init scripts, do the following:

On all connected displays (LCD, HDMI and FPDLink):

  target # weston --tty=1 --backend=drm-backend.so


By default, the screensaver timeout is configured to 300 seconds.

The user can change the screensaver timeout using a command line option

 --idle-time=<number of seconds>

To disable the screen timeout and to configure weston configured to display on all connectors, use the option with "0" as the input:

 --idle-time=0


The filesystem comes with a preconfigured weston.ini file which will be located in /etc/weston.ini

Running weston clients

There is one icon on the top right hand corner of the weston desktop window which has been configured for

  • weston-terminal

Clicking this icon should launch the applications on the Weston Desktop.

It is possible to add other icons by editing the weston.ini file.

There are several other applications that are included in the default filesystem. To invoke these applications, the user should launch the weston-terminal (top right hand corner of the desktop) and then invoke the client apps as described below from within the terminal window:

       wayland sh # /usr/bin/weston-flower
       wayland sh # /usr/bin/weston-clickdot
       wayland sh # /usr/bin/weston-cliptest
       wayland sh # /usr/bin/weston-dnd
       wayland sh # /usr/bin/weston-editor
       wayland sh # /usr/bin/weston-eventdemo
       wayland sh # /usr/bin/weston-image /usr/share/weston/terminal.png
       wayland sh # /usr/bin/weston-resizor
       wayland sh # /usr/bin/weston-simple-egl
       wayland sh # /usr/bin/weston-simple-shm
       wayland sh # /usr/bin/weston-simple-touch
       wayland sh # /usr/bin/weston-smoke
       wayland sh # /usr/bin/weston-info
       wayland sh # /usr/bin/weston-terminal


Running multimedia with Wayland sink

The GStreamer video sink for Wayland is the waylandsink. To use this video-sink for video playback:

  target # gst-launch-1.0 playbin uri=file://<path-to-file-name> video-sink=waylandsink


Exiting weston

Terminate all Weston clients before exiting Weston. If you have invoked Weston from the serial console, exit Weston by pressing Ctrl-C.

It is also possible to invoke Weston from the native console, exit Weston by using pressing Ctrl-Alt-Backspace.

Using IVI shell feature

The SDK also has support for configuring weston ivi-shell. The default shell that is configured in the SDK is the desktop-shell.

To change the shell to ivi-shell, the user will have to add the following lines into the /etc/weston.ini.

To switch back to the desktop-shell can be done by commenting these lines in the /etc/weston.ini (comments begin with a '#' at the start of line).

[core]
shell=ivi-shell.so

[ivi-shell]
ivi-module=ivi-controller.so
ivi-input-module=ivi-input-controller.so

After the above configuration is completed, we can restart weston by running the following commands

target# /etc/init.d/weston stop
target# /etc/init.d/weston start

NOTE: When weston starts with ivi-shell, the default background is black, this is different from the desktop-shell that brings up a window with background.

With ivi-shell configured for weston, wayland client applications use ivi-application protocol to be managed by a central HMI window management. The wayland-ivi-extension provides ivi-controller.so to manage properties of surfaces/layers/screens and it also provides the ivi-input-controller.so to manage the input focus on a surface.

Applications must support the ivi-application protocol to be managed by the HMI central controller with an unique numeric ID.

Some important references to wayland-ivi-extension can be found at the following links: https://at.projects.genivi.org/wiki/display/WIE/01.+Quick+start https://at.projects.genivi.org/wiki/display/PROJ/Wayland+IVI+Extension+Design


Running weston’s sample client applications with ivi-shell

All the sample client applications in the weston package like weston-simple-egl, weston-simple-shm, weston-flower etc also have support for ivi-shell. The SDK includes the application called layer-add-surfaces which is part of the wayland-ivi-extension. This application allows the user to invoke the various functionalities of the ivi-shell and control the applications.

The following is an example sequence of commands and the corresponding effect on the target.

After launching the weston with the ivi-shell, please run the below sequence of commands:

target# weston-simple-shm &

At this point nothing is displayed on the screen, some additional commands are required.

target# layer_add_surfaces 0 1000 2 &

This command creates a layer with ID 1000 and to add maximum 2 surfaces to this layer on the screen 0 (which is usually the LCD).
At this point, the user can see weston-simple-shm running on LCD. This also prints the numericID (surfaceID) to which client’s surface is mapped as shown below:

 CreateWithDimension: layer ID (1000), Width (1280), Height (800)
 SetVisibility      : layer ID (1000), ILM_TRUE
 layer: 1000 created
 surface                : 10369 created
 SetDestinationRectangle: surface ID (10369), Width (250), Height (250)
 SetSourceRectangle     : surface ID (10369), Width (250), Height (250)
 SetVisibility          : surface ID (10369), ILM_TRUE
 layerAddSurface        : surface ID (10369) is added to layer ID (1000)

Here 10369 is the number to which weston-simple-shm application’s surface is mapped.

User can launch one more client application which allows layer_add_surfaces to add second surface to the layer 1000 as shown below.

target# weston-flower &

User can control the properties of the above surfaces using LayerManagerControl as shown below to set the position, resize, opacity and visibility respectively.

target# LayerManagerControl set surface 10369 position 100 100
target# LayerManagerControl set surface 10369 destination region 150 150 300 300
target# LayerManagerControl set surface 10369 opacity 0.5
target# LayerManagerControl set surface 10369 visibility 1
target# LayerManagerControl  help  

The help option prints all possible control operations with the LayerManagerControl binary, please refer to the available options.

IMG PowerVR Demos

The Processor SDK Linux Automotive filesystem comes packaged with example OpenGLES applications. Both DRM and Wayland based applications are packaged as part of the filesystem.

The examples running on Wayland can be invoked using the below commands.

 target # /usr/bin/SGX/demos/Wayland/OGLES2ChameleonMan
 target # /usr/bin/SGX/demos/Wayland/OGLES2Navigation

The examples running on DRM/KMS can be invoked using the below commands.

 target # /usr/bin/SGX/demos/Raw/OGLES2ChameleonMan
 target # /usr/bin/SGX/demos/Raw/OGLES2Navigation

After you see the output on the display interface, hit q to terminate the application.


Using the PowerVR Tools

Please refer to http://community.imgtec.com/developers/powervr/graphics-sdk/ for additional details on the tools and detailed documentation.

The target file system includes tools such as PVRScope and PVRTrace recorder libraries from Imagination PowerVR SDK to profile and trace SGX activities. In addition, it also includes PVRPerfServerDeveloper toolfor Jacinto6 platform.

PVRTune

PVRPerfServerDeveloper tool can be used along with the PVRTune running on the PC to gather data on the SGX loading and activity threads. You can invoke the tool with the below command:

target # /opt/img-powervr-sdk/PVRHub/PVRPerfServer/PVRPerfServerDeveloper

PVRTrace

The default filesystem contains helper scripts to obtain the PVRTrace of the graphics application. This trace can then be played back on the PC using the PVRTrace Utility.

To start tracing, use the below commands as reference:

target # cp /opt/img-powervr-sdk/PVRHub/Scripts/start_tracing.sh ~/.
target # ./start_tracing.sh <log-filename> <application-to-be-traced>

Example:

target # ./start_tracing.sh westonapp weston-simple-egl

The above command will do the following:

  1. Setup the required environment for the tracing
  2. Create a directory under the current working directory called pvrtrace
  3. Launch the application specified by the user
  4. Start tracing the PVR Interactions and record the same to the log-filename

To end the tracing, user can invoke the Ctrl-C and the trace file path will be displayed.

The trace file can then be transferred to a PC and we can visualize the application using the host side PVRTrace utility. Please refer to the link at the beginning of this section for more details.

Testing DSS WB pipeline

Memory to Memory (M2M)

  1. Identify the WB pipeline M2M device.

    # ls /sys/class/video4linux/
    Video0 video10 video11
    # cat  /sys/class/video4linux/video10/name
    omapwb-m2m
  2. Look at list of formats supported.

    # v4l2-ctl -d /dev/video10 --list-formats
    ioctl: VIDIOC_ENUM_FMT
            Index       : 0
            Type        : Video Capture Multiplanar
            Pixel Format: 'NV12'
            Name        : Y/CbCr 4:2:0
    
            Index       : 1
            Type        : Video Capture Multiplanar
            Pixel Format: 'YUYV'
            Name        : YUYV 4:2:2
    
            Index       : 2
            Type        : Video Capture Multiplanar
            Pixel Format: 'UYVY'
            Name        : UYVY 4:2:2
    
            Index       : 3
            Type        : Video Capture Multiplanar
            Pixel Format: 'XR24'
            Name        : 32-bit BGRX 8-8-8-8
  3. Use v4l2-ctl command to test the input output. Below command converts from NV12 to YUYV using WB pipeline in M2M mode.

    # v4l2-ctl -d /dev/video10 --set-fmt-video-out=width=1920,height=1080,pixelformat=NV12  \
    --stream-from=test/BigBuckBunny_1920_1080_24fps_100frames.nv12 \
    --set-fmt-video=width=1920,height=1080,pixelformat=YUYV \
    --stream-to=out/video_test_file.yuyv --stream-mmap=3 --stream-out-mmap=3 --stream-count=70 --stream-poll

Capture

  1. Identify the WB pipeline capture device.

    # ls /sys/class/video4linux/
    Video0 video10 video11
    # cat  /sys/class/video4linux/video11/name
    omapwb-cap
  2. Look at list of formats supported.

    # v4l2-ctl -d /dev/video11 --list-formats
    ioctl: VIDIOC_ENUM_FMT
            Index       : 0
            Type        : Video Capture Multiplanar
            Pixel Format: 'NV12'
            Name        : Y/CbCr 4:2:0
    
            Index       : 1
            Type        : Video Capture Multiplanar
            Pixel Format: 'YUYV'
            Name        : YUYV 4:2:2
    
            Index       : 2
            Type        : Video Capture Multiplanar
            Pixel Format: 'UYVY'
            Name        : UYVY 4:2:2
    
            Index       : 3
            Type        : Video Capture Multiplanar
            Pixel Format: 'XR24'
            Name        : 32-bit BGRX 8-8-8-8
    
  3. Use v4l2-ctl command to test the input output. Below command converts from NV12 to YUYV using WB pipeline in M2M mode.

    # v4l2-ctl -d /dev/video11 -i 0 --set-fmt-video=pixelformat=NV12 \
    --stream-to=/test/video_test_file.yuv --stream-mmap=6 --stream-count=10 --stream-poll
    Video input set to 0 (CRTC#0 - LCD1: ok)
    <<<<<<<<< 7.84 fps
    <
    # v4l2-ctl -d /dev/video11 -i 1 --set-fmt-video=pixelformat=NV12 --stream-to=/test/video
    _test_file.yuv --stream-mmap=6 --stream-count=10 --stream-poll
    Video input set to 1 (CRTC#1 - DIGIT/TV: ok)
    <<<<<<<<<< 8.65 fps

Running DSS application

DSS applications are omapdrm based. These will demonstrate the clone mode, extended mode, overlay window, z-order and alpha blending features. To demonstrate clone and extended mode, HDMI display must be connected to board. Application requires the supported mode information of connected displays and plane ids. One can get these information by running the modetest application in the filesystem.

  target #  modetest

Running drmclone application

This displays same test pattern on both LCD and HDMI (clone). Overlay window also displayed on LCD. To test clone mode, execute the following command:

  target #  drmclone -l <lcd_w>x<lcd_h> -p <plane_w>x<plane_h>:<x>+<y> -h <hdmi_w>x<hdmi_h>
e.g.: target # drmclone -l 1280x800 -p 320x240:0+0 -h 640x480

We can change position of overlay window by changing x+y values. eg. 240+120 will show @ center

Running drmextended application

This displays different test pattern on LCD and HDMI. Overlay window also displayed on LCD. To test extended mode, execute the following command:

  target # drmextended -l <lcd_w>x<lcd_h> -p <plane_w>x<plane_h>:<x>+<y> -h <hdmi_w>x<hdmi_h>
e.g.: target # drmextended -l 1280x800 -p 320x240:0+0 -h 640x480

Running drmzalpha application

Z-order:

It determines, which overlay window appears on top of the other.

Range: 0 to 3

lowest value for bottom

highest value for top

Alpha Blend:

It determines transparency level of image as a result of both global alpha & pre multiplied alpha value.

Global alpha range: 0 to 255

0 - fully transparent

127 - semi transparent

255 - fully opaque

Pre multipled alpha value: 0 or 1

0 - source is not premultiply with alpha

1 - source is premultiply with alpha

To test drmzalpha, execute the following command:

  target # drmzalpha -s <crtc_w>x<crtc_h> -w <plane1_id>:<z_val>:<glo_alpha>:<pre_mul_alpha> -w <plane2_id>:<z_val>:<glo_alpha>:<pre_mul_alpha>
e.g.: target # drmzalpha -s 1280x800 -w 19:1:255:1 -w 20:2:255:1


Testing with FPDLink Display setup

For information on debugging FPDLink integration, please refer to Debugging FPDLink integration

Current H/W setup

FPDLink display is currently supported with Spectrum Digital FPDLink display part number 703840-0001. This display includes a 1280x800 AUO LCD panel with Goodix touch screen connected over a DS90UB924Q1 deserializer.

To validate FPDLink with the current HW setup, below hardware is required.

  • DRA7xx EVM + 12V supply for the EVM.
  • FPDLink Cable between DRA7xx and FPDLink display
  • 12 V power supply for the FPDLink display if using a J6/J6 Eco/J6 Entry EVM. J6 Plus EVM supplies power to the display over FPDLink. Power supply for display is not required in this case.

The picture below shows the overall setup.

DRA7xx FPDLink AUO SD setup.png

Kernel Config modifications are not necessary as AUO panel support and fpdlink support are built into the kernel.

To test the FPDLink display,

  1. Use the device tree dra7-evm-fpd-auo-g101evn01.0.dtb to boot.
  2. Add omapdrm.num_crtc=2 to the kernel boot arguments. The above device tree will enable both HDMI and FPDlink LCD.
  3. Power on the EVM and the check the modetest output. You should see two connectors now, one for HDMI and another for FPDLink.

Legacy H/W setup

Please note that support for the below FPDLink hardware will be deprecated with the next release. This is due to availability of the single board FPDLink display listed above.

To validate FPDLink with the legacy HW setup, below hardware is required.

  • DRA7xx EVM + 12V supply for the EVM.
  • FPDLink Cable between DRA7xx and De-serilzer board (DS90UB928Q).
  • 5V power supply for De-serializer board.
  • LCD Adapter board (DS90UH928Q) that sits on De-serializer board.
  • LCD Adapter cable which is between LCD panel and the Adapter board.
  • 12V power supply for LCD Adapter board.
  • The actual LCD panel (LG101(10.1in) or AUO (7.1 in))

The picture below shows the overall setup.

DRA7xx FPDLink setup.png

Kernel Config is not necessary as the supported panels and fpdlink are built into the kernel.

To test the FPDLink display,

  1. Use the device tree dra7-evm-fpd-lg.dtb to boot.
  2. Add omapdrm.num_crtc=2 to the kernel boot arguments. The above device tree will enable both HDMI and FPDlink LCD.
  3. Power on the EVM and the check the modetest output. You should see two connectors now, one for HDMI and another for FPDLink.

HW Modifications required

With the Rev B J6 Plus EVM's, a board modification is required to supply the pixel clock to the FPDLink connector. The modification required is shown in the below image.

DRA76x FPDLink Board mod.png