NOTICE: The Processors Wiki will End-of-Life on January 15, 2021. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.
Virtual DRM : An User Guide for Developing Usecases
In a setup where A15 is not allowed to access DSS, a working omapdrm driver is not available to display content. Virtual DRM is a driver framework to expose DRM devices to linux userspace in such a setup, therefore enabling linux DRM applications to continue functioning.
Contents
- 1 Introduction
- 2 Guidelines to write an usecase
- 3 Example usecases
- 3.1 Example usecase : Navigation + RVC
- 3.2 Example usecase : Navigation + RVC on one display panel, Multimedia on another
- 3.3 Example usecase : Cluster + Tell-Tales on one display panel, Navigation + RVC on another
- 3.4 Example usecase : Cluster + Tell-Tales + Navigation on one display panel, Multimedia on another
- 4 FAQs
- 4.1 How can I check weston logs?
- 4.2 I have installed Processor_SDK_Vision 3.04.00.00 with VDRM support and EVM boots up. Is weston running already?
- 4.3 I have installed Processor_SDK_Vision 3.04.00.00 with VDRM support and EVM boots up. I looked at the log and the list of active processes, and it looks like weston is running. Why don't I see anything on screen
- 4.4 How can I launch weston manually?
- 4.5 I have installed Processor_SDK_Vision 3.04.00.00 with VDRM support and EVM boots up. But the weston log file indicates weston failed to launch. Why?
- 4.6 I have installed Processor_SDK_Vision 3.04.00.00 with VDRM support and EVM boots up. weston is configured to use vdrm, but the weston log file indicates weston failed to launch. Why?
- 4.7 I can launch weston and see the output using apps.out usecase. But I cannot launch any weston clients. Why?
- 4.8 I have installed Processor_SDK_Vision 3.04.00.00 with VDRM support. But I cannot find the binaries modetest, kmscube or fliptest in the filesystem. Why?
- 4.9 I am able to see weston and wayand-egl based clients. But the output has a lot of tearing. Why?
Introduction[edit]
In vision SDK Linux, DSS is controlled by software running on IPU. As a result, omapdrm needs to be disabled, and linux based DRM applications cease to function properly as there is no DRM device capable of modesetting (displaying content).
Virtual DRM is a driver framework that can create multiple DRM devices capable of modesetting and expose them to user space. Each DRM device can contain multiple DRM connectors, and each connector can be configured to expose a predefined resolution and frame rate. Each DRM connector internally creates a DRM encoder, a DRM plane (primary) and a DRM CRTC, which are needed by DRM APIs to function properly.
Additionally, each DRM device creates a vdrm-controller device which can be opened by linux applications to read the buffers submitted by DRM applications. Vision SDK can run a chain (usecase) with multiple instances of dispDistSrcLink, where each link reads a vdrm-controller device to obtain buffers submitted by a DRM application to a particular CRTC in a virtual DRM device.
Linux applications can continue to call DRM APIs to display a DRM Framebuffer on a DRM CRTC, even when the vision SDK application / chain is not running, or the running chain does not contain the dispDistSrcLink associated with the CRTC.
Guidelines to write an usecase[edit]
Adding virtual DRM devices and CRTCs[edit]
A virtual DRM device with one (or more) CRTCs can be added by adding a DT node in arch/arm/boot/dts/dra7.dtsi
<source lang="c"> vdrm0: vdrm@0 {
compatible = "ti,dra7-vdrm";
vdrm0_crtc0: crtc@0 {
compatible = "ti,dra7-vdrm-crtc";
x-res = <1280>;
y-res = <800>;
refresh = <60>;
supported-formats = <DT_DRM_FORMAT_XRGB8888 DT_DRM_FORMAT_ARGB8888>;
};
vdrm0_crtc1: crtc@1 {
compatible = "ti,dra7-vdrm-crtc";
x-res = <640>;
y-res = <480>;
refresh = <30>;
supported-formats = <DT_DRM_FORMAT_NV12 DT_DRM_FORMAT_YUYV DT_DRM_FORMAT_UYVY>;
};
/* more connectors here ... */
};</source>
To add multiple virtual devices, the above section can be modified as below
<source lang="c"> vdrm0: vdrm@0 {
compatible = "ti,dra7-vdrm";
vdrm0_crtc0: crtc@0 {
compatible = "ti,dra7-vdrm-crtc";
x-res = <1280>;
y-res = <800>;
refresh = <60>;
supported-formats = <DT_DRM_FORMAT_XRGB8888 DT_DRM_FORMAT_ARGB8888>;
};
/* more connectors for vdrm0 here ... */
};
vdrm1: vdrm@1 {
compatible = "ti,dra7-vdrm";
vdrm1_crtc0: crtc@0 {
compatible = "ti,dra7-vdrm-crtc";
x-res = <1280>;
y-res = <800>;
refresh = <60>;
supported-formats = <DT_DRM_FORMAT_XRGB8888 DT_DRM_FORMAT_ARGB8888>;
};
/* more connectors for vdrm1 here ... */
};</source>
Each vdrm device (vdrm0, vdrm1, ...) is exposed to usespace as a /dev/dri/cardX file (/dev/dri/card0, /dev/dri/card1, ...). For each vdrm device, the DRM objects are numbered as follows
crtc0- encoder 23
- connector 24
- crtc 26
- primary plane 25
crtc1- encoder 27
- connector 28
- crtc 30
- primary plane 29
and so on.
Additionally, each vdrm device (vdrm0, vdrm1, ...) creates a corresponding vdrm-controller device file (/dev/vdrm-controller-0, /dev/vdrm-controller-1, ...) to read the buffers in the corresponding dispDistSrcLink.
Defining a vision SDK usecase with dispDistSrc links[edit]
Note In this section, we will use an example chain called chains_dispDistSrc_Display. The user is expected to use this section as a reference and modify any existing chain to suit the requirement
A sub-chain containing one dispDistSrcLink and one displayLink can be added to the chain by modifying the plain-text chain description file chains_dispDistSrc_Display.txt
UseCase: chains_dispDistSrc_Display // Other links described above ... DispDistSrc_src0 -> Display_dst0 DispDistSrc_src1 -> Display_dst1
After that, the vision SDK usecase generation tool can be used to generate the auto-generated source code files for the chain. This step will generate the files chains_dispDistSrc_Display_priv.h and chains_dispDistSrc_Display_priv.c
Finally, each pair of dispDistSrcLink and displayLink in the chain must be configured to recieve buffers from a particular CRTC of one virtual DRM device and display them using a particular pipeline. This can be done by editing the file chains_dispDistSrc_Display.c, adding new configuration code in the function chains_dispDistSrc_Display_SetAppPrms.
As an example, the following code snippet configures DispDistSrc_src0 to recieve buffers from crtc0 on vdrm device vdrm0, and display them using GFX pipeline by configuring Display_dst0.
<source lang="c">Void chains_dispDistSrc_Display_SetAppPrms(chains_dispDistSrc_DisplayObj *pUcObj, Void *appObj) {
/* other links configured above ... */
sprintf((char *)pUcObj->DispDistSrc_src0Prm.vDrmControllerName, "/dev/vdrm-controller-0"); pUcObj->DispDistSrc_src0Prm.vDrmControllerObjectId = 26; pUcObj->DispDistSrc_src0Prm.vDrmControllerObjectType = DISP_DIST_SRC_LINK_DRM_OBJECT_TYPE_CRTC; pUcObj->DispDistSrc_src0Prm.width = 1280; pUcObj->DispDistSrc_src0Prm.height = 800; pUcObj->DispDistSrc_src0Prm.format = SYSTEM_DF_BGRX24_8888;
pUcObj->Display_dst0Prm.rtParams.tarWidth = 1280; pUcObj->Display_dst0Prm.rtParams.tarHeight = 800; pUcObj->Display_dst0Prm.rtParams.posX = 0; pUcObj->Display_dst0Prm.rtParams.posY = 0; pUcObj->Display_dst0Prm.displayId = DISPLAY_LINK_INST_DSS_GFX1;
/* more links configured below ... */
}</source>
Example usecases[edit]
[edit]
Design Considerations[edit]
In this example, we will assume that the setup consists of an LCD capable of handling HD content with 1280x720 resolution at 60 FPS. The LCD is assumed to be driven by VOUT1.
Navigation application is assumed to be a linux application. weston is a wayland server running on linux.
Navigation application is assumed to be a full-screen wayland client occupying one wayland output.
RVC application is assumed to be running on IPU.
It is assumed that the Navigation content spans the entire region of the LCD with the RVC content visible in a 320x200 area in the top-right corner. The RVC content is assumed to have a higher zorder than the Navigation Content.
To achieve the above usecase, the software must be designed to enable the following
- There must be one virtual DRM device in the system
- The virtual DRM device must contain one CRTC that is capable displaying 1280x720 content at 60 FPS
- weston must be running using
/dev/dri/card0 - Navigation application must be running using weston
- Navigation application must configure itself to be full-screen and running on the wl_output corresponding to CRTC0 with ID 26
- A vision SDK usecase must be running with
- a capture -> display sub-chain that uses VID1 to display
- a dispDistSrc -> display sub chain that is configured to read
/dev/vdrm-controller-0, CRTC0 with ID 26 and display using GFX
- displayCtrl must be used to route VID1 and GFX to VOUT1
- displayCtrl must be used to program VID1 and GFX zorders appropriately
Software Setup[edit]
Adding virtual DRM device in arch/arm/boot/dts/dra7.dtsi[edit]
<source lang="c"> vdrm0: vdrm@0 {
compatible = "ti,dra7-vdrm";
vdrm0_crtc0: crtc@0 {
compatible = "ti,dra7-vdrm-crtc";
x-res = <1280>;
y-res = <720>;
refresh = <60>;
supported-formats = <DT_DRM_FORMAT_XRGB8888 DT_DRM_FORMAT_ARGB8888>;
};
};</source>
Defining the chains in chains_dispDistSrc_Display.txt[edit]
UseCase: chains_dispDistSrc_Display // An example sub-chain description representing RVC application // Actual implementation may vary Capture -> Display_cap DispDistSrc_nav -> Display_nav
Configuring the links in chains_dispDistSrc_Display.c[edit]
<source lang="c">Void chains_dispDistSrc_Display_SetAppPrms(chains_dispDistSrc_DisplayObj *pUcObj, Void *appObj) {
/* other links configured above ... */
/* Capture link configured here ... */
pUcObj->Display_capPrm.rtParams.tarWidth = 320; pUcObj->Display_capPrm.rtParams.tarHeight = 200; pUcObj->Display_capPrm.rtParams.posX = (1280 - 320); pUcObj->Display_capPrm.rtParams.posY = 0; pUcObj->Display_capPrm.displayId = DISPLAY_LINK_INST_DSS_VID1;
sprintf((char *)pUcObj->DispDistSrc_navPrm.vDrmControllerName, "/dev/vdrm-controller-0"); pUcObj->DispDistSrc_navPrm.vDrmControllerObjectId = 26; pUcObj->DispDistSrc_navPrm.vDrmControllerObjectType = DISP_DIST_SRC_LINK_DRM_OBJECT_TYPE_CRTC; pUcObj->DispDistSrc_navPrm.width = 1280; pUcObj->DispDistSrc_navPrm.height = 720; pUcObj->DispDistSrc_navPrm.format = SYSTEM_DF_BGRX24_8888;
pUcObj->Display_navPrm.rtParams.tarWidth = 1280; pUcObj->Display_navPrm.rtParams.tarHeight = 720; pUcObj->Display_navPrm.rtParams.posX = 0; pUcObj->Display_navPrm.rtParams.posY = 0; pUcObj->Display_navPrm.displayId = DISPLAY_LINK_INST_DSS_GFX1;
/* displayCtrl configured here ... */
/* more links configured below ... */
}</source>
[edit]
Design Considerations[edit]
In this example, we will assume that the setup consists of two LCDs
- LCD1 is capable of handling HD content with 1280x720 resolution at 60 FPS and is driven by VOUT1
- LCD2 is capable of handling full-HD content with 1920x1080 resolution at 30 FPS and is driven by VOUT2
Navigation application and Multimedia application are assumed to be linux applications. weston is a wayland server running on linux.
Navigation application is assumed to be a full-screen wayland client occupying one wayland output. Multimedia application is assumed to be another full-screen wayland client occupying another wayland output.
RVC application is assumed to be running on IPU.
It is assumed that the Navigation content spans the entire region of LCD1 with the RVC content visible in a 320x200 area in the top-right corner. The RVC content is assumed to have a higher zorder than the Navigation Content.
The Multimedia content is assumed to span the entire region of LCD2.
To achieve the above usecase, the software must be designed to enable the following
- There must be one virtual DRM device in the system
- The virtual DRM device must contain two CRTCs
- CRTC0 must be capable of displaying 1280x720 content at 60 FPS
- CRTC1 must be capable of displaying 1920x1080 content at 30 FPS
- weston must be running using
/dev/dri/card0 - Navigation application must be running using weston
- Navigation application must configure itself to be full-screen and running on the wl_output corresponding to CRTC0 with ID 26
- Multimedia application must be running using weston
- Multimedia application must configure itself to be full-screen and running on the wl_output corresponding to CRTC1 with ID 30
- A vision SDK usecase must be running with
- a capture -> display sub-chain that uses VID1 to display
- a dispDistSrc -> display sub chain that is configured to read
/dev/vdrm-controller-0, CRTC0 with ID 26 and display using GFX - a dispDistSrc -> display sub chain that is configured to read
/dev/vdrm-controller-0, CRTC1 with ID 30 and display using VID2
- displayCtrl must be used to route VID1 and GFX to VOUT1
- displayCtrl must be used to program VID1 and GFX zorders appropriately
- displayCtrl must be used to route VID2 to VOUT2
Software Setup[edit]
Adding virtual DRM device in arch/arm/boot/dts/dra7.dtsi[edit]
<source lang="c"> vdrm0: vdrm@0 {
compatible = "ti,dra7-vdrm";
vdrm0_crtc0: crtc@0 {
compatible = "ti,dra7-vdrm-crtc";
x-res = <1280>;
y-res = <720>;
refresh = <60>;
supported-formats = <DT_DRM_FORMAT_XRGB8888 DT_DRM_FORMAT_ARGB8888>;
};
vdrm0_crtc1: crtc@1 {
compatible = "ti,dra7-vdrm-crtc";
x-res = <1920>;
y-res = <1080>;
refresh = <30>;
supported-formats = <DT_DRM_FORMAT_XRGB8888 DT_DRM_FORMAT_ARGB8888>;
};
};</source>
Defining the chains in chains_dispDistSrc_Display.txt[edit]
UseCase: chains_dispDistSrc_Display // An example sub-chain description representing RVC application // Actual implementation may vary Capture -> Display_cap DispDistSrc_nav -> Display_nav DispDistSrc_mm -> Display_mm
Configuring the links in chains_dispDistSrc_Display.c[edit]
<source lang="c">Void chains_dispDistSrc_Display_SetAppPrms(chains_dispDistSrc_DisplayObj *pUcObj, Void *appObj) {
/* other links configured above ... */
/* Capture link configured here ... */
pUcObj->Display_capPrm.rtParams.tarWidth = 320; pUcObj->Display_capPrm.rtParams.tarHeight = 200; pUcObj->Display_capPrm.rtParams.posX = (1280 - 320); pUcObj->Display_capPrm.rtParams.posY = 0; pUcObj->Display_capPrm.displayId = DISPLAY_LINK_INST_DSS_VID1;
sprintf((char *)pUcObj->DispDistSrc_navPrm.vDrmControllerName, "/dev/vdrm-controller-0"); pUcObj->DispDistSrc_navPrm.vDrmControllerObjectId = 26; pUcObj->DispDistSrc_navPrm.vDrmControllerObjectType = DISP_DIST_SRC_LINK_DRM_OBJECT_TYPE_CRTC; pUcObj->DispDistSrc_navPrm.width = 1280; pUcObj->DispDistSrc_navPrm.height = 720; pUcObj->DispDistSrc_navPrm.format = SYSTEM_DF_BGRX24_8888;
pUcObj->Display_navPrm.rtParams.tarWidth = 1280; pUcObj->Display_navPrm.rtParams.tarHeight = 720; pUcObj->Display_navPrm.rtParams.posX = 0; pUcObj->Display_navPrm.rtParams.posY = 0; pUcObj->Display_navPrm.displayId = DISPLAY_LINK_INST_DSS_GFX1;
sprintf((char *)pUcObj->DispDistSrc_mmPrm.vDrmControllerName, "/dev/vdrm-controller-0"); pUcObj->DispDistSrc_mmPrm.vDrmControllerObjectId = 30; pUcObj->DispDistSrc_mmPrm.vDrmControllerObjectType = DISP_DIST_SRC_LINK_DRM_OBJECT_TYPE_CRTC; pUcObj->DispDistSrc_mmPrm.width = 1920; pUcObj->DispDistSrc_mmPrm.height = 1080; pUcObj->DispDistSrc_mmPrm.format = SYSTEM_DF_BGRX24_8888;
pUcObj->Display_mmPrm.rtParams.tarWidth = 1920; pUcObj->Display_mmPrm.rtParams.tarHeight = 1080; pUcObj->Display_mmPrm.rtParams.posX = 0; pUcObj->Display_mmPrm.rtParams.posY = 0; pUcObj->Display_mmPrm.displayId = DISPLAY_LINK_INST_DSS_VID2;
/* displayCtrl configured here ... */
/* more links configured below ... */
}</source>
[edit]
Design Considerations[edit]
In this example, we will assume that the setup consists of two LCDs
- LCD1 is capable of handling HD content with 1280x720 resolution at 60 FPS and is driven by VOUT1
- LCD2 is capable of handling cluster content with 1920x720 resolution at 60 FPS and is driven by VOUT2
Navigation application and Cluster application are assumed to be linux applications. weston is a wayland server running on linux.
Navigation application is assumed to be a full-screen wayland client occupying one wayland output.
Cluster application is assumed to be a DRM application.
RVC application and Tell-Tales application are assumed to be running on IPU.
It is assumed that the Navigation content spans the entire region of LCD1 with the RVC content visible in a 320x200 area in the top-right corner. The RVC content is assumed to have a higher zorder than the Navigation Content.
The Cluster content is assumed to span the entire region of LCD2 with the Tell-Tales content visible in a 640x120 area, positioned at 640x64 from top-left origin.
To achieve the above usecase, the software must be designed to enable the following
- There must be two virtual DRM devices in the system
- Device0 must contain one CRTC capable of displaying 1280x720 content at 60 FPS
- Device1 must contain one CRTC capable of displaying 1920x720 content at 60 FPS
- weston must be running using
/dev/dri/card0 - Cluster Application must be running using
/dev/dri/card1 - Navigation application must be running using weston
- Navigation application must configure itself to be full-screen and running on the wl_output corresponding to CRTC0 with ID 26
- A vision SDK usecase must be running with
- a capture -> display sub-chain that uses VID1 to display
- a dispDistSrc -> display sub chain that is configured to read
/dev/vdrm-controller-0, CRTC0 with ID 26 and display using GFX - a tell-tale -> display sub-chain that uses VID2 to display
- a dispDistSrc -> display sub chain that is configured to read
/dev/vdrm-controller-1, CRTC0 with ID 26 and display using VID3
- displayCtrl must be used to route VID1 and GFX to VOUT1
- displayCtrl must be used to program VID1 and GFX zorders appropriately
- displayCtrl must be used to route VID2 and VID3 to VOUT2
- displayCtrl must be used to program VID2 and VID3 zorders appropriately
Software Setup[edit]
Adding virtual DRM device in arch/arm/boot/dts/dra7.dtsi[edit]
<source lang="c"> vdrm0: vdrm@0 {
compatible = "ti,dra7-vdrm";
vdrm0_crtc0: crtc@0 {
compatible = "ti,dra7-vdrm-crtc";
x-res = <1280>;
y-res = <720>;
refresh = <60>;
supported-formats = <DT_DRM_FORMAT_XRGB8888 DT_DRM_FORMAT_ARGB8888>;
};
};
vdrm1: vdrm@1 {
vdrm1_crtc0: crtc@0 {
compatible = "ti,dra7-vdrm-crtc";
x-res = <1920>;
y-res = <720>;
refresh = <60>;
supported-formats = <DT_DRM_FORMAT_XRGB8888 DT_DRM_FORMAT_ARGB8888>;
};
};</source>
Defining the chains in chains_dispDistSrc_Display.txt[edit]
UseCase: chains_dispDistSrc_Display // An example sub-chain description representing RVC application // Actual implementation may vary Capture -> Display_cap // An example sub-chain description representing Tell-Tale application // Actual implementation may vary TellTale -> Display_tt DispDistSrc_nav -> Display_nav DispDistSrc_cluster -> Display_cluster
Configuring the links in chains_dispDistSrc_Display.c[edit]
<source lang="c">Void chains_dispDistSrc_Display_SetAppPrms(chains_dispDistSrc_DisplayObj *pUcObj, Void *appObj) {
/* other links configured above ... */
/* Capture link configured here ... */
/* TellTale link configured here ... */
pUcObj->Display_capPrm.rtParams.tarWidth = 320; pUcObj->Display_capPrm.rtParams.tarHeight = 200; pUcObj->Display_capPrm.rtParams.posX = (1280 - 320); pUcObj->Display_capPrm.rtParams.posY = 0; pUcObj->Display_capPrm.displayId = DISPLAY_LINK_INST_DSS_VID1;
pUcObj->Display_ttPrm.rtParams.tarWidth = 640; pUcObj->Display_ttPrm.rtParams.tarHeight = 120; pUcObj->Display_ttPrm.rtParams.posX = 640; pUcObj->Display_ttPrm.rtParams.posY = 64; pUcObj->Display_ttPrm.displayId = DISPLAY_LINK_INST_DSS_VID2;
sprintf((char *)pUcObj->DispDistSrc_navPrm.vDrmControllerName, "/dev/vdrm-controller-0"); pUcObj->DispDistSrc_navPrm.vDrmControllerObjectId = 26; pUcObj->DispDistSrc_navPrm.vDrmControllerObjectType = DISP_DIST_SRC_LINK_DRM_OBJECT_TYPE_CRTC; pUcObj->DispDistSrc_navPrm.width = 1280; pUcObj->DispDistSrc_navPrm.height = 720; pUcObj->DispDistSrc_navPrm.format = SYSTEM_DF_BGRX24_8888;
pUcObj->Display_navPrm.rtParams.tarWidth = 1280; pUcObj->Display_navPrm.rtParams.tarHeight = 720; pUcObj->Display_navPrm.rtParams.posX = 0; pUcObj->Display_navPrm.rtParams.posY = 0; pUcObj->Display_navPrm.displayId = DISPLAY_LINK_INST_DSS_GFX1;
sprintf((char *)pUcObj->DispDistSrc_clusterPrm.vDrmControllerName, "/dev/vdrm-controller-1"); pUcObj->DispDistSrc_clusterPrm.vDrmControllerObjectId = 26; pUcObj->DispDistSrc_clusterPrm.vDrmControllerObjectType = DISP_DIST_SRC_LINK_DRM_OBJECT_TYPE_CRTC; pUcObj->DispDistSrc_clusterPrm.width = 1920; pUcObj->DispDistSrc_clusterPrm.height = 720; pUcObj->DispDistSrc_clusterPrm.format = SYSTEM_DF_BGRX24_8888;
pUcObj->Display_clusterPrm.rtParams.tarWidth = 1920; pUcObj->Display_clusterPrm.rtParams.tarHeight = 720; pUcObj->Display_clusterPrm.rtParams.posX = 0; pUcObj->Display_clusterPrm.rtParams.posY = 0; pUcObj->Display_clusterPrm.displayId = DISPLAY_LINK_INST_DSS_VID3;
/* displayCtrl configured here ... */
/* more links configured below ... */
}</source>
[edit]
Design Considerations[edit]
In this example, we will assume that the setup consists of two LCDs
- LCD1 is capable of handling cluster content with 1920x720 resolution at 60 FPS and is driven by VOUT1
- LCD2 is capable of handling full HD content with 1920x1080 resolution at 30 FPS and is driven by VOUT2
Navigation application, Cluster application and Multimedia application are assumed to be linux applications. weston is a wayland server running on linux.
Navigation application is assumed to be a full-screen wayland client occupying one wayland output.
Multimedia application is assumed to be another full-screen wayland client occupying one wayland output.
Cluster application is assumed to be a DRM application.
Tell-Tales application is assumed to be running on IPU.
It is assumed that the Cluster content spans the entire region of LCD1. The Tell-Tales content is placed in LCD1 and covers a 640x120 area, positioned at 640x64 from top-left origin. from top-left origin. The Navigation content is assumed to occupy a 640x360 area in LCD1, positioned centrally.
The Tell-Tales content is assumed to have a higher zorder than the Cluster content. The Navigation content is assumed to have a higher zorder than the Tell-Tales content.
The Multimedia content is assumed to span the entire region of LCD2.
To achieve the above usecase, the software must be designed to enable the following
- There must be two virtual DRM devices in the system
- Device0 must contain two CRTCs
- CRTC0 capable of displaying 640x360 content at 60 FPS
- CRTC1 capable of displaying 1920x1080 content at 30 FPS
- Device1 must contain one CRTC capable of displaying 1920x720 content at 60 FPS
- Device0 must contain two CRTCs
- weston must be running using
/dev/dri/card0 - Cluster Application must be running using
/dev/dri/card1 - Navigation application must be running using weston
- Navigation application must configure itself to be full-screen and running on the wl_output corresponding to CRTC0 with ID 26
- Multimedia application must be running using weston
- Multimedia application must configure itself to be full-screen and running on the wl_output corresponding to CRTC1 with ID 30
- A vision SDK usecase must be running with
- a tell-tale -> display sub-chain that uses VID1 to display
- a dispDistSrc -> display sub chain that is configured to read
/dev/vdrm-controller-0, CRTC0 with ID 26 and display using GFX - a dispDistSrc -> display sub chain that is configured to read
/dev/vdrm-controller-0, CRTC1 with ID 30 and display using VID2 - a dispDistSrc -> display sub chain that is configured to read
/dev/vdrm-controller-1, CRTC0 with ID 26 and display using VID3
- displayCtrl must be used to route VID1, GFX and VID3 to VOUT1
- displayCtrl must be used to program VID1, GFX and VID3 zorders appropriately
- displayCtrl must be used to route VID2 to VOUT2
Software Setup[edit]
Adding virtual DRM device in arch/arm/boot/dts/dra7.dtsi[edit]
<source lang="c"> vdrm0: vdrm@0 {
compatible = "ti,dra7-vdrm";
vdrm0_crtc0: crtc@0 {
compatible = "ti,dra7-vdrm-crtc";
x-res = <640>;
y-res = <360>;
refresh = <60>;
supported-formats = <DT_DRM_FORMAT_XRGB8888 DT_DRM_FORMAT_ARGB8888>;
};
vdrm0_crtc1: crtc@1 {
compatible = "ti,dra7-vdrm-crtc";
x-res = <1920>;
y-res = <1080>;
refresh = <30>;
supported-formats = <DT_DRM_FORMAT_XRGB8888 DT_DRM_FORMAT_ARGB8888>;
};
};
vdrm1: vdrm@1 {
vdrm1_crtc0: crtc@0 {
compatible = "ti,dra7-vdrm-crtc";
x-res = <1920>;
y-res = <720>;
refresh = <60>;
supported-formats = <DT_DRM_FORMAT_XRGB8888 DT_DRM_FORMAT_ARGB8888>;
};
};</source>
Defining the chains in chains_dispDistSrc_Display.txt[edit]
UseCase: chains_dispDistSrc_Display // An example sub-chain description representing Tell-Tale application // Actual implementation may vary TellTale -> Display_tt DispDistSrc_nav -> Display_nav DispDistSrc_cluster -> Display_cluster DispDistSrc_mm -> Display_mm
Configuring the links in chains_dispDistSrc_Display.c[edit]
<source lang="c">Void chains_dispDistSrc_Display_SetAppPrms(chains_dispDistSrc_DisplayObj *pUcObj, Void *appObj) {
/* other links configured above ... */
/* TellTale link configured here ... */
pUcObj->Display_ttPrm.rtParams.tarWidth = 640; pUcObj->Display_ttPrm.rtParams.tarHeight = 120; pUcObj->Display_ttPrm.rtParams.posX = 640; pUcObj->Display_ttPrm.rtParams.posY = 64; pUcObj->Display_ttPrm.displayId = DISPLAY_LINK_INST_DSS_VID1;
sprintf((char *)pUcObj->DispDistSrc_navPrm.vDrmControllerName, "/dev/vdrm-controller-0"); pUcObj->DispDistSrc_navPrm.vDrmControllerObjectId = 26; pUcObj->DispDistSrc_navPrm.vDrmControllerObjectType = DISP_DIST_SRC_LINK_DRM_OBJECT_TYPE_CRTC; pUcObj->DispDistSrc_navPrm.width = 640; pUcObj->DispDistSrc_navPrm.height = 360; pUcObj->DispDistSrc_navPrm.format = SYSTEM_DF_BGRX24_8888;
pUcObj->Display_navPrm.rtParams.tarWidth = 640; pUcObj->Display_navPrm.rtParams.tarHeight = 360; pUcObj->Display_navPrm.rtParams.posX = (1920 - 640) / 2; pUcObj->Display_navPrm.rtParams.posY = (720 - 360) / 2; pUcObj->Display_navPrm.displayId = DISPLAY_LINK_INST_DSS_GFX1;
sprintf((char *)pUcObj->DispDistSrc_clusterPrm.vDrmControllerName, "/dev/vdrm-controller-1"); pUcObj->DispDistSrc_clusterPrm.vDrmControllerObjectId = 26; pUcObj->DispDistSrc_clusterPrm.vDrmControllerObjectType = DISP_DIST_SRC_LINK_DRM_OBJECT_TYPE_CRTC; pUcObj->DispDistSrc_clusterPrm.width = 1920; pUcObj->DispDistSrc_clusterPrm.height = 720; pUcObj->DispDistSrc_clusterPrm.format = SYSTEM_DF_BGRX24_8888;
pUcObj->Display_clusterPrm.rtParams.tarWidth = 1920; pUcObj->Display_clusterPrm.rtParams.tarHeight = 720; pUcObj->Display_clusterPrm.rtParams.posX = 0; pUcObj->Display_clusterPrm.rtParams.posY = 0; pUcObj->Display_clusterPrm.displayId = DISPLAY_LINK_INST_DSS_VID3;
sprintf((char *)pUcObj->DispDistSrc_mmPrm.vDrmControllerName, "/dev/vdrm-controller-0"); pUcObj->DispDistSrc_mmPrm.vDrmControllerObjectId = 30; pUcObj->DispDistSrc_mmPrm.vDrmControllerObjectType = DISP_DIST_SRC_LINK_DRM_OBJECT_TYPE_CRTC; pUcObj->DispDistSrc_mmPrm.width = 1920; pUcObj->DispDistSrc_mmPrm.height = 1080; pUcObj->DispDistSrc_mmPrm.format = SYSTEM_DF_BGRX24_8888;
pUcObj->Display_mmPrm.rtParams.tarWidth = 1920; pUcObj->Display_mmPrm.rtParams.tarHeight = 1080; pUcObj->Display_mmPrm.rtParams.posX = 0; pUcObj->Display_mmPrm.rtParams.posY = 0; pUcObj->Display_mmPrm.displayId = DISPLAY_LINK_INST_DSS_VID2;
/* displayCtrl configured here ... */
/* more links configured below ... */
}</source>
FAQs[edit]
How can I check weston logs?[edit]
If you are running weston using the linux init script /etc/init.d/weston start, the logs will be present in /var/log/weston.log.
I have installed Processor_SDK_Vision 3.04.00.00 with VDRM support and EVM boots up. Is weston running already?[edit]
The linux init script /etc/init.d/weston start is executed at system startup. So weston may be running in the background. You can verify that by launching ps | grep weston and inspecting the log file /var/log/weston.log
I have installed Processor_SDK_Vision 3.04.00.00 with VDRM support and EVM boots up. I looked at the log and the list of active processes, and it looks like weston is running. Why don't I see anything on screen[edit]
weston is running on vdrm and the buffers can be routed to IPU for display only when the usecase is started. To see the weston output, start vision SDK application apps.out and run the vdrm-dispDistSrc usecase. This usecase can be launched by selecting
<source lang="bash">[HOST] [HOST ] 1: Single Camera Usecases </source>
followed by
<source lang="bash"> [HOST] [HOST ] 8: DispDistSrc (weston) + Display (1920x1080 HDMI) </source>
How can I launch weston manually?[edit]
If weston is running in the background, you will need to kill it first. <source lang="bash"># killall -9 weston </source> or <source lang="bash"># /etc/init.d/weston stop </source>
Then you can launch weston using the following command <source lang="bash"># weston --tty=1 --backend=drm-backend.so --idle-time=0 </source>
If weston terminates abruptly, it does not give away control of the tty it was running on. In that case, relaunching weston with the above command may fail with the following error
<source lang="bash"> ...
[19:26:04.032] initializing drm backend
[19:26:04.032] <stdin> is already in graphics mode, is another display server running?
[19:26:04.032] fatal: drm backend should be run using weston-launch binary or as root
[19:26:04.032] fatal: failed to create compositor backend
</source>
you may launch weston on a different tty by launching
<source lang="bash"># weston --tty=2 --backend=drm-backend.so --idle-time=0
</source>
I have installed Processor_SDK_Vision 3.04.00.00 with VDRM support and EVM boots up. But the weston log file indicates weston failed to launch. Why?[edit]
weston is configured to use omapdrm by default. Since omapdrm is not found in the system, weston dies with the following error
<source lang="bash"> ...
loaded module : gbm_pvr.so
found valid GBM backend : gbm_pvr.so
PVR:(Error): [ 1069-> 1069] < gbm_pvr_create_device():592|ERROR> Failed to create DBM device: No such device [0, ]
[23:11:16.203] failed to initialize egl
[23:11:16.219] fatal: failed to create compositor backend
</source>
If weston is required to use vdrm instead, it can be configured by adding these lines in /etc/powervr.ini
<source lang="bash">[weston]
DbmDriverName=vdrm
</source>
I have installed Processor_SDK_Vision 3.04.00.00 with VDRM support and EVM boots up. weston is configured to use vdrm, but the weston log file indicates weston failed to launch. Why?[edit]
vdrm can allocate buffers only from CMA. The default CMA size allocated by linux is 24 MB. With this configuration, weston cannot allocate enough buffers, and fails with the following error <source lang="bash"> [23:12:39.762] failed to create input device '/dev/input/event1'. [23:12:39.763] output for connector_id = 24 PVR:(Error): [ 1073-> 1073] < gbm_pvr_bo_create_common():260|ERROR> Failed to allocate DBM buffer: Cannot allocate memory [0, ] PVR:(Error): [ 1073-> 1073] < gbm_pvr_surface_create_common():448|ERROR> GBM=0x459f8: cannot allocate GBM buffer[1] [0, ] </source>
For most practical purposes, a CMA size of 128 MB must be enabled. This can be done by adding cma=128M to the kernel command line.
If you are using SD boot, you can find a file named uenv.txt in the boot directory of the SD card. The default content of the file would be
<source lang="bash">fdtfile=dra76-evm-infoadas.dtb args_mmc=part uuid mmc 0:2 uuid; setenv bootargs "console=ttyO0,115200n8 vram=16M root=PARTUUID=${uuid} rw rootwait ip=none mem=1024M" </source>
You can edit the second line to read <source lang="bash">args_mmc=part uuid mmc 0:2 uuid; setenv bootargs "console=ttyO0,115200n8 vram=16M root=PARTUUID=${uuid} rw rootwait ip=none mem=1024M cma=128M" </source>
You will need to save the file and reboot the EVM.
If you want to edit the file from the EVM's console, this file can be found in /run/media/mmcblk1p1/uenv.txt
I can launch weston and see the output using apps.out usecase. But I cannot launch any weston clients. Why?[edit]
Is your client based on wayland-egl? In that case, it will try to allocate its own buffers from the configured DRM driver. By default, all clients are configured to use omapdrm. you can change this behaviour on a per-client basis.
For example, to enable weston-simple-egl on vdrm, you will need to add the following lines in /etc/powervr.ini
<source lang="bash">[weston-simple-egl]
DbmDriverName=vdrm
</source>
I have installed Processor_SDK_Vision 3.04.00.00 with VDRM support. But I cannot find the binaries modetest, kmscube or fliptest in the filesystem. Why?[edit]
The filesystem packaged with Processor_SDK_Vision 3.04.00.00 is a minimal version of the one originally distributed with Processor_SDK_Linux_Automotive 3.04.00.03. It does not contain the binaries mentioned above.
I am able to see weston and wayand-egl based clients. But the output has a lot of tearing. Why?[edit]
By default, weston uses a pool of 3 buffers, and due to functional differences between DRM and VPS drivers, weston renders into the buffer that is currently displayed. To overcome this, you will need to configure weston to use a bigger pool per display.
This can be done by adding a configuration option in the [weston] section in /etc/powervr.ini
<source lang="bash"> [weston]
DbmDriverName=vdrm
+GbmNumBuffers=5 </source>
|
{{
Please post only comments related to the article Virtual DRM : An User Guide for Developing Usecases here. |
Keystone=
Please post only comments related to the article Virtual DRM : An User Guide for Developing Usecases here. |
C2000=For technical support on the C2000 please post your questions on The C2000 Forum. Please post only comments about the article Virtual DRM : An User Guide for Developing Usecases here. | DaVinci=For technical support on DaVincoplease post your questions on The DaVinci Forum. Please post only comments about the article Virtual DRM : An User Guide for Developing Usecases here. | MSP430=For technical support on MSP430 please post your questions on The MSP430 Forum. Please post only comments about the article Virtual DRM : An User Guide for Developing Usecases here. | OMAP35x=For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article Virtual DRM : An User Guide for Developing Usecases here. | OMAPL1=For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article Virtual DRM : An User Guide for Developing Usecases here. | MAVRK=For technical support on MAVRK please post your questions on The MAVRK Toolbox Forum. Please post only comments about the article Virtual DRM : An User Guide for Developing Usecases here. | For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article Virtual DRM : An User Guide for Developing Usecases here.
}} |
