This page is intended to capture high-level requirements, features, and architecture for AAMP IP Video Engine.
AAMP is a native player that can be invoked from JavaScript using:
Developer Guidelines
Build Instructions
Architecture/Design
Triage
Test Content
Overview
- Audio capture manager presents the audio data to registered applications.
- Supports creation of audio clips from currently streaming content.
- Creates clips of audio from content currently viewing so that it can be used for song identification service.
- The Data Capture Service Manager API is used to create audio clip and post/stream to Music ID server (specified URL.)
- When Service Manager API is called to create audio clip, settop creates audio clip of specified duration.
Data Flow
- At startup, app calls org.rdk.dataCapture_1.enableAudioCapture api to create pre-capture audio buffer and starts buffering primary audio stream.
- App makes request for audio clip capture by passing following parameters:
- Destination URL and application parameters for Music ID service
- Length of clip capture
- Primary or secondary audio. (Note: Only primary audio is continuously captured)
- Send pre-captured data, or post-capture (capture starts after app makes request). Majority of requests will be for pre-captured data, where entire clip is already captured by the time call is made.
- App calls Service Manager API org.rdk.dataCapture_1.getAudioClip and passes the request
{
"stream" : “primary”
"url" : "http://<musicid_server/analyze?trx=83cf6049-b722-4c44-b92e-79a504ae8f85:1458580048400&codec=PCM_16_16K&deviceId=5082732351093257712",
"duration" : 6
"captureMode" : “preCapture”
}
- Service Manager stores url and then calls IARMBUS_AUDIOCAPTUREMGR_REQUEST_SAMPLE which is handled in audiocapturemgr.
- ACM (using audio driver api's) extracts the data based on specified length in seconds,
- the content must be raw binary data captured from PCM output
- packages data in a pcm file, and
- sends IARM event to Service Manager.
- Name of event: DATA_CAPTURE_IARM_EVENT_AUDIO_CLIP_READY.
- Associated data: file or html locator is sent with event.
- Service Manager takes the audio clip file, formats the curl message and sends the file to URL pointing to Music ID service.
curl \-H "Content-Type: application/x-wav" \--trace-ascii debugdump.txt \--data-binary @AudioClip_6.wav '<media_service_url>&codec=PCM_16_16K&deviceId=<device ID>'
- Service Manager logs the capture event
- Service Manager logs the response from Music ID service.
Test Case Using Test App CLI Interface
Ensure that SDK support is enabled for audiocapture.
- Confirm the presence of /usr/bin/audiocapturemgrtestapp
- Launch /usr/bin/audiocapturemgrtestapp and verify that you get a CLI menu
- Select option set precapture length.
- Provide 3 as the value and press enter.
- Select option Start client.
- Wait 3 seconds and then select dump precaptured sample. The console will indicate the name and path of the file being written. Note this down and and the precapture length you set (3).
- Select capture next N seconds. Enter 10 for length and press enter. The console will indicate the name and path of the file being written. Note this down and the length you entered just now.
- Wait 11 seconds.
- Select Stop client.
- Select Quit.
- Copy the dumped files to a PC and verify that they're playable.
- Verify that the duration of these sound clips match the number that you logged against them when conducting the test.
- Delete all the .wav files created in /opt/ by the test application.
Note: the precaptured sample files have the following pattern: /opt/precap-*.wav.
The sound samples captured using capture next N seconds option will have the following filename pattern: /opt//opt/freshcap-*.wav.
API Documentation
To see the List of APIs supported by audiocapturemgr, Please see Audiocapturemgr API Documentation
Bluetooth Provides an interface to port any Bluetooth application on RDK. Bluetooth Manager (An RDK component) interfaces with BlueZ through the D-Bus API, so there is no direct linking of the BlueZ library with Bluetooth Manager.
In RDK, Bluetooth is comprised of a Core module (BTCore) and a Manager module (BTMgr). The BTCore module controls basic Bluetooth functionality such as scanning, pairing, and connecting. The BTMgr module uses the services of the BTCore module for performing audio streaming. RDK has two utilities for testing. A btrCoreTest utility tests the BTCore functions. A btrMgrStreamOutCoreTest utility tests BTMgr functions. Both utilities share some common functionality. For example, it is possible to perform a device scan using either utility.
Bluez
In its current implementation, the RDK Bluetooth uses the Bluez stack. It is possible that another stack (e.g. Broadcom’s BSA) could be used in the future.
DBUS
The Bluez stack uses DBus to facilitate communication between the user application and the kernel level Bluetooth functions.
gStreamer
BTMgr utilizes gStreamer to process incoming Bluetooth data
Basic Bluetooth Architecture in RDK
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAwOTQwIiwiZGlhZ3JhbU5hbWUiOiJCYXNpYyBCbHVldG9vdGggQXJjaGl0ZWN0dXJlIGluIFJESy5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiYmx1ZXRvb3RoX21nciIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjY5MDI5MjEsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI2OTAyOTIxLCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiZTQzOGIwNDMtMTQwNC00NGQ5LTlmMmUtMzEwNjFjOGRkZTRkIiwicHJldmlld05hbWUiOiJCYXNpYyBCbHVldG9vdGggQXJjaGl0ZWN0dXJlIGluIFJESy5kcmF3aW8ucG5nIiwibGljZW5zZVN0YXR1cyI6Ik9LIiwic2VydmljZSI6IiIsImlzVGVtcGxhdGUiOiIiLCJ3aWR0aCI6Im51bGwiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2MTQ2OTQ1NDQwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
Connecting to a device
In order to connect, the device must first be discovered. The source device (e.g. tablet or phone) can be put into a discoverable mode. This can be accomplished with the btrCoreTest utility. The current options are shown below:
- 1. Get Current Adapter
- 2. Scan
- 3. Show found devices
- 4. Pair
- 5. UnPair/Forget a device
- 6. Show known devices
- 7. Connect to Headset/Speakers
- 8. Disconnect to Headset/Speakers
- 9. Connect as Headset/Speakerst
- 10. Disconnect as Headset/Speakerst
- 11. Show all Bluetooth Adapters
- 12. Enable Bluetooth Adapter
- 13. Disable Bluetooth Adapter
- 14. Set Discoverable Timeout
- 15. Set Discoverable
- 16. Set friendly name
- 17. Check for audio sink capability
- 18. Check for existance of a service
- 19. Find service details
- 20. Check if Device Paired
- 21. Get Connected Dev Data path
- 22. Release Connected Dev Data path
- 23. Send SBC data to BT Headset/Speakers
- 29. BT audio input test
- 30. install agent for accepting connections NoInputNoOutput
- 31. install agent for accepting connections DisplayYesNo
- 32. Accept a connection request
- 33. Deny a connection request
- 34. Register connection callback to allow accepting or rejection of connections.
- 35. Uninstall agent - allows device-initiated pairing
- 88. debug test
- 99. Exit
Sequence of Steps
- User can use option 2 to start a device scan. The scan takes about 10 seconds to complete, then use option 3 to see the list of devices that the settop found. If your device is in the list, you can use option 4 to perform a pairing. In some cases, you may have to confirm the pairing on the tablet/phone.Once the device is paired, the next step is to establish an audio connection between the settop and your source device (e.g. tablet).
- In most cases, the connection must be initiated from the source device. Ubuntu is an exception to this, so if playing music from Ubuntu, you can start the connection from the settop. To do this, use option 9. You may have to confirm the connection on Ubuntu.
- If you are initiating the connection from the tablet, you must first start an agent. The agent allows accepting of connections from remote devices. You can do this using option 31. After invoking option 31, connect to the settop from your tablet.
Note, the agent seems to inhibit pairing from the settop, so if you need to pair more devices from the settop, you can use option 35 to unregister the agent.
- Once you have connected the device once (during the settop lifetime or with the device in persistent memory) you will not need to use the agent again. The connection will automatically be established upon attempt by Bluez, with no agent required.
- Optionally, before attempting to connect, you can run option 34 to install an authentication callback. This allows the settop to accept or refuse the connection from the tablet. If you run option 34, then attempt a first time connection from a tablet, you will be prompted to enter option 32 to accept, or 33 to deny the request.
- Once connected, you can start your player on your tablet. There is an option 29 in the btrCoreTest menu that retrieves data from Bluetooth, and pipes it into a gst-launch command to start the gstreamer elements to perform playback. However, it is not a full gstreamer implementation. To run the full gstreamer implementation, use the btrMgrStreamOutCoreTest, after first having paired and connected the device.
btrMgrStreamOutCoreTest
The current btrMgrStreamOutCoreTest having following option in RDK
- 1. Get Current Adapter
- 2. Scan
- 3. Show found devices
- 4. Pair
- 5. UnPair/Forget a device
- 6. Show known devices
- 7. Connect to Headset/Speakers
- 8. Disconnect to Headset/Speakers
- 9. Connect as Headset/Speakerst
- 10. Disconnect as Headset/Speakerst
- 11. Show all Bluetooth Adapters
- 12. Enable Bluetooth Adapter
- 13. Disable Bluetooth Adapter
- 14. Set Discoverable Timeout
- 15. Set Discoverable
- 16. Set friendly name
- 17. Check for audio sink capability
- 18. Check for existance of a service
- 19. Find service details
- 20. Check if Device Paired
- 21. Get Connected Dev Data path
- 22. Release Connected Dev Data path
- 23. Send SBC data to BT Headset/Speakers
- 24. Send WAV to BT Headset/Speakers - btrMgrStreamOutTest
- 25. Send Live Audio to BT Headset/Speakers
- 26. Send audio data from device to settop with BT
- 88. debug test
- 99. Exit
Once bluetooth connected with your tablet, start the player on your tablet, then do option 21 (this gets needed parameters for playback. Note, this functionality is automatically invoked in the btrCore utility, but has not, as of this time, been implemented in the btrMgr utility).
Once you do option 21, you can do option 26 to start Bluetooth audio, in a full gstreamer implementation.
gStreamer
Gstreamer contains several plugins for the Bluetooth In process. The gstreamer used is version 1.0.
rtpsbcdepay | sbcparse | sbcdecode | brcmpcmsink
rtpsbcdepay: takes RTP encapsulated data from Bluetooth, and removes the RTP headers. The payload is sbc encoded data.
Note it has been observed that some devices such as Ubuntu and the iPhone 5s use a constant RTP packet size, whereas some Samsung tablets have been observed to use a variable RTP packet size.
sbcparse & sbcdecode: together, these two plugins convert the sbc data to pcm data.
brcmpcmsink: outputs pcm data to HDMI (or other source if configured, such as SPDIF out). This plugin is made by Broadcom. To date, only HDMI out has been tested.
One important note for using these utilities: Before you can use them, you must first kill a process that will be used for providing the Comcast XRE app with Bluetooth capability. You can do this as follows:
systemctl stop btmgr
Be sure to do systemctl stop btmgr before using the btrCore or btrMgr utilities.
API Documentation
To know more about SoC/Application level APIs details use in RDK, refer the link BLUETOOTH MANAGER API Documentation
Introduction
Bluetooth in RDK, provides short range wireless connectivity between RDK devices and consumer electronics devices. RDK Bluetooth architecture is designed to support any Bluetooth stack.
The Bluetooth stack currently supports common Bluetooth profile such as A2DP, AVRCP, and can be extended to various profiles such as HID, PAN, etc.. Bluetooth may be enabled directly on capable RDK boxes or indirectly via USB-to-Bluetooth adaptor.
Features supported in RDK
Bluetooth feature in RDK | Feature Descriptions |
---|
Audio Encoding | Detail SBC (sub-band coding) and aptX encoding (Bluetooth chip, in software, or in SoC hardware). |
Audio Output Muting | The Bluetooth audio output may be muted independently of other audio outputs (e.g. HDMI) |
Audio Input (Settop as AD2P SNK) | Using RDK device speakers over bluetooth i.e transmitting audio input back to a speaker connected with RDK device. |
Audio Output Routing | Detail PCM audio routing to Bluetooth A2DP SRC, It uses H/W accelerations, S/W processing, RMF involvement on streaming audio/video contents. |
Audio Output Sources | Bluetooth audio may be different than HDMI audio (e.g. secondary audio program, application sourced audio such as Pandora, voice navigation audio, etc). |
Dual Decode | Supports ability to simultaneously output one audio stream to HDMI and a different audio stream to Bluetooth |
Power Control | In future, the power state of each Bluetooth connected device and the Bluetooth subsystem can be controlled |
Audio/Video Remote Control Profile (AVRCP) | Controller (Remote Control) sends mute and volume commands to target. AV/C commands are defined by the 1394 trade association |
Bluetooth in RDK - Block Diagram
Bluetooth in RDK provides Interface API and implementation to abstract Bluetooth stack and it provides 5 layers in the BTR (Bluetooth-RDK) stack.
1. Bluetooth daemon (Bluez based) - Interacts with kernel layer bluetooth modules
2. Bt-Ifce (Abstracts Bluez versions and servers as a HAL for other Bluetooth stacks) - Interacts with Bluez over DBus
3. Bluetooth HAL (BTRCore) - Provide API to perform Bluetooth operations by abstracting and simplifying the complexities of Bt-Ifce (& BLuez)
4. BTRMgr - Utilize API's exposed by BTRCore to perform high level Bluetooth ops like Scan, Pair, Connect and achieve usecases like AudioOut.
Exposes interfaces for external entities to perform BTRMgr related operation using IARM
5. ServiceManager [BluetoothService] - Interacts with BTRMgr based on Application requirements using IARM. Guide applications are interact with Service Manager.
6. RDK Apps/Diagnostics - HTML-5 based UI applications to make use of Bluetooth service using Service Manager APIs.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMjUyIiwiZGlhZ3JhbU5hbWUiOiJibHVldG9vdGgxLmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJCbHVldG9vdGggKEJUKSIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjYxODE2NTMsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI2MTgxNjUzLCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiZGE1N2QxMzAtMDkyYS00Mzk2LTgxZWEtNWVmYzY0MjJjN2UwIiwicHJldmlld05hbWUiOiJibHVldG9vdGgxLmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU0ODAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
Bluetooth Architecture
Bluetooth Manager and Bluetooth HAL [BTRCore] is that Bluetooth Manager implements the BT HAL [BTRCore] API. Then BT HAL [BTRCore] integrates and manages the BlueZ stack though the D-BUS interface.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMjU0IiwiZGlhZ3JhbU5hbWUiOiJCbHVldG9vdGgyLmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJCbHVldG9vdGggKEJUKSIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjYxODE2NTMsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI2MTgxNjUzLCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiMTVlYzIxOGEtMDZkOS00ZDMwLThlYmYtOGM3ZjJmYjU2ZjZjIiwicHJldmlld05hbWUiOiJCbHVldG9vdGgyLmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU0ODAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
BlueZ D-Bus Communication
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMDA4IiwiZGlhZ3JhbU5hbWUiOiJibHVldG9vdGg0LmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJCbHVldG9vdGggKEJUKSIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjYxODE2NTMsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI2MTgxNjUzLCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiZjIxMTAxNGMtZGQyMS00NmM2LWFiYTEtMGFkYWZjYWQ1MGY4IiwicHJldmlld05hbWUiOiJibHVldG9vdGg0LmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU0NTAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
Bluetooth - Service Manager
Bluetooth Service Manager component in RDK exposes Java scripts APIs against each of the Core Bluetooth features supported in the current implementation Javascript API's have been exposed to invoke IARM communication in the context of a browser which have a Javascript engine when we have HTML/HTML5/Browser based applications. Applications which don't have a Java-script engine should also be able to invoke Service manager methods/IARM methods to communicate with BTRMgr.
Provides methods and events to support the following features,
- Device discovery
- Pairing with the remote device
- Connecting to the device after authentication.
- Choose Audio stream to be streamed to other bluetooth device.
- Provides method to select appropriate audio sink
Contains Methods and Events to communicate with the Bluetooth manager
Service Manager will send event in case external Bluetooth adapter is inserted or removed, or it is requested for pairing.
List of API & Events
Refer to Bluetooth APIs for a complete list of Bluetooth APIs and events exposed by service manager.
Bluetooth Manager (BTRMgr)
Bluetooth Manager (An RDK component) interfaces with BlueZ through the D-Bus API, so there is no direct linking of the BlueZ library with Bluetooth Manager. BTRCore uses Bt-Ifce (which serves as Bluetooth HAL) interfaces with BlueZ.
BTRMgr Provides an interface to port any Bluetooth stack on RDK Provides an interface to port any Bluetooth application on RDK
The bluetooth_mgr daemon manages Bluetooth services in RDK. It uses IARM Bus to facilitate communication between the application and Bluetooth driver through Bluetooth Manager component.
Bluetooth HAL Interface:
Bluetooth HAL interface Provides an software abstraction layer that interfaces with the actual Bluetooth implementation and/or drivers. RDK Bluetooth HAL layer enables projects to pick whatever Bluetooth profiles as per their requirements. Bluetooth HAL uses BlueZ5.42 stack which is a quite popular Linux Bluetooth library.
BlueZ In RDK
- BlueZ is a well known Open Source project used to support core Bluetooth layers and protocols on Linux systems.
- BlueZ is multi processing safe, supports multiple Bluetooth devices, and provides device and service level security.
- Supported Profiles: A2DP 1.3, AVRCP 1.5, DI 1.3, HDP 1.0, HID 1.0, PAN 1.0, SPP 1.1
- The interface layer is based off of DBUS, so there is no direct linking with the BlueZ daemon.
- Currently BlueZ5.42 stack is integrated with RDK & it is managed by Bluetooth HAL component.
Some Bluetooth supported gstreamer plugins used by BlueZ 5:
Gstreamer Elements | Descriptions |
sbcenc | Bluetooth SBC (sub-band coding) encoder |
sbcdec | Bluetooth SBC (sub-band coding) decoder |
sbcparse | The sbcparse element will parse a Bluetooth SBC audio stream into frames and timestamp them properly |
avdtpsink | Bluetooth AVDTP sink |
a2dpsink | Bluetooth A2DP sink for streaming audio |
rtpsbcpay | RTP packet payload maker |
Use Case : Bluetooth Device Discovery
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMDEwIiwiZGlhZ3JhbU5hbWUiOiJCbHVldG9vdGg1LmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJCbHVldG9vdGggKEJUKSIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjYxODE2NTMsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI2MTgxNjUzLCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiYWM2MTJmZmMtOTBiZS00NjVhLWI4ZDctYzlhNjY5NjUzNjI3IiwicHJldmlld05hbWUiOiJCbHVldG9vdGg1LmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU0NTAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
RDK Bluetooth A2DP Use Case - Audio Streaming
- Set-top enables Bluetooth audio output (A2DP SRC).
- Set-top uses Bluetooth periodic Inquiry procedure to discover A2DP SNK.
- If user enables Bluetooth audio output, set-top discovers A2DP SNK but set-top and application has not registered to take control of Bluetooth pairing then:
- set-top prompts user to select A2DP SNK device to pair and pairs upon user selection.
- Set-top encodes audio output to A2DP SNK according to A2DP SNK's capabilities.
- Set-top streams primary audio to A2DP SNK.
- Set-top provides application layer control over Bluetooth enable/disable state.
- Set-top notifies application via Bluetooth Service API when Bluetooth device is discovered.
- Set-top logs connect/disconnect to/from Bluetooth device (A2DP SNK)
API Documentation
To know more about SoC/Application level APIs details use in RDK, refer the link BLUETOOTH API Documentation
Breakpad consists of a library and tool suite –
Library is linked with the application to record crashes in compact "minidump" file
- libbreakpad_client.a (breakpad client: that writes minidump)
Tools are used in the server (or in a system where debugging is performed) to produce C and C++ stack traces.
- dump_syms (symbol dumper: to extract the debug symbols for a given library/binary)
- minidump_stackwalk (minidump processor: uses the minidump and the symbols created by dump_syms to produce stack trace)
Breakpad C Wrapper
Breakpad wrapper acts as a wrapper to integrate Google Breakpad with RDK components.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMTUyIiwiZGlhZ3JhbU5hbWUiOiJicmVha3BhZC5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiQnJlYWtwYWQgV3JhcHBlciIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6ODU3NTg5MTgsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjg1NzU4OTE4LCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiNTY2ZWIyOWMtZTI3YS00YTliLWIzNDItZTUzOWYxZDM2ZmU2IiwicHJldmlld05hbWUiOiJicmVha3BhZC5kcmF3aW8ucG5nIiwibGljZW5zZVN0YXR1cyI6Ik9LIiwic2VydmljZSI6IiIsImlzVGVtcGxhdGUiOiIiLCJ3aWR0aCI6Im51bGwiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2MTQ2OTQ1NDcwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
Purpose of this component is to avoid static linking of the library (libbreakpad_client.a) across different modules. Includes the static library (libbreakpad_client.a) so that we can use dynamic library (libbreakpadwrapper.so) along with the native code.
https://code.rdkcentral.com/r/rdk/components/generic/breakpad_wrapper
Breakpad exception handler writes minidump to disk at exception time.
void breakpad_ExceptionHandler()
{
printf("\t\t\t\t ********ENTER breakpad_ExceptionHandler****************** \n");
static google_breakpad::ExceptionHandler* excHandler = NULL;
excHandler = new google_breakpad::ExceptionHandler(google_breakpad::MinidumpDescriptor("/opt/minidumps"), NULL, breakpadDumpCallback, NULL, true, -1);
printf("\t\t\t\t ******** breakpad_ExceptionHandler EXIT****************** \n");
}
Breakpad-wrapper component compiles to create libbreakpadwrapper.so which needs to be linked with the RDK component for Breakpad integration.
See the page Integrating Breakpad to RDK-V Component to know about its usage
Introduction
- RDK PROC ANALYZER is a tool that enables different teams like development, triage and testing to analyze the CPU and memory utilization of the processes that run on top of RDK framework.
- It helps us in detecting the memory leaks, cpu and memory performance regressions.
- This tool is implemented as a service.
- Highly configurable (Parameters like period , time interval and processes to be monitored can be configured).
Code Flow
- The main code flow of CPU Procanalyzer -
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAwNzcwIiwiZGlhZ3JhbU5hbWUiOiJNQUlOIENPREUgRkxPVy5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiY3B1cHJvY2FuYWx5emVyIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjo5MDExNzIzNCwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6OTAxMTcyMzQsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEsIm1hY3JvSWQiOiIyYjJjMjdkNS1lZTUyLTQ1ZTQtYjg1ZC0wNDI3MzkyNDU4OTAiLCJwcmV2aWV3TmFtZSI6Ik1BSU4gQ09ERSBGTE9XLmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU0MjAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
- To get the Load Average information-
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMDg4IiwiZGlhZ3JhbU5hbWUiOiJsb2FkYXZnLmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJjcHVwcm9jYW5hbHl6ZXIiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjkwMTE3MjM0LCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjo5MDExNzIzNCwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6ImI1OTA2YTRhLTUzYjktNGQ1Mi04OTVmLTJhYjI2NTllNjM5OCIsInByZXZpZXdOYW1lIjoibG9hZGF2Zy5kcmF3aW8ucG5nIiwibGljZW5zZVN0YXR1cyI6Ik9LIiwic2VydmljZSI6IiIsImlzVGVtcGxhdGUiOiIiLCJ3aWR0aCI6Im51bGwiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2MTQ2OTQ1NDYwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
- To get the Memory information-
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMDkwIiwiZGlhZ3JhbU5hbWUiOiJtZW0gaW5mby5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiY3B1cHJvY2FuYWx5emVyIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjo5MDExNzIzNCwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6OTAxMTcyMzQsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEsIm1hY3JvSWQiOiJlYTQzMjlhZC0wNWZkLTQ3ZTItYTBhYS05YTY4MDgxMzkzNjciLCJwcmV2aWV3TmFtZSI6Im1lbSBpbmZvLmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU0NjAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
- To get the Idle Percent Information-
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMDkyIiwiZGlhZ3JhbU5hbWUiOiJpZGxlcGVyY2VudC5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiY3B1cHJvY2FuYWx5emVyIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjo5MDExNzIzNCwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6OTAxMTcyMzQsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEsIm1hY3JvSWQiOiJlNzNmM2VmMC1mODJkLTRmNDQtYjNkYi0yOGQ3YmEwZmQwNjEiLCJwcmV2aWV3TmFtZSI6ImlkbGVwZXJjZW50LmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU0NjAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
How to Launch
This tool runs as a service.
If the file /tmp/PROC_ANALYZER_ENABLE is touched the tool starts running and it logs the details.
How to Configure:
1 Open ‘/opt/rmfconfig.ini’ file on the device.
Parameters that can be configured:
(a)Time Interval
(b)Period
(c)Enable Dynamic
It would take the default values if not configured (sleepsecs:60, Time to run:0, Dynamic:1)
Ex: FEATURE.CPUPROCANALYZER. SLEEP.SECS=60
FEATURE.CPUPROCANALYER.TIMETORUN.SECS = 0 (which means tool runs until it is killed manually)
FEATURE.CPUPROCANALYZER.DYNAMIC = 1
2. Open ‘/opt/processes.list’ file on the device.
File to configure process names to be monitored
Overview
Crash dumping system facilitates service providers or developers to collect crashes happened in the set-top boxes and do the debugging in offline. Crash dumping system is a debug supporting system, which consists of Crash dumping server(s) with user interfaces. Crash dumping server collect crash logs which happened in the connected STBs, process these logs and store for future reference.
Crash log is a log file automatically created on Set top boxes when a crash occurs. This information is useful for offline debugging.
Minidump
- A list of the executable and shared libraries that were loaded in the process at the time the dump was created. This list includes both file names and identifiers for the particular versions of those files that were loaded.
- A list of threads present in the process. For each thread, the minidump includes the state of the processor registers, and the contents of the threads' stack memory.
- Other information about the system on which the dump was collected: processor and operating system versions, the reason for the dump, and so on.
Google Breakpad
Breakpad is a library that records crashes in compact "minidump" files. It produce C and C++ stack traces from minidumps. Breakpad can also write minidumps on request for programs that have not crashed.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMDEyIiwiZGlhZ3JhbU5hbWUiOiJjcmFzaHVwbG9hZC5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiQ3Jhc2h1cGxvYWQiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjI2MTgxNjY0LCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjoyNjE4MTY2NCwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6IjllMWY0Zjc1LTY2NWYtNGUxOC04YmM0LWE5ZDYzMzA2NzM2MyIsInByZXZpZXdOYW1lIjoiY3Jhc2h1cGxvYWQuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTQ1MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
How to Integrate Google Breakpad library?
#include "client/linux/handler/exception_handler.h“ // Include Header file for exception handler
static bool dumpCallback(const google_breakpad::MinidumpDescriptor& descriptor, void* context, bool succeeded)
{
printf("Dump path: %s\n", descriptor.path());
return succeeded;
}
int main(int argc, char* argv[])
{
google_breakpad::MinidumpDescriptor descriptor("/tmp");
google_breakpad::ExceptionHandler eh(descriptor, // Minidump will be saved in /tmp
NULL,
dumpCallback, //Callback
NULL,
true,
Google Breakpad Utilities
- dump_syms is used for symbol extraction.
dump_syms ./gpsample_app > gpsample_app.sym, will generate symbol file.
- minidump_stackwalk is used for symbolized stack trace
It takes a minidump and its corresponding text-format symbols and produce a symbolized stacktrace.
minidump_stackwalk minidump.dmp gpsample_app.sym
uploadDumps.sh collects core dumps/ mini dumps to crash server whenever any applications crashes.
Sample Application
#include "client/linux/handler/exception_handler.h“
static bool dumpCallback(const google_breakpad::MinidumpDescriptor& descriptor,
void* context,
bool succeeded)
{
printf("Dump path: %s\n", descriptor.path());
return succeeded;
}
void crash()
{
volatile int* a = (int*)(NULL);
*a = 1;
}
int main(int argc, char* argv[])
{
google_breakpad::MinidumpDescriptor descriptor("/tmp");
google_breakpad::ExceptionHandler eh(descriptor,
NULL,
dumpCallback,
NULL,
true,
-1);
crash();
return 0;
}
To compile the source
- Create a simple Makefile
- Add the following contents to the Makefile
PKG_CONFIG_PATH=../
all: breakpad_exercise.c
@ $(CXX) -std=c++11 breakpad_exercise.c -g -o breakpad_exercise `pkg-config --cflags breakpad` -L./client/linux/ -lbreakpad_client -I./ -lpthread
Execute the sample application
- An application of name “breakpad_exercise” will be generated. Copy this executable to the box
- Run the application in the box which will cause segmentation fault:
- A minidump will be generated in the same file
Coredump
Core dump files generated after an uncaught signal in a process (as a SIGSEGV or SIGQUIT), are generated in the base directory where the program was executed, and the core dumps starts with the name as “core” or “core.PID”.
By default size of the core will be zero, To generate the core, we need to set the size of the core to unlimited.
By default, core will be generated in the current directory with the file name "core". We can change the core generating directory from current directory to another by editing the kernel configuration file core pattern(/proc/sys/kernel/core_pattern) in the kernel.
Core pattern is helpful in the case if there are couple of core dumps files in one directory and we don't know which program caused it.
How to get stack trace?
Make sue the executable is compiled with -g option to turn on the debugging symbols
gdb <executable_path> <coredump_file_path>
After you get inside the gdb-prompt, (on execution of the above command), type;
(gdb) bt full
API Documentation
To know more about SoC/Application level APIs details use in RDK, refer the link Crashupload API Documentation
This page is under construction
Overview
Data Collection and Analysis (DCA) is responsible for collecting the data from various log files and send to server. The script dca_utility.sh is in place on the set-top box. Based on the DCM response it will create a cron job in the settop box.
*/20 * * * * nice -n 20 sh /lib/rdk/dca_utility.sh 1
This cron job will send out the JSON message with the level one parameter values to the server.
There are 3 level of loggins message and upload to the server. Using S3 as the log back end for second and third level logging.
- First Level
- Frequency - start with 5 minutes and then expand.
- If log upload frequency is 5 minutes, that is separate from the log collection frequency, which will be based on various parameters.
- Parameters could be counters.
- Parameters may not be available in logs but may need real-time probing using snmp/tr-69 or other methods.
- We will need collect records based on frequency at which collection needs to occur.
- Log some events back to the cloud. Could be to S3 or another destination.
- Records that it upload should be records that could be fed into Splunk without having to do much processing, for example, a name/value pair or another that is easy to expose on Splunk.
- There could be multiple records since logging period.
- Data collection frequency and upload frequency can be configured differently.
- The level will be enabled for every device.
- Second Level
- Medium number of logs. Full logs will need to be pushed.
- Second and Third level are similar.
- Third Level
- Similar to current method of full log uploads.
Architectural diagram
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAwOTMyIiwiZGlhZ3JhbU5hbWUiOiJEQ0EgQXJjaGl0ZWN0dXJlIERpYWdyYW0uZHJhd2lvIiwiYXNwZWN0IjoiIiwibGlua3MiOiJhdXRvIiwiY2VvTmFtZSI6IkRDQSIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjYxODE2NjksImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI2MTgxNjY5LCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiYzY5YmM2NTItMGRlMy00OTZjLWJkZDAtMzRkMTdhZTk2OThjIiwicHJldmlld05hbWUiOiJEQ0EgQXJjaGl0ZWN0dXJlIERpYWdyYW0uZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTQ0MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
Process Flow
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAwOTM0IiwiZGlhZ3JhbU5hbWUiOiJQcm9jZXNzIEZsb3cuZHJhd2lvIiwiYXNwZWN0IjoiIiwibGlua3MiOiJhdXRvIiwiY2VvTmFtZSI6IkRDQSIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjYxODE2NjksImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI2MTgxNjY5LCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiOWIwYzQ3MTktMDUzYi00ZjM3LTkyNDAtZTlmMTBhODZjZTU1IiwicHJldmlld05hbWUiOiJQcm9jZXNzIEZsb3cuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTQ0MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
- DCMscript.sh communicates with Xconf server and fetches the predefined markers
- Using the markers, DCM Script will prepare a sorted map file for the log lookup, creates a CRON job for DCA Agent.
- CRON job retrieves data from the device using DCA which filters search patterns by looking into logs.
- From the retrieved data, it will create a JSON formatted message.
- JSON format data is uploaded to server
{"searchResult":[{"Total Space available":"30"},{"Heartbeat":"61"},{"Success tune":"280"},{"Failure tune":"0"},{"mac":"14:D4:FE:65:A9:81"},{"Version":"PX001AN_VBN_master_HYB_021622172015_PBTsd_RTT"}]}
{"urn:settings:GroupName":"test","urn:settings:CheckOnReboot":true,"urn:settings:CheckSchedule:cron":"47
9 * *
*","urn:settings:CheckSchedule:DurationMinutes":10,"urn:settings:CheckSchedule:StartDate":"2014-01-01
01:01:01","urn:settings:CheckSchedule:EndDate":"2017-11-01
01:01:01","urn:settings:LogUploadSettings:Message":null,"urn:settings:LogUploadSettings:Name":"test","urn:settings:LogUploadSettings:NumberOfDays":0,"urn:settings:LogUploadSettings:UploadRepositoryName":"Amazon","urn:settings:LogUploadSettings:RepositoryURL":"http://logs.xcal.tv","urn:settings:LogUploadSettings:UploadOnReboot":true,"urn:settings:LogUploadSettings:upload":true,"urn:settings:LogUploadSettings:LogFiles":[{"id":"2609da75-59ed-494f-96a0-369328be6a9c","name":"logfile1","deleteOnUpload":true},{"id":"6cfb1b02-4147-4980-8e3c-26754d14329e","name":"logfile2","deleteOnUpload":true}],"urn:settings:LogUploadSettings:LogFiles:StartDate":"","urn:settings:LogUploadSettings:LogFiles:EndDate":"","urn:settings:LogUploadSettings:UploadSchedule:cron":"6
2 * *
*","urn:settings:LogUploadSettings:UploadSchedule:levelone:cron":null,"urn:settings:LogUploadSettings:UploadSchedule:leveltwo:cron":null,"urn:settings:LogUploadSettings:UploadSchedule:levelthree:cron":"3","urn:settings:LogUploadSettings:UploadSchedule:DurationMinutes":20,"urn:settings:LogUploadSettings:UploadSchedule:StartDate":"2014-01-01
01:01:01","urn:settings:LogUploadSettings:UploadSchedule:EndDate":"2016-01-01
01:01:01","urn:settings:VODSettings:Name":null,"urn:settings:VODSettings:LocationsURL":null,"urn:settings:VODSettings:SRMIPList":null}
STB Script Design
Script will create temporary files split from the logs based on the seek value(Which keeps track of the point till we have looked in the logs). Once the strings are looked in the temporary file the script deletes the temporary file from the settop box. All the string/SNMP queries that settop box has to monitor is derived from the DCM response.
API Documentation
To know more about SoC/Application level APIs details use in RDK, refer the link DCA API Documentation
Overview
RDK Device Settings library is a cross-platform library for controlling the following hardware configurations:
- Audio Output Ports (Volume, Mute, etc.)
- Video Ouptut Ports (Resolutions, Aspect Ratio, etc.)
- Front Panel Indicators
- Zoom Settings
- Display (Aspect Ratio, EDID data etc.)
- General Host configuration (Power managements, event management etc.)
The library is split into three major components
- Application Level APIs. (Comcast component)
- SoC level APIs. (SoC component)
- IARM support. (Comcast Component)
Application Level API
This is the API that application should use to control hardware configurations in a platform independent way. It also hides single-app and multi-app difference of the implementation from the applications. This allows the application to switch among different SoC versions or between single or multi app mode freely.
Example: API to get the current video resolution :
const VideoResolution & VideoOutputPort::getResolution() const
SoC Level API
SoC Level APIs that that need to implement by SoC vendors. It provides primitive and hardware specific implementation for each controllable aspect of their device. This level API is considered single-app mode only, even though its SoC implementation may potentially support multiple-app mode.
Example: API to get the current video resolution :
dsError_t dsGetResolution ( int handle, dsVideoPortResolution_t *resolution )
IARM Support
If multiple applications need to control the device settings simultaneously, this component turns the single-app mode SoC level API into multi-app mode. Even though some SoC vendors implement the SoC level API to be multi-app capable, we still use Comcast’s IARM support to achieve multiple-app mode. This allows the Application level API to remain truly platform neutral.
Architectural Overview
The Device Settings (DS) registers its services with the service manager. The Application uses/calls the DS Public API through service manager and DS Public API’s intern calls the under lying SoC level API’s to perform the required functionality.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNDk2IiwiZGlhZ3JhbU5hbWUiOiJCbG9jayBkaWFncmFtLmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJEZXZpY2UgU2V0dGluZ3MiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjI4MDgyNDUxLCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjoyODA4MjQ1MSwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6ImE4NWZlYTQ0LWE4OWMtNDdmYS1hYzg1LTg5YjE1ZmIxMWFiMiIsInByZXZpZXdOYW1lIjoiQmxvY2sgZGlhZ3JhbS5kcmF3aW8ucG5nIiwibGljZW5zZVN0YXR1cyI6Ik9LIiwic2VydmljZSI6IiIsImlzVGVtcGxhdGUiOiIiLCJ3aWR0aCI6Im51bGwiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2MTQ2OTQ1NTEwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
Multi-App mode Support using IARM
Multi-app mode is used when multiple applications need to control the device settings simultaneously. Some SoC vendors implement the SoC level API to be multi-app capable, we still use Comcast’s IARM support to achieve multiple-app mode. This allows the Application level API to remain truly platform neutral.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNDk4IiwiZGlhZ3JhbU5hbWUiOiJNdWx0aS1BcHAgbW9kZSBTdXBwb3J0IHVzaW5nIElBUk0gZGlhZ3JhbS5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiRGV2aWNlIFNldHRpbmdzIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjoyODA4MjQ1MSwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6MjgwODI0NTEsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEsIm1hY3JvSWQiOiI2Y2MzY2ViNy1mOGQxLTQzYjItYmU4ZS01OWFkNzVjY2I0MWUiLCJwcmV2aWV3TmFtZSI6Ik11bHRpLUFwcCBtb2RlIFN1cHBvcnQgdXNpbmcgSUFSTSBkaWFncmFtLmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU1MTAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
The below diagram depicts that how multi-app designed in RDK.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNDk0IiwiZGlhZ3JhbU5hbWUiOiJSREstRGV2aWNlU2V0dGluZ3MtT3ZlcnZpZXcuZHJhd2lvIiwiYXNwZWN0IjoiIiwibGlua3MiOiJhdXRvIiwiY2VvTmFtZSI6IkRldmljZSBTZXR0aW5ncyIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjgwODI0NTEsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI4MDgyNDUxLCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiYTI2NDA0MjUtYjBlYS00ZGU3LTk0YzgtMjQyN2JlMzU0NDEyIiwicHJldmlld05hbWUiOiJSREstRGV2aWNlU2V0dGluZ3MtT3ZlcnZpZXcuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTUxMDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
Device Settings Programming Guide
First we need to initialize the IARMbus and device manager, perform the required task making use of the API’s and and finally need to de-initialize the device manager and disconnect the IARMbus.
Simple use case to set the resolution
API Documentation
To know more about SoC/Application level APIs details use in RDK, refer the link Device Settings API Documentation
Overview
Digital Transmission Content Protection ("DTCP") technology protects high-value digital motion pictures, television programs and audio against unauthorized interception and copying in the home and personal environment (e.g., between a digital set top box and gateway or between a personal computer and a digital TV).
There are two gstreamer filter elements that are used for content encryption/decryption.
- DTCP Encrypt:
The "dtcpencrypt" is a gstreamer filter element which encrypts incoming MPEG 2 SPTS stream and pushes encrypted data to the source pad. DTCP encrypt requires initialization of DTCP libs done in RMF application (e.g Media Streamer) which includes creating socket and listening for AKE request, authenticate and send exchange key to Sink device upon DTCP request from sink EMO It support Authentication and Key Exchange (AKE) from DTCP client. It encrypts the video stream using DTCP Encryption Mode Indicator (EMI)
- DTCP Decrypt:
The "dtcpdecrypt" is a gstreamer filter element is used to decrypt the MPEG2 SPTS video streams. It performs Authentication and Key Exchange (AKE) to DTCP server.
DTCP Protection
A device enabled with DTCP determines whether it is connected to other devices that implement the DTCP protection technology. Content encoded for DTCP protection is encrypted and securely transmitted only to recording and display devices that implement DTCP. The content carries information indicating whether and to what extent the content may be copied.
All DTCP encryption and decryption uses common set of provided gstreamer elements, The gstreamer elements uses DTCP manager API. Each SoC provides binary DTCP encryption/decryption library to support the DTCP Manager API.
DTCP Disable Procedure for Gateway boxes
At first, please verify that the current build of the box supports to disable DTCP. If it's yes, follow the next steps
Copy rmfConfig.ini under /etc to /opt
- cp /etc/rmfconfig.ini /opt
Change value of this string "FEATURE.DTCP.SUPPORT" in /opt/rmfconfig.ini from TRUE to FALSE
- vi /opt/rmfconfig.ini
- Find FEATURE.DTCP.SUPPORT
- Change value of "FEATURE.DTCP.SUPPORT" from TRUE to FALSE
- Save and Exit
Create receiver_config.ini.user under /opt
- touch /opt/receiver_config.ini.user
- sync
Reboot
Edit receiver_config.ini.user under /opt
- echo enableDtcpIp=false > /opt/receiver_config.ini.user
- sync
Reboot
Check AV for the box once it's up. This step can manually check or use script as below.
DTCP Use Case: Live Playback using QAM Source
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMTQ2IiwiZGlhZ3JhbU5hbWUiOiJkdGNwLXVzZSBjYXNlLmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJEVENQIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjoyNjE4MTcxNiwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6MjYxODE3MTYsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEsIm1hY3JvSWQiOiIwNTQ1ZjQyMy1mNWZkLTRmOWYtOWNiMS05NTE2YjhiMTc0YTciLCJwcmV2aWV3TmFtZSI6ImR0Y3AtdXNlIGNhc2UuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTQ3MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
- In case of live stream, the HTTPReqHandler will receive a request from client box and the Media Streamer will sets an pipeline between QAM Source and HN Sink.
- QAM Src element receives the data from the tuner and sends to the HN Sink.
- In the client side another pipeline has created between HNSrc and MediaPlayerSink.
- HNSrc receive the incoming data from HNSink and feeds to the MediaPlayerSink for live playback.
- DTCP encryption and decryption are used for protecting contents over network.
DTCP Interface Specifications
Please refer to API Documentation for more details about API specifications.
References
Feature Summary
The HDMI_CEC API defines the ability to get connected HDMI devices, send messages to those devices, and to be notified when messages are received from HDMI devices.
HDMI-CEC is a protocol that provides high-level control functions between audio-visual devices connected over HDMI. CEC is a one-wire bidirectional serial bus based on industry-standard AV.Link protocol to perform control functions. All audio-visual sources are connected directly or indirectly to a display device as the ‘root’ in a tree-like structure.
- Send raw or formatted CEC messages on behalf of application
- Provide received CEC messages to registered application listener
- Get information about a device connected to HDMI input
- Autonomously handle subset of CEC messages
- Provide list of connected CEC capable device to application
- Send "Feature Abort" response if message is not handled autonomously by RDK and message is not handled by application listener
Device Applicability
This feature applies to the following devices:
Architecture Overview
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMTYyIiwiZGlhZ3JhbU5hbWUiOiJBcmNoaXRlY3R1cmUgb3ZlcnZpZXcuZHJhd2lvIiwiYXNwZWN0IjoiIiwibGlua3MiOiJhdXRvIiwiY2VvTmFtZSI6IkhETUkgQ0VDIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjoyNjE4MTcwNCwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6MjYxODE3MDQsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEsIm1hY3JvSWQiOiI0M2Y0MmIyNC04NDlhLTQ3OGItYTk4Ny03OTM3NGEwODJkZGMiLCJwcmV2aWV3TmFtZSI6IkFyY2hpdGVjdHVyZSBvdmVydmlldy5kcmF3aW8ucG5nIiwibGljZW5zZVN0YXR1cyI6Ik9LIiwic2VydmljZSI6IiIsImlzVGVtcGxhdGUiOiIiLCJ3aWR0aCI6Im51bGwiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2MTQ2OTQ1NDcwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
HDMI-CEC Profiles supported in RDK
Profiles | Description |
Discovery | Discover HDMI devices that support CEC and provide settop information to those devices |
Power | Synchronize settop power state with HDMI device power state |
Switching | Switch settop HDMI inputs to settop HDMI outputs |
Channel Change | Change channel on settop from HDMI device |
Audio | Control audio mute/volume on HDMI device from settop and vice versa |
User Input | Accept user input commands from HDMI device |
Component Impacts
CEC Protocol Library
- Translate application commands to CEC commands
- Receive CEC commands and provide to application listeners
- Autonomously respond to a subset of CEC messages
HDMI-CEC HAL
- Abstracts SoC HDMI-CEC driver from higher level components that means it will abstract SoC CEC library from CEC Protocol Library
- it allow transmits/receives HDMI-CEC messages
SoC CEC Driver
Service Manager
Device Settings HAL
Device Settings APIs that SoC vendors implement. It provides primitive and hardware specific implementation for each controllable aspect of the SoC. This level API is considered single-app mode only, even though its SoC implementation may potentially support multiple-app mode.
SoC Video Pipeline
How HDMI-CEC Works in RDK
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMTYwIiwiZGlhZ3JhbU5hbWUiOiJIRE1JLmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJIRE1JIENFQyIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjYxODE3MDQsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI2MTgxNzA0LCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiMTA0YWY4NzMtNTkzOC00ODcxLWFlM2EtMGJhOThlMjIyY2YxIiwicHJldmlld05hbWUiOiJIRE1JLmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU0NzAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
Application API Specification
Overall the RDK-CEC library offers 3 categories of application APIs,
HDMI-CEC Connection
- The Connection APIs allows application to transmit and receive raw data bytes (a.k.a. CEC Frame) that conforms to the HDMI-CEC specification.
- This is the only interface that the application can use to access CEC Bus.
HDMI-CEC Message and Frame Structure
- The Messages APIs allows application to encode high-level message constructs into CECFrame raw bytes, or decode CECFrame raw bytes into high-level message constructs.
HDMI-CEC Library Interface
- The Library APIs allows application to contrl how the CEC stack operates, such as adding logical address to the stack.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMTY0IiwiZGlhZ3JhbU5hbWUiOiJDb21wb25lbnRzIG9mIENFQyBMaWJyYXJ5LmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJIRE1JIENFQyIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjYxODE3MDQsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI2MTgxNzA0LCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiMTI2MGQyZDUtN2Q4NC00MGVkLTk0YTMtMmEzZDYyNDk0YWQzIiwicHJldmlld05hbWUiOiJDb21wb25lbnRzIG9mIENFQyBMaWJyYXJ5LmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU0NzAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
The Host interface allows libCEC implementation to interact with the host environment. Such interaction includes monitoring of the Power State change, the HDMI HotPlug events, or API to change the Host State. The Host Interface is delivered as a run-time plugin to the libCEC stack. This allows the CEC stack to run in any devices that implements the Host Interface.
The Driver Component access the HDMI-CEC SoC Driver via the CEC HAL API. The vendors are responsible in delivering a SoC Driver that conforms to the HAL API (see the header file hdmi_cec_driver.h)
HDMI-CEC Applications
The relation between Application, Connection and CEC-Bus is described in the figure.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMTY2IiwiZGlhZ3JhbU5hbWUiOiJBcHBsaWNhdGlvbi0xLmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJIRE1JIENFQyIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjYxODE3MDQsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI2MTgxNzA0LCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiNGZjNjcxZWEtMGFjNi00YzMwLWE5NWQtMzBkZTU0MDYxYmJmIiwicHJldmlld05hbWUiOiJBcHBsaWNhdGlvbi0xLmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU0NzAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
CEC Daemon
- This daemon receives Raw Bytes from the SoC Driver and dispatches them into IARM Bus via CecIARMMgr, it also receives Raw Bytes from IARM Bus and send to the SoC Driver. It controls the only access point to the physical HDMI CEC Bus.
Receiver
- This application receives Raw Bytes from IARM Bus and dispatch to Service Manager (which in turn may dispatch the bytes to Guide Application). It also receives Raw bytes from Service Manager and send to the IARM-Bus.
CECDevMgr
- This application is a "sniffer" on the CEC Bus. It monitors all messages on the bus and construct a Device Map, which depicts the topology of all connected devices on the CEC Bus. Other applications can be developed similar to Receiver or CECDevMgr where the CEC Raw bytes (in form of CECFrame) are send/receive to/from IARM Bus. This pseudo CEC Driver implemented on IARM Bus is called CEC IARM Adapter in the diagram.
HDMI CEC Messaging
The CECFrame is a byte buffer that provides access to raw CEC bytes. CECFrame is guaranteed to be a complete CEC Message that has the necessary data blocks:
The Header Data block (The byte that contains the initiator and destination address)
The OpCode Data Block (The byte that contains the opcode).
The Operand Data Block.(The bytes that contains the operands).
In most cases application need not access CECFrame directly, but manipulate the raw bytes through the Message API. The Message API allows the application to send or receive high-level CEC message construct instead of raw bytes. Basically for each CEC message (such as ActiveSource), there is a C++ class implementation representing it. Each message class provides necessary getter and setter methods to access the properties of each message.
Asynchronous Vs. Synchronous
When messages converge on the logical buses, they are queued for sending opportunities on the physical bus. The waiting time for such send to complete, though short in most cases, can be problematic to some interactive real-time applications. It is recommended that the applications always send CEC messages asynchronously via the Connection API and use the listener APIs to monitor response messages or device state changes. The CEC library offers abundant APIs to facilitate such asynchronous implementation and the application is encouraged to make full use of them.
Given the vast variance of HDMI-CEC support from the off-the-self media devices, it is not recommended that application wait for the response from a destination device. Even if the request message is sent out successfully, the destination device may choose to ignore the request. The recommended approach is again to send the request asynchronously and use the listener to monitor responses.
Overall, given the asynchronous nature of HDMI-CEC, application should always opt to use Asynchronous APIs as first choice. And for same reasons, the RDK CEC library offers only limited support for Synchronous APIs.
Multiple Application Support
Often , the application functionality (Record, Tune and Playback) is distributed across multiple components. In order for any component to have equivalent access to the HDMI-CEC bus, the library offers Multi-App support via IARM-Bus. This support is enabled by default, and can be disabled if desired.
In essence, there is only one physical CEC bus on a system. However, with the help of Connection, Logical CEC-Bus, and IARM-Bus, the CEC library can converge the CEC traffic from different Connections and Logical Buses before forwarding them to the single physical bus. This is illustrated by the diagram below.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMTY4IiwiZGlhZ3JhbU5hbWUiOiJtdWx0aS1BcHBsaWNhdGlvbi5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiSERNSSBDRUMiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjI2MTgxNzA0LCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjoyNjE4MTcwNCwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6IjdmZWIzNjBhLWVmYjktNDZkYS1iMTFmLTNiZGU1MjBiNWZjOSIsInByZXZpZXdOYW1lIjoibXVsdGktQXBwbGljYXRpb24uZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTQ3MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
In this diagram there are two applications (Receiver and CECDevMgr). Since both applications can only access the underlying physical CEC Bus via Connection API, they have no knowledge how the message are eventually delivered to the Physical Bus.
For both applications, its CEC messages flows from,
Connection --> Logical Bus--> CEC IARM Apaper--> IARM Bus---> (CECDaemonMain)
For CECDaemonMain, its CEC messages flows from,
IARM Bus --> CecIARMMgr --> Connection --> Logical Bus --> CEC Driver --> (Physical Bus)
The message flow on Connections and Logical Buses are full duplex.
Methods & Events
Following methods are used for DMI CEC module.
Name | Parameters | Description |
---|
setEnabled | enabled : boolean | Enables or disables CEC |
getEnabled | none | Returns true if CEC is enabled |
setName | name : string | Sets the name of the STB device. The default name is "STB". It is recommended that the name of the device is set prior to enabling CEC. |
getName | none | Returns the name of the STB device |
sendMessage | message : String | The message is a base64 encoded byte array of the raw CEC bytes. The CEC message includes the device ID for the intended destination. |
getCECAddresses | none | return the JSON object <CECAddresses> that is assigned to the local device. It does not contain the <CECAddresses> of other devices on the connected CEC network. |
"CECAddresses" : { "physicalAddress": Array of 4 bytes [byte0, byte1, byte2, byte3], "logicalAddresses" : Array of <CECLogicalAddress> } "CECLogicalAddress" : { "deviceType" : <string> "logicalAddress": <integer> } The deviceType returned is part or all of devices types optionally set by XRE. A CEC device can have multiple deviceTypes, if so an array of <CECLogicalAddress> with size more than one is returned. Default deviceType is Tuner, and its logical Address is either 3, 6, 7, or 10. In messages sent by XRE, XRE can only use the logicalAddress returned from CECAddresses. Accepted deviceType are: "Tuner", "Record", "Playback", "AudioSystem", "VideoProcessor", "Switch" |
Events notification:
Name | Content | Description |
---|
onMessage | message : String | Fired when a message is sent from an HDMI device. Message is a base64 encoded byte array of the raw CEC bytes. |
cecAddressesChanged | JSON object <CECAddresses> | Notify that address of the host CEC device has changed |
API Documentation
To know more about SoC/Application level APIs details use in RDK, refer the link RDK HDMI-CEC API Documentation
Overview
IARM-Bus is a platform agnostic Inter-process communication (IPC) interface. It allows applications to communicate with each other by sending Events or invoking Remote Procedure Calls. The common programming APIs offered by the RDK IARM-Bus interface is independent of the operating system or the underlying IPC mechanism.
Two applications connected to a same instance of IARM-Bus are able to exchange events or RPC calls. On a typical system, only one instance of IARM-Bus instance is needed. If desired, it is possible to have multiple IARM-Bus instances. However, applications connected to different buses will not be able to communicate with each other.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAwNjYwIiwiZGlhZ3JhbU5hbWUiOiJJQVJNIEJ1cyBBcmNoaXRlY3R1cmUuZHJhd2lvIiwiYXNwZWN0IjoiIiwibGlua3MiOiJhdXRvIiwiY2VvTmFtZSI6IklBUk0gQnVzIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjoyNjE4MTcyMiwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6MjYxODE3MjIsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEsIm1hY3JvSWQiOiJkMzE1MGJmMS05ODQwLTRhN2UtYmFmMC02NmMzM2Y0YjNiYTIiLCJwcmV2aWV3TmFtZSI6IklBUk0gQnVzIEFyY2hpdGVjdHVyZS5kcmF3aW8ucG5nIiwibGljZW5zZVN0YXR1cyI6Ik9LIiwic2VydmljZSI6IiIsImlzVGVtcGxhdGUiOiIiLCJ3aWR0aCI6Im51bGwiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2MTQ2OTQ1NDAwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
Bus Daemon
Each Bus Instance is managed by a single Bus Daemon Process. The Bus Daemon oversees the activities on the bus and manage common resources competed by all connected applications. Applications requesting a shared resource must firstly acquire from the Bus Daemon. Once it is done with the resource, it must release the ownership back to Bus Daemon so that other applications can use the resource. The IARM Bus Daemon offers standard APIs to request and release ownership of a resource. In Essence, a Bus Daemon itself is a regular applications connected to the IARM-Bus with special privileges. It is the only entity that has knowledge of all applications connected to the bus, and has the authority of granting or denying resources.
Well-Known Name
Each application that connected to the bus must identify itself with a unique name. This name is considered well-known in that it is used by other applications to send events or invoke RPC calls published by the application. The well-known name thus is considered part of the public API interface published by the application. The Bus daemon's well-known name is "Daemon".
An application's well-known name is only visible to the bus that it connects to. When concatenated with the IARM-bus name com.comcast.rdk.iarm.bus, it becomes the application's universally unique identifier.
Programming Guidelines
As explained above, IARM-Bus offers two basic functionalities:
An IARM Application that runs as a linux daemon process is considered a Manager Component. The IARM-Bus Daemon is a special Manager component that belongs to the IARM core. Such manager components normally register Events and RPC methods for other applications to use.
The directory under IARM should use this structure:
Directory | Files |
$iarm | IARM Core, IARM Bus Daemon, and all IARM Manager Components |
core | Core implementation of IARM framework. It is built into a shared library for all IARM applications to use. |
core/include | Public headers exposed by IARM core. IARM application should only reference header files located here to use IARM-Bus APIs. |
<mgr> | Manager's internal implementation. Header files listed here should NOT be referenced by any external components outside the <mgr> directory. |
<mgr>/include | Public headers exposed by the Manager. IARM applications uses the Manager's events or RPC methods should only reference header files located here. |
template | A Sample implementation of a IARM Manager Component. This provides a good starting point for developers to create their manager components. The developer can make a copy of the template and modify to suit their application needs. |
The IARM-Bus Library is ./core/libIARMBus.so. All IARM Applications must link to this library.
In this document we use the implementation of IR Manager as our example. The source code of IR Manager is available at iarm/ir/.
IR Manager is an application that publishes Remote Key events to other applications.
- IR manager sends these IR events to other applications.
- IARM_BUS_IRMGR_EVENT_IRKEY
- The Event Data contains Key Code and Key Type of the pressed IR key.
- IR manager publishes two RPC Methods:
- SetRepeatKeyInterval
- GetRepeatKeyInterval
- Other application can invoke these methods to determine how often a repeat key is sent when the IR key is held own by the user.
We will use IR Manager's implementation to illustrate how to use IARM-Bus APIs to publish, send, receive and handle Events, as well as publish and invoke RPC Methods.
This document explains the usage of IARM-Bus APIs by example. For a full API specification please refer to IARM's public header files or doxygen document.
How to Create, Send, and Receive Events
Since all the events published by the application are tied to its well-known name, the application must make its well-known name available to other applications that wish to use its service. The well-known name can be thought of as the Namespace within which the application's events and RPC methods live. This name must be declared in the application's public header file. In our example, this file is irMgr.h
#define IARM_BUS_IRMGR_NAME "IRMgr"
Naming Convention: IARM_BUS_<Manager>_NAME "Manager"
When the application initialize with IARM-Bus, it provides its well-known name:
IARM_Bus_Init(IARM_BUS_IRMGR_NAME);
IARM_Bus_Connect();
Applications should use the defined macro of the owner's well-known name (IARM_BUS_IRMGR_NAME in this example) when sending or listening for events.
Declare Event and Event Data in Header File
Considering the application's well-name as a namespace name, an Event ID is used to uniquely identify the Event within the namespace. The Event IDs must be declared in the application's public header file, using C Enumerations and must start with value 0.
typedef enum _EventId_t {
IARM_BUS_IRMGR_EVENT_IRKEY = 0,
IARM_BUS_IRMGR_EVENT_MAX
}
Naming Convention: IARM_BUS_<Manager>EVENT<Event Name>
_EVENT_MAX must have the value of (Number Of Events Published + 1). This MAX value is used when registering all events to the IARM –Bus.
An event may or may not have Event Data. If an event has event data, the data types must be declared so that the listeners of the events can process the data properly. The data structure should a union of event data for all events that the application would send. For example, IR Manager's IR Event Data contains a keyType and KeyCode field.
typedef struct _IRMgr_EventData_t {
union {
struct _IRKEY_DATA{
int keyType;
int keyCode;
} irkey, fpkey;
} data;
}IARM_Bus_IRMgr_EventData_t;
Naming Convention: IARM_Bus_<Manager>_EventData_t
Register Event to IARM-Bus
An Event must be Registered with IARM-Bus first before it can be sent out or listened to. The application that registers the event is considered the Owner of the event. During initialization, the owner can register all the events it will send to the bus.
Now that both the event and event data are declared, the application can register all its events to the IARM-Bus. Note how _EVENT_MAX constant is used here to register all events in a single call.
IARM_Bus_RegisterEvent(IARM_BUS_IRMGR_EVENT_MAX)
Send Event to IARM-Bus
Once the event is registered, the application can send events to the bus. The events are always broadcast on the bus. Only the applications listening to the event will be awakened. The sending application is responsible for allocating and freeing memory used to store event data. In most cases the memory can simply be allocated from stack.
To send an IARM_BUS_IRMGR_EVENT_IRKEY an IR whenever
IARM_Bus_BroadcastEvent(
IARM_BUS_IRMGR_NAME, /* Owner of the Event */
IARM_BUS_IRMGR_EVENT_IRKEY, /* Event ID from this owner */
(void *) &eventData, /* IARM_Bus_IRMgr_EventData_t */
sizeof(eventData) /* Length of the eventData */
)
Receive Event from IARM-Bus
Any application can listen for events from sent by other applications on the IARM-Bus. In our example, an application interested in receiving Remote Keys can register for IR Manager's IARM_BUS_IRMGR_EVENT_IRKEY event. When receiving events, a handler must be supplied to process the event. This handler will be called from IARM's internal thread context.
IARM_Bus_RegisterEventHandler(
IARM_BUS_IRMGR_NAME, /* Owner of the Event */
IARM_BUS_IRMGR_EVENT_IRKEY, /* Event ID from this owner*/
_My_Event_Handler, /* IARM_EventHandler_t */
)
An application can listen for different event with different event handlers. If a same event handler is used to listen for different events from different applications, a simple switch block can be used to further dispatch the events to their target processing.
- use strcmp() to dispatch event by the sending application's name.
- use switch to dispatch event by Event Id.
The event handler in our example would contain the following block to dispatch IR key events:
_My_Event_Handler(const char *owner, IARM_EventId_t eventId, void *data, size_t len)
{
…
/* Dispatch By Owner first */
if(strcmp(owner, IARM_BUS_IRMGR_NAME) == 0) {
/* Then Dispatch by Event ID */
switch(eventID) {
case IARM_BUS_IRMGR_EVENT_IRKEY:
/*Cast data to its target type */
IARM_Bus_IRMgr_EventData_t * = (IARM_Bus_IRMgr_EventData_t *) data;
/* Processing of Data */
…
}
}
else if(strcmp(owner, /some other application/) == 0) {
}
else {
}
}
Summary Of Events
If an application wants to Send events, it needs to
- Follow the naming conventions recommended.
- Register to IARM-Bus with its well-known name during initialization.
IARM_Result_t IARM_Bus_Init(const char name);
IARM_Result_t IARM_Bus_Connect(void);
- Declare its event enumerations and event data types in public header file.
- Register all its events during initialization using _EVENT_MAX:
IARM_Result_t IARM_Bus_RegisterEvent(IARM_EventId_t maxEventId);
IARM_Result_t IARM_Bus_BroadcastEvent(const char *ownerName, IARM_EventId_t eventId, void *data, size_t len);
If an application wants to receive and handle events , it needs to :
- Register to IARM-Bus with its well-known name during initialization.
IARM_Result_t IARM_Bus_Init(const char *name);
IARM_Result_t IARM_Bus_Connect(void);
IARM_Result_t IARM_Bus_RegisterEventHandler(const char *ownerName, IARM_EventId_t eventId, IARM_EventHandler_t handler);
How to Create and Invoke RPC Methods
Since all the RPC methods published by the application are tied to its well-known name, the application must make its well-known name available to other applications that wish to use its service. The well-known name can be thought of as the Namespace within which the application's events and RPC methods live. This name must be declared in the application's public header file. In our example, this file is irMgr.h
#define IARM_BUS_IRMGR_NAME "IRMgr"
Naming Convention: IARM_BUS_<Manager>_NAME "Manager"
When the application initialize with IARM-Bus, it provides its well-known name:
IARM_Bus_Init(IARM_BUS_IRMGR_NAME);
IARM_Bus_Connect();
Applications should use macro of the well-known name (IARM_BUS_IRMGR_NAME in this example) when invoking the RPC method.
Declare RPC Method Names and Argument Types in Header File
Considering the application's well-name as a namespace name, Method name is used to identify the RPC method within the namespace. Each method from a same owner has unique string name. This name must be declared in the application's public header file, so other applications can refer to this method by its method name.
In our example, IR Manager publishes two RPC Methods, that allow other applications to set and get Repeat Key Intervals. The method name is defined as:
#define IARM_BUS_IRMGR_API_SetRepeatInterval "SetRepeatInterval"
Naming Convention: IARM_BUS_<Manager>API<Method> "Method"
Applications should use macro of the method name (IARM_BUS_IRMGR_API_SetRepeatInterval in this example) when invoking the RPC method.
A RPC method is like a regular method in its declaration. It may or may not have input or output arguments. If a RPC method has any input or output argument, the data types must be declared so that other applications can invoke the method properly. The data structure should be a C structure that includes both input and output parameters.
In our example, IR Manager declares this data structure as argument type for the SetRepeatInterval method.
typedef struct _IARM_Bus_IRMgr_SetRepeatInterval_Param_t {
unsigned int timeoutNewValue; /* Used when invoking RPC */
unsigned int timeoutOldValue; /* Used to hold return value */
} IARM_Bus_IRMgr_SetRepeatInterval_Param_t;
Naming Convention: IARM_BUS_<Manager>_<Method>_Param_t
This method has an input parameter and an output parameter. It is equivalent to a non-RPC function with signature:
SetRepeatInterval (uint timeoutNewValue, uint *{}timeoutOldValue);
The RPC implementation will place the old value into the storage allocated for timeoutOldValue prior to function return.
Register RPC Methods to IARM-Bus
A RPC Method must be Registered with IARM-Bus first before it can be invoked. The application that registers the RPC method is considered the Owner of the method. During initialization, the application can register all the RPC methods it implements
IARM_Result_t IARM_Bus_RegisterCall(
_BUS_IRMGR_API_SetRepeatInterval, /* RPC Method Name */
_SetRepeatInterval /* RPC Method Implementation*/*
)
Here _SetRepeatInterval () is the actual implementation of the RPC method. All RPC methods takes the signature of IARM_BusCall_t:
typedef IARM_Result_t (*IARM_BusCall_t) (void *arg);
The owner of the RPC Method provides its implementation. In irMgr.c, the implementation takes the following form:
static IARM_Result_t _SetRepeatInterval(void *arg)
{
/* First cast the argument to its target type */
IARM_Bus_IRMgr_SetRepeatInterval_Param_t
*param = (IARM_Bus_IRMgr_SetRepeatInterval_Param_t *)arg;
/* do something */
/* populate the output fileds of param */
}
Invoke RPC Method
Once an RPC is registered, other application can invoke the method synchronously. For example, this invocation sets the key repeat interval to 200ms.
IARM_Bus_IRMgr_SetRepeatInterval_Param_t param;
param. timeoutNewValue = 200;
IARM_Bus_Call (
IARM_BUS_IRMGR_NAME, /* Owner of the Method */
IARM_BUS_IRMGR_API_SetRepeatInterval,/* Name of Method */
(void *)¶m, / Parameter of Method */
sizeof(param)); /* Length of the Parameter */
)
Summary of RPC Methods
In summary, if an application wants to publish RPC Methods, it needs to
- Follow the naming conventions recommended.
- Register to IARM-Bus with its well-known name during initialization.
IARM_Result_t IARM_Bus_Init(const char name);*
IARM_Result_t IARM_Bus_Connect(void);
- Declare its RPC method names and argument types in public header file:
- Register all its RPC methods during initialization:
IARM_Result_t IARM_Bus_RegisterCall(const char *name, IARM_BusCall_t handler);
IARM_Result_t IARM_Bus_Call(const char *ownerName, const char *methodName, void *arg, size_t argLen);
Decouples Applications from IARM
The RPC methods exposed via IARM can be called by multiple applications, so they are also named Multiple-App APIs. In contract, the regular C functions that can only be invoked from within the same Linux process that implements the C functions are named Single-App APIs. Sometimes, it is desirable that the application is decoupled from such API difference. In this case, the developer should provide a generic API that can be linked to either a local C method or a RPC method at build time.
In our example, IR Manager exports RPC API "SetRepeatInterval". To invoke this method, the application executes:
IARM_Bus_Call (
IARM_BUS_IRMGR_NAME, /* Owner of the Method */
IARM_BUS_IRMGR_API_SetRepeatInterval, /* Name of Method */
(void *)¶m, / Parameter of Method */
sizeof(param)); /* Length of the Parameter */
)
This invocation injects the IARM dependency into the application. An alternative is to provide the application a generic API IRMgr_SetRepeatInterval(), whose implementation internally invokes the RPC method.
IRMgr_SetRepeatInterval(int newInterval)
{
IARM_Bus_IRMgr_SetRepeatInterval_Param_t param;
param.timeoutNewValue = 200;
IARM_Bus_Call (
IARM_BUS_IRMGR_NAME, /* Owner of the Method */
IARM_BUS_IRMGR_API_SetRepeatInterval,/* Name of Method */
(void *)¶m, / Parameter of Method */
sizeof(param)); /* Length of the Parameter */
)
}
Short-Term Approach
To invoke the same API, application now calls IRMgr_SetRepeatInterval().
A quick approach to decouple application from IARM is to define the generic API IRMgr_SetRepeatInterval() as inline function. In our example, we would include this in the irMgr.h.
#define IRMgr_SetRepeatInterval(newInterval) \
do {
IARM_Bus_IRMgr_SetRepeatInterval_Param_t param;
param. timeoutNewValue = 200;\
IARM_Bus_Call (
IARM_BUS_IRMGR_NAME,\ /* Owner of the Method */
IARM_BUS_IRMGR_API_SetRepeatInterval,\/* Name of Method */
(void *)¶m,\/ Parameter of Method */
sizeof(param));\/* Length of the Parameter */
)
}while(0);
In this approach, the application is decoupled from IARM. However, application cannot use the same API for Single-App version. This may be enough for most applications who at this point does not need a single-app version of the same API.
Long-Term Approach
If an application may use the same API's single-app version, the following changes are needed.
To invoke the same API, application now calls IRMgr_SetRepeatInterval(), which must be implemented as an actual function that has external linkage.
IRMgr_SetRepeatInterval(int newInterval)
{
IARM_Bus_IRMgr_SetRepeatInterval_Param_t param;
param. timeoutNewValue = 200;
IARM_Bus_Call (
IARM_BUS_IRMGR_NAME, /* Owner of the Method */
IARM_BUS_IRMGR_API_SetRepeatInterval,/* Name of Method */
(void *)¶m, / Parameter of Method */
sizeof(param)); /* Length of the Parameter */
)
}
In the IR Manager's implementation of RPC Method, we have already learned from previous sections that this RPC method is registered with.
IARM_Result_t IARM_Bus_RegisterCall(
_BUS_IRMGR_API_SetRepeatInterval, /* RPC Method Name */
_SetRepeatInterval /* RPC Method Implementation*/
)
Where _SetRepeatInterval changes the actual settings.
static IARM_Result_t _SetRepeatInterval(void *arg)
{
/* First cast the argument to its target type */
IARM_Bus_IRMgr_SetRepeatInterval_Param_t
*param = (IARM_Bus_IRMgr_SetRepeatInterval_Param_t *)arg;
/* changes actual settings here */
}
With generic API IRMgr_SetRepeatInterval(), we can change the _SetRepeatInterval implementation to:
static IARM_Result_t _SetRepeatInterval(void *arg)
{
/* First cast the argument to its target type */
IARM_Bus_IRMgr_SetRepeatInterval_Param_t
*param = (IARM_Bus_IRMgr_SetRepeatInterval_Param_t *)arg;
IRMgr_SetRepeatInterval(parma->newInterval);
}
Where IRMgr_SetRepeatInterval()changes the actual settings.
Now, we have at our hands two implementations of a same generic API IRMgr_SetRepeatInterval:
The RPC Client / Multi App Version:
IRMgr_SetRepeatInterval(int newInterval)
{
IARM_Bus_IRMgr_SetRepeatInterval_Param_t param;
param. timeoutNewValue = 200;
IARM_Bus_Call (
IARM_BUS_IRMGR_NAME, /* Owner of the Method */
IARM_BUS_IRMGR_API_SetRepeatInterval, /* Name of Method */
(void *)¶m, /* Parameter of Method */
sizeof(param)); /* Length of the Parameter */
)
}
This function is linked into library libirMgrCli.so
The Manager Version/Single-App version:
IRMgr_SetRepeatInterval(int newInterval)
{
/* Change the Actual Settings */
}
This function is linked into library libirMgr.so
The application can then choose which implementation to link to at build time based on its needs. To use the multi-app version of API, the application links to libirMgrCli.so. To use the single-app version of the API, the application links to libirMgr.so. In either choice, the application is no longer coupled to IARM. The following diagrams demonstrate the linkage relationship between applications and the generic API.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAwOTM4IiwiZGlhZ3JhbU5hbWUiOiJJQVJNIFB1Ymxpc2hlciBhbmQgTGlzdGVuZXJzIENvbmNlcHQgRmxvdyBEaWFncmFtLmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJJQVJNIEJ1cyIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjYxODE3MjIsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI2MTgxNzIyLCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiOTQ1NDQ2ZGItNzVmNS00NDk1LThiOGYtYmQ1NGI5MGUwNjFiIiwicHJldmlld05hbWUiOiJJQVJNIFB1Ymxpc2hlciBhbmQgTGlzdGVuZXJzIENvbmNlcHQgRmxvdyBEaWFncmFtLmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU0NDAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
Porting layer of IARM-Bus
Most IARM Applications are not Manager Components. Rather they are connected to IARM bus only to utilize the service provided by various IARM-Bus Managers. These applications can maximum their platform independency by interfacing to only the common APIs of the IARM Bus.
Meanwhile, depending on the events being published or the dependency that an RPC method implementation may have, some part of an IARM Manager Component may be platform specific.
It is up to the developer of the manager component to craft out and abstract the platform specific portion of the manager implementation. In the IR Manager example we used, the manager receives IR signals from PIC drivers in different ways on different platforms. This difference is abstract to a PLAT_API interface defined in an internal header file plat.h, and allows most of IR Manager implementation to remain platform agnostic.
Core IARM-Bus Manager Components
By default, the IARM-Bus has the following Manager Components. The published events and RPC methods from these manager components can be found in their public header files.
On a standard system, you should see the following 3 processes running before executing your own application.
- IARMDaemonMain
- irMgrMain
- pwrMgrMain
To see the IARM managers available in the device. Use the below command,
ps -aef|grep Mgr*
root 462 1 0 05:07 ? 00:00:02 /usr/bin/mfrMgrMain
root 1195 1 0 05:07 ? 00:00:02 /usr/bin/sysMgrMain
root 1240 1 0 05:07 ? 00:00:02 /usr/bin/dsMgrMain
root 1343 1 1 05:07 ? 00:06:01 /usr/bin/irMgrMain
root 1545 1 0 05:07 ? 00:00:02 /usr/bin/pwrMgrMain
root 1593 1 0 05:07 ? 00:00:02 /usr/bin/deepSleepMgrMain
Bus Daemon
Executable name is IARMDaemonMain. The IARM Bus Daemon is a Manager Component with special privileges.
IR Manager
Executable name is irMgrMain. This manager receives IR signals from driver and dispatch it to all registered listeners on IARM Bus. The standard IR key codes sent by IR Manager are listed in core/ir/comcastIRKeyCodes.h.
Power Manager
Executable name is pwrMgrMain. This manager monitors Power IR key events and react to power state changes based on RDK Power Management Specification. It dispatches Power Mode Change events to IARM-Bus. All listeners should releases resources when entering POWER OFF/STANDBY state and reacquire them when entering POWER ON state.
Troubleshooting
Before you try out a new IARM-Application, please make sure the following components are properly running on your box:
- libIARMBus.so is at a known library path.
- Daemon process IARMDaemonMain is running.
API Documentation
To know more about SoC/Application level APIs details use in RDK, refer the link IARM BUS API Documentation
Overview
IARM (Inter Application Resource Management) is a mechanism for inter-process communication among different RDK applications. Its a platform agnostic inter process communication (IPC) mechanism for the other RDK components. The inter communication is possible between IARM application using events and RPC method.
IARM-Bus offers two basic functionalities:
- Send Events to application.
- Invoke application's RPC methods.
An IARM Application that runs as a linux daemon process is considered a Manager Component. The IARM-Bus Daemon is a special Manager component that belongs to the IARM core. Such manager components normally register Events and RPC methods for other applications to use.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNDMwIiwiZGlhZ3JhbU5hbWUiOiJBcmNoaXRlY3R1cmUuZHJhd2lvIiwiYXNwZWN0IjoiIiwibGlua3MiOiJhdXRvIiwiY2VvTmFtZSI6IklBUk0gTWFuYWdlciIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjYxODE3MjQsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI2MTgxNzI0LCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiOWM4YWFhNDctZmUzZC00N2Y4LWEzZjctMmYxMmVjYjNlMDQ2IiwicHJldmlld05hbWUiOiJBcmNoaXRlY3R1cmUuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTUxMDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
Basically there are three IARM entities involved for development
- IARM Bus
- IARM Application (Consumers/Listeners)
- IARM Manager (Publishers)
IARM Bus
- Invoke methods in other processes via Remote Procedure Call.
- Send inter-process messages.
- Manage shared and exclusive access to resources.
- Register for event notification.
- Publish Event notification to registered listener.
- There are two ways for application to use IARM Bus ie 'Subscribe for system events' and 'Invoke RPC Methods'
IARM Application
- IARM Application utilize the IARM utilities and it register for event notification.
- For example, IR Application registering for the events and the same event appears in the IARM Bus so that the notification of the IARM Bus event shall be transfer to the IARM Bus application.
- IARM application can also invoke the RPC method which has been registered by the other IARM process.
IARM Manager
- IARM Manager is an IARM Application that runs as Linux daemon process.
- The IARM Bus Daemon is a Manager Component with Special privileges to manage resources.
- The Other IARM Manager components include Power Manager, IR Manager, Disk Manager, Sys Manager, DS Manager, etc
IARM Publisher and Listeners Concept
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNDI4IiwiZGlhZ3JhbU5hbWUiOiJGbG93IERpYWdyYW0uZHJhd2lvIiwiYXNwZWN0IjoiIiwibGlua3MiOiJhdXRvIiwiY2VvTmFtZSI6IklBUk0gTWFuYWdlciIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjYxODE3MjQsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI2MTgxNzI0LCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiOGRmMDUxMDktMDU4MC00MmY3LTkzZmQtNjZiZWNhNTgyNTJkIiwicHJldmlld05hbWUiOiJGbG93IERpYWdyYW0uZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTUwMDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
IARM Manager modules
API Documentation
To know more about SoC/Application level APIs details use in RDK, refer the link IARM MANAGER API Documentation
Overview
Injected bundle is an Integration layer between Service Manager and the player in RDK Browser and WPE.
- Adds an ability to send messages from JavaScript to UI side and vice versa.
- Supports ACL for the JavaScript objects.
The JS Bridge consists of 2 parts:
- execution backend (written in C++)
- client interface to execution backend (this one)
Each part consists of 2 layers:
- object interface (methods calls)
- general messaging (serialized messages)
Each method call JS => C++ is serialized into JSON, trasfered via IPC,
received on another side, mapped into the corresponding method call.
So, the route is:
C++ JS
------------------- -------------------
object interface < < object interface
------------------ | |-------------------
general messaging | | general messaging
------------------ | |-------------------
IPC <===< IPC
Responses and events are transferred in opposite direction (C++ => JS)
Implementation Details
How to Expose C/C++ API using injectedbundle
- Define an Injectedbundle CB that's invoked when a page is loaded
Define an object of WKBundlePageLoaderClientV1 with your own function callback for didCommitLoadForFrame. This callback gets invoked when a page's DOM contens finishes loading. This will also provide the mainFrame instance in which the JS object is to be loaded.
WKBundlePageLoaderClientV1 client {
{1, clientInfo},
// Version 0.
nullptr, // didStartProvisionalLoadForFrame;
nullptr, // didReceiveServerRedirectForProvisionalLoadForFrame;
nullptr, // didFailProvisionalLoadWithErrorForFrame;
didCommitLoad, // didCommitLoadForFrame;
nullptr, // didFinishDocumentLoadForFrame;
nullptr, // didFinishLoadForFrame;
nullptr, // didFailLoadWithErrorForFrame;
nullptr, // didSameDocumentNavigationForFrame;
nullptr, // didReceiveTitleForFrame;
nullptr, // didFirstLayoutForFrame;
nullptr, // didFirstVisuallyNonEmptyLayoutForFrame;
nullptr, // didRemoveFrameFromHierarchy;
nullptr, // didDisplayInsecureContentForFrame;
nullptr, // didRunInsecureContentForFrame;
nullptr, // didClearWindowObjectForFrame;
nullptr, // didCancelClientRedirectForFrame;
nullptr, // willPerformClientRedirectForFrame;
nullptr, // didHandleOnloadEventsForFrame;
// Version 1.
nullptr, // didLayoutForFrame
nullptr, // didNewFirstVisuallyNonEmptyLayout_unavailable
nullptr, // didNewFirstVisuallyNonEmptyLayout_unavailable
nullptr,
nullptr, // globalObjectIsAvailableForFrame
nullptr, // globalObjectIsAvailableForFrame
nullptr, // didReconnectDOMWindowExtensionToGlobalObject
nullptr // willDestroyGlobalObjectForDOMWindowExtension
};
- void didCommitLoad(WKBundlePageRef page, WKBundleFrameRef frame) // WKBundleFrameRef frame provides the JS context in which to load JS/C++ bindings
void didCommitLoad(WKBundlePageRef page, WKBundleFrameRef frame)
{
JSGlobalContextRef context = WKBundleFrameGetJavaScriptContext(frame);
LoadJS(context);
}
- Using the context obtained from frame you can load custom JS objects, but first you need to define a JS class definition which provides a standard set of callbacks and properties for the JS object
typedef struct {
int version; /* current (and only) version is 0 */
JSClassAttributes attributes;
const char* className;
JSClassRef parentClass;
const JSStaticValue* staticValues;
const JSStaticFunction* staticFunctions;
JSObjectInitializeCallback initialize;
JSObjectFinalizeCallback finalize;
JSObjectHasPropertyCallback hasProperty;
JSObjectGetPropertyCallback getProperty;
JSObjectSetPropertyCallback setProperty;
JSObjectDeletePropertyCallback deleteProperty;
JSObjectGetPropertyNamesCallback getPropertyNames;
JSObjectCallAsFunctionCallback callAsFunction;
JSObjectCallAsConstructorCallback callAsConstructor;
JSObjectHasInstanceCallback hasInstance;
JSObjectConvertToTypeCallback convertToType;
} JSClassDefinition;
The important parameters for any JS object are staticValues, staticFunctions which helps to implement JSObject.property (get/set) and JSObject.function()
You may find more about the structure of JSStaticValue and JSStaticFunction in JSObjectRef.h
- Once the class and corresponding callbacks are defined, you may load this object onto the context that is retrieved from the frame object in injectedbundle
static const JSClassDefinition JS_class_def;
void LoadJS(JSGlobalContextRef context)
{
//Create a custom object that holds the context and any other variables that are required, for eg- seesion keeping var.
struct CustomObject* obj = new CustomObject();
JSClassRef classDef = JSClassCreate(&JS_class_def);
JSObjectRef classObj = JSObjectMake(context, classDef, obj);
JSObjectRef globalObj = JSContextGetGlobalObject(context);
JSStringRef str = JSStringCreateWithUTF8CString("JSObject"); //If you would like to name your object as JSObject and access like JSObject.property
JSObjectSetProperty(context, globalObj, str, classObj, kJSPropertyAttributeReadOnly, NULL); //this loads the JSObject to page
JSClassRelease(classDef);
JSStringRelease(str);
}
- Once the page is loaded, you may add an event listenet for onDOMContentLoaded and verify if the JSObject is defined ( if(typeof global.JSObject !== "undefined" {console.log ("JSObject available")})
How to Invoke a JS API from C/C++
- Pass the JS API function pointer to Native code and store it as a JSObjectRef
JSObject.addEventListener(eventType, eventListener) //with eventListener having a definition like "function eventListener(event: any) {....}"
static JSValueRef addEventListener(JSContextRef context, JSObjectRef function, JSObjectRef thisObject, size_t argumentCount, const JSValueRef arguments[], JSValueRef *exception)
{
JSObjectRef callbackObj = JSValueToObject(context, arguments[1], NULL);
if (callbackObj != NULL && JSObjectIsFunction(context, callbackObj))
{
//Store the callbackObj in a variable
eventListener = callbackObj;
JSValueProtect(context, callbackObj);
}
else
{
return JSValueMakeUndefined(context);
}
return JSValueMakeNull(context);
}
Overview
The LED Manager is an application that is responsible for controlling the LEDs on the product. Manages the STB front panel color LED to communicate the system status. It initializes the LED hardware and exposes functionality to the rest of the system via iarm events and calls.The LED manager has knowledge of the physical layout of the LED's and organizes them into logical groups. The LED's can be controlled individually or as a group according to the product requirements. The LED manager can be programmed with pre-defined animations which are exposed to the rest of the system via iarm bus calls.
The high level state diagram for the LED manager process is shown below.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMjUwIiwiZGlhZ3JhbU5hbWUiOiJsZWRNZ3IgUHJvY2VzcyBTdGF0ZSBEaWFncmFtLmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJMRUQgTWFuYWdlciIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjYxODE2NTcsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI2MTgxNjU3LCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiMjkxZTk0YzYtNjc4My00NWRhLTkxYTYtNjA5MzRhYmI1MWQ5IiwicHJldmlld05hbWUiOiJsZWRNZ3IgUHJvY2VzcyBTdGF0ZSBEaWFncmFtLmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU0ODAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
Ledmgr stack contains generic and device specific code. Device specific implementation is in 'extended' folder which has device specific lighting specification. There is a noop implementation provided which can be referred by OEM vendors to implement device specific 'extended' folder.
API Specification
LED Manager API specification is available in the Doxygen page: LED Manager API Specifications
Repo Path :
https://code.rdkcentral.com/r/rdk/components/generic/ledmgr
Supports USB detection and control functionality to enable USB detection and control from application. This ensures that the USB port works as expected before using peripherals and capabilities that use the USB port.
Functionality
- Support for USB hot plug detection & Control from service manager module
- Notifies application via Service Manager when device is connected to USB port, including device type (and make / model if available).
- Provides software control via Service Manager to enable/disable USB port.
- Allows multiple USB devices to connect via USB hub.
- Upon initialization, libusbctrl scan the existing devices and start monitor hotplug events.
Sample Control Flow
- usbctl is loaded. It initializes data structures to store callbacks.
- App calls registerCallback()
- App calls init()
- usbctrl initializes internal data structures.
- usbctrl launches hotplug monitoring task.
- usbctl enumerates all usb_interface device types and assigns a unique number to each interface.
- Each interface is entered into a list of structs. Each struct has the unique identifier and the interface-specifier
- usbctrl launches callback for each interface with "add" event.
- Callback is allowed to internally call other usbctrl APIs to get properties.
- When a getProperty() call is received, usbctrl compares unique identifier against its internal data structures and validates.
- if unique identifier is valid,
- if property is defined by interface, return that.
- if property is not defined by interface, iterate up the USB hierarchy to find one that does and return the value.
- App calls term()
- usbctrl stops monitoring of hotplug events.
- usbctrl clears data structures storing callbacks and usb_interfaces.
Media player is resident on devices that render to a local sink. It handles all the controlling functionality of the current pipeline. It handles all presentation, scaling, decoder, demux, PID remapping, closed captions and Trick-play controls.
This component provides 3 major functionalities,
- Wi-Fi: Manage the Wi-Fi network by connecting to AP (Access Point) and provide the notification to the application. Generally it is called as Wi-Fi Network Manager.
- Route : Discover and manage the network route for data communication.
- MoCA: Managing MoCA services.
Wi-Fi Network Manager
Wifi- network manager, which takes several responsibility for managing Wifi in Video device
- It dynamically detect the Network interfaces, send notifications to subscribers
- Supports diagnostics both local and cloud based applications
- Setup and update the network routes based on priorities, wifi connection status, availability, etc
- It also Listen to home networking updates to determine the routes for which communication to be established in outside world
- It provide Modular approach to add/remove new network interface types and also provide support for configuring routing rules
Lets see how network manager works when a RDK device boots up, On bootup, network service manager reads a configuration file to check what all network interfaces are supported on current set-top box and accordingly it initializes and bring-up the corresponding subsystems such as wifi, moca, or Ethernet. It also sets the telemetry parameters such as logging interval and decide what information need to be logged according to the configuration sets by the user.
The WIFI Manager API provides support to client applications that wish to enable WIFI communications on a STB.
- It Provide API to Initialize the wifi driver and runs the linux wireless daemon
- Provides API to configure WiFi SSID and password, it is required for video device to to connect to the Access Point.
- It provide facility to immediately try to connect to WiFi network with provided SSID and password when API is invoked.
- It also Provides response to caller to indicate whether or not WiFi network connection was successfully established.
- Provides API to clear previously configured SSID and password.
- Stores/Saves WiFi SSID and password in persistent memory, which will help in automatically connecting to the AP after box reboots.
- Enumerates via API the available broadcasting SSIDs.
- Wifi Manager automatically tries to connect to paired Wifi network on startup
Another important feature of the network manager is to notify other application or other listeners when a major event occurs with the Wi-Fi sub-system
Here the event may of following types.
- Any state change that either the state changed from Connected to Disconnected or Vice Versa.
- when settop boots with WiFi capability.
- when WiFi network is successfully established.
- when connection to WiFi network is lost.
- when WiFi driver failure is detected.
- By notifying about all the discussed events, it helps the other application to do some decision making or display some information in the screen.
- For example, when a video is being played from internet and in-between wireless connection is lost.
- In this case the video player will receive a disconnection event from the network manager and can show on screen error message.
Wi-Fi Network Manager - IARM Event & Calls
Lets see how the event notification mechanism works. Basically all the event related activity are done through a D-Bus messaging extension known as IARM. In our case the network manager will register few event names and their corresponding event handler function. When an application is interested to receive that event, he will be register as a listen to that event. Whenever the event occurs all the register listener that are connected to IARM will be able to receive the notification.
IARM Call | Descriptions |
IARM_BUS_WIFI_MGR_API_getAvailableSSIDs | Retrieves the List of available APs |
IARM_BUS_WIFI_MGR_API_getConnectedSSID | Returns the properties of the currently connected SSID |
IARM_BUS_WIFI_MGR_API_setEnabled | Enable the WIFI adapter on the box |
IARM_BUS_WIFI_MGR_API_connect | Connect with given or saved SSID and passphrase |
IARM_BUS_WIFI_MGR_API_getConnectionType | Retrieves the type based on active network interface |
IARM_BUS_WIFI_MGR_API_getRadioStatsProps | Retrieve the get radio stats properties |
IARM Call implementation:
- In the above table we can see that for each of the possible Wi-Fi Events, we have defined a IARM Call.
- For example, we have some remote procedure calls, which can be invoked from any application to perform some Wi-Fi related operation.
- These operation may be to get the list of available network or to connect to a particular Wi-Fi network, etc.
IARM Events Notificaiton:
Basically we have 2 types of events for Wifi Manager notifications.
State change notifications events:
- WIFI_CONNECTING : When a connection is initiated the state will change from IDEAL to CONNECTING.
- WIFI_FAILED : When a connection attempt is failed.
- WIFI_DISCONNECTED : When a AP is disconnected from client.
- WIFI_CONNECTED : This will be notified after a successful connection.
Error events:
API Specification
Network Service Manager API specification is available in the Doxygen page: netsrvmgr API Specifications
RDK Browser
Summary
The RDK Browser is a fully functional web browser built into the RDK which allows RDK Set-top Boxes to browse and display 3rd party web pages/apps. The currently deployed RDK Browser is a port of QTWebkit. A future version based on WebkitForWayland is being developed, as QTWebkit is no longer supported.
Webkit and QtWebkit
Webkit is an open source Apple layout engine for rendering HTML and HTML5 in web browsers, based on KHTML and KJS by KDE. It was originally written to work on the Qt cross-platform application framework, but was made toolkit independent by Apple when they took over the development, which they later open-sourced. Primarily written in C++, but with some added Apple Objective-C message/calls, Webkit provides a set of classes to display web content in layout windows, and implements browser features such as hyperlinks, and the navigation of forward and backward within the history.
QtWebkit is a port of Apple's Webkit which utilizes the functionality of the Qt cross-platform application framework, while including the improvements Apple made from the original KHTML and KDE. The RDK platform uses Qt in other areas, such as the Receiver. The version of Webkit used in the RDK version of the browser is 537.21 (as reported by Javascript).
Webkit is a well-known standard for browsers.
Browser | Rendering Engine |
---|
Chrome | Webkit 537.36 |
Safari | WebKit 601.2.7 |
Edge | WebKit 537.36 |
Firefox | Gecko/20100101 (iOS version uses Webkit 602.1.50 |
RDK QTWebkit Browser | Webkit 537.21 |
Mobile Browser | Rendering Engine |
---|
Chrome (Android) | Webkit 537.36 |
Chrome (iOS) | Webkit 602.1.50 |
Firefox (Android) | Gecko/20100101 |
Firefox (iOS) | Webkit 602.1.50 |
References
Wikipedia: WebKit
QT Webkit
HTML Support
Supported Features
- HTTPS
- Redirects
- HTTP Cookies (limited support, in-memory only)
- Javascript
- Clipboard (copy-paste)
- Webgl (experimental)
- HTML5 Canvas
- CSS3 (http://css3test.com/ 48% score)
- CSS3 downloadable fonts
- Websockets
- audio tag (aac, mp3)
- video tag (h.264)
- Flash Player 11.1
Unsupported HTML Features
- uploading files: type=file of input tag
- downloading files
- popup windows
Limitations
There are no software codecs. Hardware support is limited in a number of processing units, which is one processing unit per a video stream and one processing unit per an audio stream.
Flash Plugin Support
Supported Features
- Flash Plugin 11.1
- SWF (Flash 11.1)
- Video should be limited to H.264 due to presence of hardware decode and rendering support
- HW decoded video is displayed in a hardware video plane behind the Flash content. Flash content can composite on top of the video. But flash content cannot be composited below video. There is no support for transparency within the video stream.
- Other Flash video formats are supported but may not perform adequately due to lack of hardware support.
- Image file formats are Progressive JPEG, and PNG
- Supported audio codecs are MP3, ADPCM, Nellymoser, Speex and AAC.
Limitations
There are no software codecs. Hardware support is limited in a number of processing units, which is one processing unit per a video stream and one processing unit per an audio stream.
Comparison of QTWebkit CSS Features to other browsers
The following is a comparison of the CSS features offered by some of the standard browsers, and the RDK QtWebkit. With the exception of Firefox and IE, the rest of the browsers are all based off of Webkit. A breakdown of the actual features missing can be found in the appendices. These tests are based on the site: http://css3test.com/
Comparison of RDK QTWebkit HTML5 features to other browsers
The following is a comparison of the HTML features offered by some of the standard browsers, and the RDK QtWebkit. With the exception of Firefox and IE, the rest of the browsers are all based off of Webkit. A breakdown of the actual features missing can be found in the appendices. These tests are based on the site: https://html5test.com/
Video playback, MSE and EME
RDK QTWebkit supports Media Source Extensions (MSE) and Encrypted Media Extensions (EME).
The version of MSE supported is: MSE Spec Version: 10 December 2013 (conformance results here)
Google MSE conformance test used:
http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/2016.html?enablewebm=off×tamp=1480519673236
Currently only EME version 0.1b is supported. Playready is currently the only DRM supported.
DRMs supported by RDK QtWebkit EME
DRM | SUPPORTED |
---|
Playready | YES |
Widevine | NO |
ClearKey | NO |
Axinom | NO |
AES-128 | Not natively, may be supported by a specific player |
Codecs supported by RDK QTWebkit
Mime Type / Codec | Description |
---|
video/mp4;codecs="avc1.42E01E, mp4a.40.2" | H.264 Simple baseline profile video (main and extended video compatible) level 3 and Low-Complexity AAC audio in MP4 container |
video/mp4;codecs="avc1.58A01E, mp4a.40.2" | H.264 Extended profile video (baseline-compatible) level 3 and Low-Complexity AAC audio in MP4 container |
video/mp4;codecs="avc1.4D401E, mp4a.40.2" | H.264 Main profile video level 3 and Low-Complexity AAC audio in MP4 container |
video/mp4;codecs="avc1.64001E, mp4a.40.2" | H.264 'High' profile video (incompatible with main, baseline, or extended profiles) level 3 and Low-Complexity AAC audio in MP4 container |
video/ogg;codecs="theora, vorbis" | Theora video and Vorbis audio in Ogg container |
audio/ogg;codecs=vorbis | Vorbis audio alone in Ogg container |
video/mp4; codecs="avc1.42E01E" | H.264 baseline in MPEG-4 container |
audio/mp4; codecs="mp4a.40.2" | AAC low-complexity in MPEG-4 container |
audio/mpeg;codecs="mp3" | Audio mp3 |
video/webm; codecs="vorbis,vp8" | WebM with VP8 video and Vorbis |
Codecs NOT supported by RDK QTWebkit
Mime Type / Codec | Description |
---|
application/x-mpegurl | HLS x-mpegurl |
application/vnd.apple.mpegurl | HLS vnd.apple.mpegurl |
video/mp4;codecs="mp4v.20.8, mp4a.40.2" | MPEG-4 Visual Simple Profile Level 0 video and Low-Complexity AAC audio in MP4 container |
video/mp4;codecs="mp4v.20.240, mp4a.40.2" | MPEG-4 Advanced Simple Profile Level 0 video and Low-Complexity AAC audio in MP4 container |
video/3gpp;codecs="mp4v.20.8, samr" | MPEG-4 Visual Simple Profile Level 0 video and AMR audio in 3GPP container |
video/ogg;codecs="theora, speex" | Theora video and Speex audio in Ogg container |
audio/ogg;codecs=speex | Speex audio alone in Ogg container |
audio/ogg;codecs=flac | FLAC audio alone in Ogg container |
video/ogg;codecs="dirac, vorbis" | Dirac video and Vorbis audio in Ogg container |
video/x-matroska;codecs="theora, vorbis" | Theora video and Vorbis audio in Matroska container |
Remote Web Inspector
The RDK browser has a hidden feature called "Remote Web Inspector." This features sends information to a remote browser for debugging purposes.
Setting up the STB to use RWI
The STB and Computer/Laptop/Terminal which is displaying the information must be on the same network for Remote Web Inspector to work. There are several ways to accomplish this:
1) Use a Moca to Ethernet bridge. This is the easiest solution. The bridge provides an IP address with which to connect to the STB using it's Moca IP address, without requiring it to obtain a local one.
2) If the STB is a dev box, it is sometimes possible to connect both Computer and STB to a hub, and connect through the local network. DHCP must be enabled on the STB so it may obtain it's own IP address, if this is the case.
3) If you have access to the STB with root access, you can connect it to a that is also connected to a PC, and then use the "ifconfig eth0 x.x.x.x" command to give the STB an IP address that is on the same network as the PC
If you can ping the PC from the STB, you have a good connection (make sure your PC doesn't ignore pings, of course).
Connecting to Remote Web Inspector
Now that everything else is set up, you can connect to the RWI. Open up either Safari or Chrome > v 5.5 and browse to the following address: http://<ESTB_IP_ADDR>:9222
If 9222 doesn't work, try port 9223
A link may be presented, if so, click on it, and you're in!
Overview
rdkbrowser2 is the browser application based on WPE, it is integrated with following components which enables it with new features compared with legacy rdkbrowser.
- injectedBundle : Provides integration Layer for Service manager and Player inside WPE, adds ability to send messages between JavaScript & other application.
- pxcore-libnode : pxcore - Provides a lightweight Frame-buffer library, pxscene - 2D scene graph API library.
- wpe-webkit : WebKit porting which is used with Wayland.
- rdk-logger : Provides console and file level message logging feature to RDK component.
- westeros : Wayland compositor library that allows applications to create their own Wayland displays, which allows nesting and embedding of third party application
How to Launch rdkbrowser2 ?
rdkbrowser2 can be launched in two different ways:
Server Mode: --server - Launch the browser in a server(“tab”) mode
It could be directly launched as:
/usr/bin/rdkbrowser2 --server
Also can launch _rdkbrowser2_server.sh, script file to run rdkbrowser2 as a server.
Standalone mode: --url <url> - Launch opening a specific URL
web pages could be launched using rdkbrowser2 by passing the URL.
/usr/bin/rdkbrowser2 --url http://www.google.com
Architecture Diagram
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAwNjU4IiwiZGlhZ3JhbU5hbWUiOiJyZGticm93c2VyMl9hcmNoaXRlY3R1cmUuZHJhd2lvIiwiYXNwZWN0IjoiIiwibGlua3MiOiJhdXRvIiwiY2VvTmFtZSI6InJka2Jyb3dzZXIyIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjo3MTAxNDIxNSwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6NzEwMTQyMTUsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEsIm1hY3JvSWQiOiI2MWZmZDhlOC1iYTc1LTRiMmQtOTEzZS1iYTA1ODMyZDA1ZTYiLCJwcmV2aWV3TmFtZSI6InJka2Jyb3dzZXIyX2FyY2hpdGVjdHVyZS5kcmF3aW8ucG5nIiwibGljZW5zZVN0YXR1cyI6Ik9LIiwic2VydmljZSI6IiIsImlzVGVtcGxhdGUiOiIiLCJ3aWR0aCI6Im51bGwiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2MTQ2OTQ1NDAwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
Webkit : Thin layer to link against from the applications .
WebCore : Provides rendering, layout, network access, multimedia, accessibility support etc.
JavaScript Core : Javascript engine.
Platform : Provides platform-specific hooks to implement generic algorithms.
rdkbrowser2 Controls
rdkbrowser2-control is an app for discovering RDKBrowser2 RtRemote Server Object and invoking its RtRemote based API.
Only works in conjunction with /usr/bin/rdkbrowser2.sh
Usage:
start rdkbrowser2: /usr/bin/rdkbrowser2.sh 'about:blank'
start /usr/bin/rdkbrowser2-control in a separate shell
Sample control sequence:
rdkbrowser2tab = rt.locate()
rdkbrowser2tab.transparentBackground = false
rdkbrowser2tab.proxies = [ { "pattern" : "*" , "useproxy" : "http://<ip>:<port>" }]
rdkbrowser2tab.url = "https://www.google.com/"
rdkbrowser2tab.evaluateJavaScript( "startTest()" )
|
This provides HTML diagnostic clients which can be used for Hybrid Gateway devices as well as IP clients. It also supports retrieving diagnostic values over a TR-069 interface for devices where snmp support is not present (IP client devices). Also additional diagnostic screens to monitor MOCA devices are available.
HTML based diagnostic screens will send a JSON request to the Lighttpd server. This request is converted to a corresponding SNMP trigger or a TR-69 request to retrieve the data and send it back as a JSON response to the HTML client.
Capabilities
- Handle HTTP gets from Diagnostics Application.
- Retrieve data from SNMP and/or TR-069 Clients.
Feature Summary
Diagnostic Parameters (example)
Parameter | SNMP MIB | TR-069 Object |
---|
MoCA Enable/Disable Status | mocaIfEnable | Device.MoCA.Interface.{i}.Enable |
Firmware Version | ocStbHostSoftwareFirmwareVersion | SoftwareVersion |
LAN IP Address |
| Device.IP.Interface.{i}.IPv4Address.{i}.IPAddress |
State Variables
RDK will signal state variable transitions to application, and application will present the corresponding error messages to the user if necessary.
Diagnostics using SNMP
A glance on SNMP
- Simple Network Management Protocol (SNMP) is an Internet-standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behaviour.
- SNMP is the opensource component which is integrated with RDK.
- “snmpd” is the snmp agent which is running in the box.
- All MIBS are available in /usr/share/snmp/mibs/
SNMP MIB
SNMP agents maintains a database describing the managed device parameters.
Manager uses this database to request the agent to retrieve specific information and further translates the information as needed for the network mangement system .
Agent and Manager shares MIB
MIBs comprises of managed object identified by the name Object Identifier (OID).
SNMP mibs starts with 1.3.6.1.2.1
SNMP Diagnostics
- SNMP queries are used to fetch the details from the box which will be displayed in the “Diagnostics” page
- SNMP is used only in “hybrid” box types and not in client boxes.
- Client boxes use TR069 protocol for fetching diagnostic details.
Steps to display Diagnostics page in PC Browser
Copy lighttpd config file from /etc to /opt
cp /etc/lighttpd.conf /opt/
Modify config file to show the page in browser.
vi /opt/lighttpd.conf
Comment below line
server.bind = "127.0.0.1"
Execute below command
ps -ef| grep "/usr/sbin/lighttpd" | grep -v "grep" | awk '{print $2}' | xargs kill -9 >& /dev/null;/usr/sbin/lighttpd -D -f /opt/lighttpd.conf &
Use below url in the browser to see diagnostics page
http://<hybrid box lan ip address>:50050/htmldiag/summary_info.html
eg: http://192.168.160.83:50050/htmldiag/summary_info.html
Note: Use TAB, SHIFT+TAB and ENTER keys to browse through this page
SNMP queries through command line
- SNMP queries can be executed command line to fetch the details
- Execute below commands in the box console to see the output of the query
Example 1: Querying card binding status
snmpwalk -OQ -v 2c -c public 127.0.0.1 OC-STB-HOST-MIB::ocStbHostCardBindingStatus.0
Expected Output :
It shows that card is not authenticated for paid channels
Example 2: To check signal strength
snmpwalk -v 2c -c public 127.0.0.1 OC-STB-HOST-MIB::ocStbHostInBandTunerTable
Example 3: For HDMI status returned by TV
snmpwalk -OQ -v 2c -c public 127.0.0.1 OC-STB-HOST-MIB::ocStbHostDVIHDMITable
Diagnostics using TR069
- TR069 queries are used to fetch the details from the box which will be displayed in the “Diagnostics” page
- TR069 is used only in “client” box types and not in hybrid boxes.
- Hybrid boxes use SNMP protocol for fetching diagnostic details.
Steps to display Diagnostics page in PC Browser
Copy lighttpd config file from /etc to /opt
cp /etc/lighttpd.conf /opt/
Modify config file to show the page in browser.
vi /opt/lighttpd.conf
Comment below line
server.bind = "127.0.0.1"
Execute below command
ps -ef| grep "/usr/sbin/lighttpd" | grep -v "grep" | awk '{print $2}' | xargs kill -9 >& /dev/null;/usr/sbin/lighttpd -D -f /opt/lighttpd.conf &
Use below url in the browser to see diagnostics page
http://<client box lan ip address>:50050/htmldiag/summary_info.html
eg: http://192.168.160.34:50050/htmldiag/summary_info.html
TR-069 queries through command line
Example 1: To fetch number of entries in the HDMI table
curl -d '{"paramList" : [{"name" : "Device.Services.STBService.1.Components.HDMI.1.Status"}]}' http://127.0.0.1:10999
Example 2: To fetch Human-readable name associated with this video decoder
curl -d '{"paramList" : [{"name" : "Device.Services.STBService.1.Components.VideoDecoder.1.Name"}]}' http://127.0.0.1:10999
Example 3: To fetch the device total cpu usage
curl -d '{"paramList" : [{"name" : "Device.DeviceInfo.ProcessStatus.CPUUsage"}]}' http://127.0.0.1:10999
Steps to display Diagnostics page in PC Browser
RDK Logger is a common logging library which is based on MPEOS logging & it uses log4c for formatting and supports multiple log levels
RDK Logger Capabilities
- Abstracts logging client from underlying logging utility.
- Dynamically enables/disables logging level at run time.
- Provides logging format that complies with the existing OCAP format (e.g. <timestamp> [mod=*, level=*]).
- Controls log level independently for each component/module.
- Enables logging globally via single configuration value.
- Controls initial log level for each component/module from configuration file (debug.ini) at startup.
- Prints formatted data to stdout.
- Separates logs into separate files based on "SEPARATE.LOGFILE.SUPPORT" configuration variable
Architecture
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNjE4IiwiZGlhZ3JhbU5hbWUiOiJSREtfTE9HR0VSX0FSQ0hJVEVDVFVSRS5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiUkRLIExvZ2dlciIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MTU4OTI1MjUsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjE1ODkyNTI1LCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiM2U1YzNmODctNDQ1NS00OGU5LWI2OWEtYWNhM2NkYjM3NDYyIiwicHJldmlld05hbWUiOiJSREtfTE9HR0VSX0FSQ0hJVEVDVFVSRS5kcmF3aW8ucG5nIiwibGljZW5zZVN0YXR1cyI6Ik9LIiwic2VydmljZSI6IiIsImlzVGVtcGxhdGUiOiIiLCJ3aWR0aCI6Im51bGwiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2MTQ2OTQ1NTMwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
Log4c – Introduction & Terminology:
- Framework which provides the capability to log messages in a variety of formats to console or local file
- Configuration - Log4c can be configured using a configuration file
- log4crc keeps configurations in xml format
- Configurations can be provided for modules, sub modules etc.
- Loggers - Named log message destinations which are known to applications.
- Appenders - Responsible for delivering LogEvents to their destination.
- Layouts & Filters determine how the message is formatted & filter the messages according to the configuration.
Logging Levels supported by RDK Logger
Code | Description |
---|
RDK_LOG_FATAL | Any error that is forcing a shutdown of the service or application to prevent data loss (or further data loss), reserve these only for the most heinous errors and situations where there is guaranteed to have been data corruption or loss. |
RDK_LOG_ERROR | Any error which is fatal to the operation but not the service (cant open a file, missing data, etc) |
RDK_LOG_WARN | Anything that can potentially cause application oddities, but for which the application automatically recovering. |
RDK_LOG_NOTICE | Anything that largely superfluous for application-level logging. |
RDK_LOG_INFO | Generally useful information to log (service start/stop, configuration assumptions, etc). |
RDK_LOG_DEBUG | Information that is diagnostically helpful to people more than just developers. |
RDK_LOG_TRACE1, RDK_LOG_TRACE2,... | Only when it would be "tracing" the code and trying to find one part of a function specifically. |
How to initialize RDK Logger
- rdk_logger_init() loads entries from “debug.ini” and initializes log4c.
- Sets log level of the module corresponding to environment variables.
- Sets log level to default log levels, for the modules not having entries in configuration file. (Currently it is set as LOG.RDK.DEFAULT = ERROR in debug.ini)
How to add the logger functionality to the new module?
Include rdk_debug.h header file and make use of RDK_LOG for printing logs. Initialize RDK Logger by calling rdk_logger_init() in the respective module/component. Build new module/component by linking "librdkloggers.so" along with "liblog4c.so" and "libglib-2.0.so" shared object.
Example: -lrdkloggers -L ../opensource/lib -llog4c -lglib-2.0
RDK_LOG (rdk_LogLevel level, const char *module, const char *format,...)
- "level" is Log level of the log message (FATAL, ERROR etc). Apart from this there are special log levels like ALL, NONE, TRACE, !TRACE are supported.
- "module" is the Module to which this message belongs to (Use module name same as mentioned in debug.ini)
- "format" is a printf style string containing the log message.
All the RDK components logs are stored under /opt/log/ with a naming convention <RDK component>="">_log.txt.
For example, /opt/log/pod_log.txt includes all events logged by POD Manager module.
Sample code for Logging
For example, add a debug messages for "INBSI" module
RDK_LOG (RDK_LOG_NOTICE, "LOG.RDK.INBSI","<%s: %s>: Sending PMT_ACQUIRED event\n", PSIMODULE, __FUNCTION__);
User needs to provide the module name "LOG.RDK.INBSI", which is the same as mentioned in debug.ini
$ cat debug.ini
EnableMPELog = TRUE
LOG.RDK.INBSI = ALL FATAL ERROR WARNING NOTICE INFO DEBUG
Sample logging output
131011-21:21:49.578394 [mod=INBSI, lvl=NOTICE] [tid=4141] <SITP_PSI: NotifyTableChanged>: Sending PMT_ACQUIRED event
In this way, user make use of the RDK logger in the respective modules and control the logging levels through configuration file. Here, No need to build RDK logger again for the addition of new components/module.
How to use logging in G-Streamer
A callback function gst_debug_add_log_function() is registered to receive GStreamer logs. Logs are converted to RDK logs in callback function. RMF element which controls a gst-element shall register element name and corresponding log module using
void RMF_registerGstElementDbgModule(char *gst_module, char *rmf_module)
Callback function uses this information to get module names corresponding to gstreamer logs.
RDK Logging Configuration
Default level for RDK logging is ERROR and logging settings are configured in /etc/debug.ini. RDK components reads the configuration details from config file at the beginning.
LOG.RDK.<component1> = FATAL ERROR WARNING NOTICE INFO
LOG.RDK.<component2> = FATAL ERROR WARNING NOTICE INFO DEBUG
For Example:
LOG.RDK.UI = NONE
LOG.RDK.QAMSRC = ALL FATAL ERROR
LOG.RDK.VODSRC = ALL FATAL ERROR WARNING NOTICE INFO
LOG.RDK.MS = ALL FATAL ERROR WARNING INFO
LOG.RDK.GSTQAM = ALL FATAL ERROR WARNING INFO
LOG.RDK.IPPV = ALL FATAL ERROR WARNING NOTICE INFO
LOG.RDK.RMFBASE = FATAL ERROR WARNING INFO
LOG.RDK.TRM = ALL FATAL ERROR WARNING NOTICE INFO
Which path logs are stored
By default, stdout is redirected to /opt/logs/ocapri_log.txt for OCAP RI related logs.
RDK Log upload Process
Logs are uploaded to servers in following scenarios
- When the box is rebooted
- When an on-demand log request is made
- When a regular nightly job is set up for the log uploads
the script uploadSTBLogs.sh is responsible for uploading the logs to the server. Logs are uploaded as tar files with sufficient information like Mac ID, date , timestamp. Log can be uploaded to server using scp or tftp protocol as per server requirement.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNjE2IiwiZGlhZ3JhbU5hbWUiOiJSREsgTG9nIHVwbG9hZCBQcm9jZXNzLmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJSREsgTG9nZ2VyIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjoxNTg5MjUyNSwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6MTU4OTI1MjUsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEsIm1hY3JvSWQiOiI5YzQ3Nzk0Ni05Y2I1LTQxOTYtYTY0OS1jNmU1N2VkMGE1NmUiLCJwcmV2aWV3TmFtZSI6IlJESyBMb2cgdXBsb2FkIFByb2Nlc3MuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTUzMDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
API Documentation
To know more about SoC/Application level APIs details use in RDK, refer the link RDK LOGGER API Documentation
Overview
RDK services are a set of JSON-RPC services that provide access to the RDK core components on set-top devices. RDK services are implemented as Thunder plugins for the Thunder framework. The Thunder framework is responsible for, among other things, managing plugins and handling client requests. RDK services are invoked over HTTP or Web Sockets using their JSON-RPC services-based interface. This makes RDK services accessible to any client that can process JSON, such as Lightning JavaScript applications or HTML5 web applications. For native applications, you can also invoke RDK services directly using C/C++ native code.
Documentation
The open-source component of RDK Services is developed within the rdkcentral organization on GitHub. For further information and API references, you can refer to the RDK Services project website . The below table provides a list of RDK Services plugins along with their corresponding GitHub links.
Some RDK components contain RDK services that are separately developed as part of their project. Refer to the each component repository, respectively:
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IkFzaHJhZiBCaGFudSBLb3RoYXBldGEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiQXNocmFmIEJoYW51IEtvdGhhcGV0YSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMjEzNjAzMjA1IiwiZGlhZ3JhbU5hbWUiOiJSREsgVFYgSERNSUlucHV0IENvbXBvc2l0ZUlucHV0IC0gSGlnaCBMZXZlbCBBcmNoaXRlY3R1cmUiLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiUkRLIFRWIEhETUlJbnB1dC9Db21wb3NpdGVJbnB1dCIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjEzNjAyODQ0LCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjoyMTM2MDI4NDQsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjIsIm1hY3JvSWQiOiIxYThlOTgwYS1kZmI1LTQ2OTUtYTJjMy0xYWMwNmZjN2FiZjgiLCJwcmV2aWV3TmFtZSI6IlJESyBUViBIRE1JSW5wdXQgQ29tcG9zaXRlSW5wdXQgLSBIaWdoIExldmVsIEFyY2hpdGVjdHVyZS5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoiOTU2Iiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjYxMzE4ODA3MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IkFzaHJhZiBCaGFudSBLb3RoYXBldGEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiQXNocmFmIEJoYW51IEtvdGhhcGV0YSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMjEzNjAzNDEwIiwiZGlhZ3JhbU5hbWUiOiJNb3Rpb24gRGV0ZWN0aW9uIEhpZ2ggTGV2ZWwgQXJjaGl0ZWN0dXJlIiwiYXNwZWN0IjoiIiwibGlua3MiOiJhdXRvIiwiY2VvTmFtZSI6IlJESyBUViBNb3Rpb25EZXRlY3Rpb24iLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjIxMzYwMjg0OCwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6MjEzNjAyODQ4LCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiYTI2MmY5ZjAtNjAwZC00MTZmLThmOWMtOWJkMDc4ZGM5YTEzIiwicHJldmlld05hbWUiOiJNb3Rpb24gRGV0ZWN0aW9uIEhpZ2ggTGV2ZWwgQXJjaGl0ZWN0dXJlLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiI5NTMiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2NjEzMjA1NTkwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IkFzaHJhZiBCaGFudSBLb3RoYXBldGEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiQXNocmFmIEJoYW51IEtvdGhhcGV0YSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMjEzNjAzNDYyIiwiZGlhZ3JhbU5hbWUiOiJUViBBdWRpbyBTZXR0aW5ncyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJSREsgVFYgQXVkaW8gc2V0dGluZ3MiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjIxMzYwMjg1NSwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6MjEzNjAyODU1LCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiZjJmYjU1M2ItOWU2My00NTU3LThhNmEtNjFiNzQwNDVjOWQyIiwicHJldmlld05hbWUiOiJUViBBdWRpbyBTZXR0aW5ncy5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoiMTA0MSIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTY2MTMyODY3MTAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IkFzaHJhZiBCaGFudSBLb3RoYXBldGEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiQXNocmFmIEJoYW51IEtvdGhhcGV0YSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMjEzNjAzNDc4IiwiZGlhZ3JhbU5hbWUiOiJSREsgVFYgQXVkaW8gc2V0dGluZ3MgU29mdHdhcmUgc3RhY2siLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiUkRLIFRWIEF1ZGlvIHNldHRpbmdzIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjoyMTM2MDI4NTUsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjIxMzYwMjg1NSwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6IjAwZGMyNDU0LTY5ZTctNDMyNi04ZjUxLWE5MTc3ZDUxYjdiMyIsInByZXZpZXdOYW1lIjoiUkRLIFRWIEF1ZGlvIHNldHRpbmdzIFNvZnR3YXJlIHN0YWNrLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiI2NjIiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2NjEzMzMzNzUwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
TV CEC & ARC/eARC Features and Functionalities
TV CEC Features:
- One Touch Play
- Routing Control
- System Standby
- Power Status
- System Audio Control
- ARC Control
- Remote Control Passthrough
TV ARC/eARC Functionalities:
- Audio device type detection
- Audio device power state synchronisation
- Audio routing control
- Digital Audio output mode configuration
CEC Sink & ARC/eARC – Software stack
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IkFzaHJhZiBCaGFudSBLb3RoYXBldGEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiQXNocmFmIEJoYW51IEtvdGhhcGV0YSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMjEzNjAzNTQ3IiwiZGlhZ3JhbU5hbWUiOiJSREsgVFYgQ0VDIFNpbmsgYW5kIEFSQyBlQVJDIFNvZnR3YXJlIHN0YWNrIiwiYXNwZWN0IjoiIiwibGlua3MiOiJhdXRvIiwiY2VvTmFtZSI6IlJESyBUViBDRUMgXHUwMDI2IEFSQy9lQVJDIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjoyMTM2MDI4ODQsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjIxMzYwMjg4NCwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MiwibWFjcm9JZCI6IjllNDQ1OTQzLWUxNGItNGFkNi05NDQ2LTZkN2M5OGU1OTkzMiIsInByZXZpZXdOYW1lIjoiUkRLIFRWIENFQyBTaW5rIGFuZCBBUkMgZUFSQyBTb2Z0d2FyZSBzdGFjay5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoiOTEyIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjYxMzQ1MTE1MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IkFzaHJhZiBCaGFudSBLb3RoYXBldGEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiQXNocmFmIEJoYW51IEtvdGhhcGV0YSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMjEzNjAzNTcyIiwiZGlhZ3JhbU5hbWUiOiJQaWN0dXJlIFNldHRpbmdzIOKAkyBTb2Z0d2FyZSBzdGFjayIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJSREsgVFYgUGljdHVyZSBTZXR0aW5ncyIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjEzNjAyOTA0LCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjoyMTM2MDI5MDQsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEsIm1hY3JvSWQiOiJkMzA3YzQ0NC04ZTA0LTRiNjMtYWU5NS01NWM4NGU5OGUzODYiLCJwcmV2aWV3TmFtZSI6IlBpY3R1cmUgU2V0dGluZ3Mg4oCTIFNvZnR3YXJlIHN0YWNrLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiI4ODIiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2NjEzNDY5NjYwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
Parameters
- RDK TV Settings thunder module provides RESTFULL thunder APIs to get/set/reset following picture settings parameters. All parameters below except aspect ratio can be changed individually for every picture modes.
- Backlight
- Brightness
- Contrast
- Color temperature
- Contrast
- Dolby modes bright and dark.
- Hue
- Saturation
- Sharpness
- Dimming modes
- Aspect ratio
- Custom white balance
- Component Hue/Saturation/Luma
Customization
- Application of every picture setting parameters can be customized for every product based on the following rules as specified in /etc/tvproduct_config.ini file.
- Format classification
- 0 = Applies for all Content Formats.
- 1 = Applies to current content format only.
- 2 = Applies for current Content Format Group SDR or HDR (HDR10/HDR10+/HLG/DV) only.
- 3 = Applies to DV Content format only
- 4 = Applies for all content formats except Dolby
- 5 = Applies to HDR10 content format only
- 6 = Applies to HLG content format only
- Mode Classification
- 0 = Applies for all viewing modes.
- 1 = Applies for current viewing mode.
Customization example of few parameters (/etc/tvproduct_config.ini )
[set] | Description
|
---|
backlight_format = 2 | Changing backlight applies for current Content Format Group SDR or HDR (HDR10/HDR10+/HLG/DV) only. |
backlight_mode = 0 | Changing backlight applies for all picture modes |
aspectratio_format = 0 | Changing aspect ratio applies for all Content Formats |
aspectratio_mode = 0 | Changing aspect ratio applies for all picture modes |
autobacklight_format = 0 | Changing auto backlight applies for all Content Formats |
autobacklight_mode = 0 | Changing auto backlight applies for all picture modes |
dvmode_format = 3 | Changing dolby vision mode applies to DV Content format only |
dvmode_mode = 0 | Changing dolby vision mode applies for all picture modes |
sharpness_format = 2 | Changing sharpness applies for current Content Format Group SDR or HDR (HDR10/HDR10+/HLG/DV) only. |
sharpness_mode = 1 | Changing sharpness applies for all picture modes |
[reset] |
|
backlight_format = 0 | Resetting backlight applies for all Content Formats |
backlight_mode = 0 | Resetting backlight applies for all picture modes |
aspectratio_format = 0 | Resetting aspect ratio applies for all Content Formats |
aspectratio_mode = 0 | Resetting aspect ratio applies for all picture modes |
autobacklight_format = 0 | Resetting auto backlight applies for all Content Formats |
autobacklight_mode = 0 | Resetting auto backlight applies for all picture modes |
dvmode_format = 3 | Resetting dolby vision mode applies to DV Content format only |
dvmode_mode = 0 | Resetting dolby vision mode applies for all picture modes |
sharpness_format = 0 | Resetting sharpness applies for all Content Formats |
sharpness_mode = 1 | Changing sharpness applies for all picture modes |
- Once initialized, the RDK TV Settings thunder module activates itself, providing an interface to the TV application for changing picture setting parameters.
- For any changes to picture setting parameters, the TV application invokes the set thunder APIs and passes the values to be set as parameters. RDK TV Settings thunder module follows the rules set in /etc/tvproduct_config.ini file to apply the value.
- The last set value for any picture setting parameter can be queried by the TV Application using getThunder APIs. The returned value will always be for the current content format being played and the current picture mode selected.
- If the TV application decides to reset to default, the corresponding reset APIs can be invoked, and the TV Settings module will use default values for the product and apply them following the rules set in /etc/tvproduct_config.ini file.
- RDK TV Settings will be merged with RDK Display Settings as one RDK Thunder implementation named RDK Control Settings.
- RDK Control settings will no longer have product-specific customization capability. It will be handled either in the TV application as business rules or TV Settings HAL as platform specific customization.
- RDK Control settings will expose Thunder APIs for picture settings parameters that can be modified for any TV picture mode, any content format (SDR/HDR/DV) and any sources (HDMI, Composite, IP etc.,)
- RDK Control settings to be more generic, more scalable, easier addition of features, standardized API formats, standardized persistent model, and easy maintenance.
generate_si_cache
RDK SI Cache Converter is a tool to convert the the given SI Cache file from binary to XML format or vice versa based on the specified mode. This tool helps to enhance the existing channel map to support the development activities at locations where Comcast head-end connectivity is not available. This tool uses Libxml2 XML toolkit (http://xmlsoft.org/) for all XML related operations.
Operation modes:
- xtob - Generate SI Cache binaries from the given XML file
- btox - Generate SI Cache XML file from the given binary file
- dump - Dump channel map from the given binary file to console
- input: Input file. It can be an XML file or a binary SI Cache file depending on the operation mode
- output: Output file. It can be a binary SI Cache file or an XML file depending on the operation mode
- sioutput: Binary SI Cache file to be generated. To use this option, the mode should be set to 'xtob'
- snsoutput: Binary SNS Cache file to be generated. To use this option, the mode should be set to 'xtob'
- version: Prints the tool's version details
- help: Prints this user's manual
Examples:
Command to generate binary SI cache from given XML file:
./generate_si_cache -mode xtob -input si.xml -output SICache
Command to generate both binary SI cache and binary SNS cache from given XML file"
./generate_si_cache -mode xtob -input si.xml -sioutput SICache -snsoutput SNSCache
Command to generate XML file from binary SI cache
./generate_si_cache -mode btox -input SICache -output si.xml
Command to dump channel map from binary SI cache to console
./generate_si_cache -mode dump -input SICache
tenableHDCP
A utility for enabling and disabling HDCP (High-bandwidth Digital Content Protection).
API Specification
RMF_Tools API specification is available in the Doxygen page: RMF_Tools Streamer API Specifications
| Tool | Repo Path | Description |
1 | analyzers/scripts/target | rdk/components/generic/sys_mon_tools/analyzers/scripts/target | Target analyzer scripts that support system monitoring |
2 | hostdataconverter | rdk/components/generic/sys_mon_tools/hostdataconverter | A data conversion tool that runs on the host and supports system monitoring |
3 | iarm_event_sender | rdk/components/generic/sys_mon_tools/iarm_event_sender | IARM Event sender. Send IARM events with event name and event status. |
4 | iarm_query_powerstate | rdk/components/generic/sys_mon_tools/iarm_query_powerstate | IARM power state query module supporting system monitoring. |
5 | iarm_set_powerstate | rdk/components/generic/sys_mon_tools/iarm_set_powerstate | IARM power state control module supporting system monitoring. |
6 | key_simulator | rdk/components/generic/sys_mon_tools/key_simulator | Key Simulator. Send key codes with repeat number and interval |
7 | mfr_utils | rdk/components/generic/sys_mon_tools/mfr_utils | Manufacturer utilities. Get information about current running image name, current flashed image name, current PDRI Version etc |
8 | power-state-monitor | rdk/components/generic/sys_mon_tools/power-state-monitor | Power state monitoring. For monitoring power state mode changes. |
9 | rdklogctrl | rdk/components/generic/sys_mon_tools/rdklogctrl | When executed, rdklogctrl broadcast (IARM_Bus_BroadcastEvent()) an event with event data contains: 1) componentName 2) subcomponentName (optional. If NULL, it means all subcomponents) 3) Logging Level. This event will be received by librdkloggerutil.so. The tool will build as binary rdklogctrl |
10 | si_cache_parser | rdk/components/generic/sys_mon_tools/si_cache_parser | A tool that parses SI cache supporting system monitoring |
11 | sys_resource | rdk/components/generic/sys_mon_tools/sys_resource | The memory leak tracer tool which is a system resource monitor for RDK. |
12 | sys_utils | rdk/components/generic/sys_mon_tools/sys_utils | Get devicesettings and trm related details such as HDCP Power State, Set Time Format (12hr / 24hr), TRM tuner details etc. |
13 | udhcpc-opt43 | rdk/components/generic/sys_mon_tools/udhcpc-opt43 | This program reads the file /opt/udhcpc.vendor_specific and then executes udhcpc with the -x option filled with the converted data. |
14 | sys_mon_tools/analyzers/scripts/host | rdk/components/generic/sys_mon_tools/analyzers/scripts/host | Host analyzer scripts that support system monitoring |
Summary
TR-069 is a technical specification that defines an application layer protocol for remote management of end-user devices. It was published by the Broadband Forum and was entitled CPE WAN Management Protocol(CWMP). The CWMP, published by The Broadband Forum as TR-069, specifies a standard communication mechanism for the remote management of end-user devices. It defines a protocol for the secure auto-configuration of a TR-069 device and incorporates other management functions into a common framework. This protocol simplifies device management by specifying the use of an auto configuration server (ACS) to perform remote, centralized management of customer premises equipment (CPE). TR-069 supports a variety of functionalities to manage CPEs and has the following primary capabilities:
- Auto-configuration and dynamic service provisioning
- Software/firmware management
- Status and performance monitoring
- Diagnostics
TR-069 closely monitor and control the Customer Premises Equipment (CPE). In RDK it would be Settop box or Gateway. There are many benefits associated with using TR-069 to provision and manage end-user devices. TR-069 and its extensions allow you to:
- Enable remote provisioning of CPE devices.
- Better manage broadband networks with increased visibility and control of CPE.
- Collect data for analytics on network usage and activity, home network characteristics, and service utilization.
- Deliver new managed data services such as WiFi, content filtering and other parental controls, online backup, and home surveillance.
- Offer subscribers a degree of self-service through web portals.
- Expand service offerings and manage the connected home.
- Improve your customer service with improved diagnostics, monitoring, and firmware management.
- Reduce support calls and remove the burden of CPE configuration from subscribers and roll-out services with an automated process.
TR-069 Features used in RDK
- Service Activation
- Firmware upgrade management
- Register device to Auto-Configuration Server (ACS) using Inform notification
- Periodically send device information to ACS using Inform notification
- Forced Inform for required parameters
- Allow ACS to configure periodic Inform interval.
- Allow ACS to reach devices that are connected behind NAT using STUN + UDP NAT traversal
- (future) Allow ACS to reach devices that are connected behind NAT using XMPP
- Retrieve device diagnostics/parameters using GetParameterValues() method
- Set device parameters using SetParameterValues() method
- Factory reset using FactoryReset method
- Device reboot using Reboot method
- SSL/TLS 1.2 (Transport Layer Security) per RFC5246 to encrypt communications with ACS
Use of ACS server in RDK
- TR-069 specifies communication between customer-premises equipment (CPE) and an auto configuration server.
- The auto configuration server acts as a management server for TR-069-enabled CPE.
- It is essentially the link between the subscriber's devices in the home and the service provider's customer service representative (CSR), support staff, operational support systems and business support systems (OSS/BSS).
- An auto configuration server enables you to automate provisioning and many management tasks for TR-069 devices, facilitating remote management.
How does TR-069 works in RDK
TR-069 is a SOAP(Simple Object Access Protocol)/HTTP-based protocol. Orders are sent between the device (CPE) and an auto configuration server over HTTP or HTTPS in the form of remote procedure calls (RPCs) and responses, with SOAP acting as the encoding syntax to transport RPCs. The CPE acts as the HTTP client and the ACS acts as the HTTP server.
The basic network elements required include:
- An auto configuration server (ACS): The management server on the network.
- Customer premises equipment (CPE): The device that is managed on the network
- DNS server: Used to resolve the URL that is required for the ACS and CPE to interact
- DHCP server: Can be used to assign an IP address to a device on the network. Well-known DHCP options can configure important parameters on the CPE, such as the ACS URL.
- TR-069 provides the communication interface between CPE and Auto Configuration Server (ACS)
- An ACS can manage a device, trouble shoot, configure and upgrade. the information.
TR-069 closely monitor and control the Customer Premises Equipment (CPE). In RDK it would be Settop box or Gateway.
- The Auto Configuration Server (ACS) is located in the cloud which control the Customer Premises Equipment.
- ACS server is controlled by Operation/Support team.
- There are different kinds of data model used in customer premises, such as TR-135 data model is used in STB, TR-104 data model is used in VoIP, TR-140 data module is used in storage, and so on.
What is a remote procedure call (RPC)?
A remote procedure call (RPC) is an operation between an ACS and the CPE. It is used for bidirectional communication between CPE and an ACS. Some common RPCs include:
- GetParameterValue: The ACS uses this RPC to get the value of one or more parameters of a CPE
- SetParameterValue: The ACS sets the value of one or more parameters of a CPE
- Inform: A CPE sends this message to an ACS to initiate a session and to periodically send local information
- Download: When the ACS requires a CPE to download a specified file to upgrade hardware and download a configuration file
- Upload: When the ACS requires a CPE to upload a specified file to a specified location
- Reboot: An ACS reboots a CPE remotely when the CPE encounters a failure or needs a software upgrade
- Add Object: Allows the ACS to create instances of objects available on the CPE, for example, port mapping entries. The ACS also creates the associated parameters and sub-objects.
- Delete Object: Enables the ACS to delete existing instances of objects available on the CPE. It also deletes the associated parameters and sub-objects.
Why RDK use TR-069?
There are many benefits associated with using TR-069 to provision and manage end-user devices. TR-069 and its extensions allow you to:
- Enable remote provisioning of CPE devices (example Xi3), etc.
- Better manage broadband networks with increased visibility and control of CPE.
- Collect data for analytics on network usage and activity, home network characteristics, and service utilization.
- Deliver new managed data services such as WiFi, content filtering and other parental controls, online backup, and home surveillance.
- Offer subscribers a degree of self-service through web portals.
- Expand service offerings and manage the connected home.
- Improve your customer service with improved diagnostics, monitoring, and firmware management.
- Reduce support calls and remove the burden of CPE configuration from subscribers and roll-out services with an automated process.
TR-069 Setup
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMDE0IiwiZGlhZ3JhbU5hbWUiOiJUUjY5IHNldHVwLmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJUUi0wNjkgSG9zdGlmIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjoyNjE4MTcxMSwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6MjYxODE3MTEsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEsIm1hY3JvSWQiOiI0ZWNmMDAwZS0zODBkLTRhNWEtYTA3MC03NTNlZmM5MGNiZTkiLCJwcmV2aWV3TmFtZSI6IlRSNjkgc2V0dXAuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTQ1MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
TR-69 Message Flow
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMDE2IiwiZGlhZ3JhbU5hbWUiOiJ0cjY5IG1lc3NhZ2UgZmxvdy5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiVFItMDY5IEhvc3RpZiIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MjYxODE3MTEsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjI2MTgxNzExLCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiNDM4YTg0ZmYtMWQ0MS00MjE4LWJiODItMDk2ZWI1MTZlNWIwIiwicHJldmlld05hbWUiOiJ0cjY5IG1lc3NhZ2UgZmxvdy5kcmF3aW8ucG5nIiwibGljZW5zZVN0YXR1cyI6Ik9LIiwic2VydmljZSI6IiIsImlzVGVtcGxhdGUiOiIiLCJ3aWR0aCI6Im51bGwiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2MTQ2OTQ1NDUwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
API Documentation
Refer the TR-069 Interface Specification to know more about on the following topics,
- TR-069 Device Management
- TR-069 Diagnostics
- TR-069 Firmware Download
- TR-069 Gathering Periodic Information
- TR-069 Host Interface Specifications
TR-69 Training (Overview on CPE WAN Management Protocol)
Overview
Westeros is a lightweight Wayland Compositor library that allows users to create Wayland displays and also allows nesting and embedding displays that contain third-party applications. The WPE integration with Westeros enables a better video experience with increased smoothness and enhanced browser responsiveness. Westeros is designed for embedded systems and is a replacement for Weston.
- Westeros is small and simple making it easier to understand and maintain.
- Westeros caters to the needs of embedded systems over traditional desktop computing.
- Westeros is a shared library that provides an API for creating and operating a compositor.
- Westeros includes sample compositor app OR you can implement a custom compositor.
- Westeros allows an application to create a Wayland display within itself- referred to as an embedded compositor. The main UI can then control the embedded application window and lifecycle.
Architecture
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNDEwIiwiZGlhZ3JhbU5hbWUiOiJXZXN0ZXJvcyBBcmNoaXRlY3R1cmUuZHJhd2lvIiwiYXNwZWN0IjoiIiwibGlua3MiOiJhdXRvIiwiY2VvTmFtZSI6Ildlc3Rlcm9zIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjozMTcxOTQzOSwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6MzE3MTk0MzksInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEsIm1hY3JvSWQiOiJjNjkyNDRhNS0wOTcyLTQ4ZDMtOWI2OS00ZmI1ZTQ4N2FhY2EiLCJwcmV2aWV3TmFtZSI6Ildlc3Rlcm9zIEFyY2hpdGVjdHVyZS5kcmF3aW8ucG5nIiwibGljZW5zZVN0YXR1cyI6Ik9LIiwic2VydmljZSI6IiIsImlzVGVtcGxhdGUiOiIiLCJ3aWR0aCI6Im51bGwiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2MTQ2OTQ1NTAwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
Westeros Use Case
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNDA4IiwiZGlhZ3JhbU5hbWUiOiJ3ZXN0ZXJvcyB1c2UgY2FzZS5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiV2VzdGVyb3MiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjMxNzE5NDM5LCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjozMTcxOTQzOSwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6IjM5OTY4OWRiLWQzMzMtNDc1OS1hYjkzLTA5NmJkMDVlOGUxZiIsInByZXZpZXdOYW1lIjoid2VzdGVyb3MgdXNlIGNhc2UuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTUwMDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
The hosting application (MSO Guide) has control over the presentation & composition of third-party applications.
Advantages of Westeros over Weston Compositor
There are two main sets of attributes of Westeros that make it a good choice:
First
- Westeros is small, simple, and targets embedded systems.
- Its small code size makes it easier to understand and maintain.
- Westeros concentrates on functionality needed for embedded systems rather than trying to include features that are related to traditional desktop computing.
Second
- The functionality of Wayland composition is in a shared library that provides an API for creating and operating a compositor.
- You can use the included sample compositor app, or you can use the sample as a reference for implementing a custom compositor.
- The use of embedded compositors allows applications to create additional Wayland display within itself.
A system could have a primary user interface which allows other third party applications to provide additional functionality such as Netflix, and the primary UI can control the size and position of the third party UI to provide seamless integration. If, on the other hand, you want to implement a system where the user moves, resizes, minimizes, and maximizes various windows, and does drag and drop operations etc., then Weston is a more appropriate choice.
Westeros as Wayland Library
- Westeros implements the Wayland protocols and is compatible with applications that are built to use Wayland compositors.
- Westeros supports the creation of normal, nested, and embedded Wayland Compositors.
- Westeros includes memory management primitives in order to provide a better video experience.
Build Steps
Bitbake recipes for building wpewebkit, which is integrated with Westeros, are available in the meta-metrological
layer in the CMF space. Changes which are required to build and run Westeros-integrated applications on the Raspberry Pi platform, have been merged into meta-cmf-raspberrypi
CMF Layer.
Steps to run a Westeros-enabled Application
Since the Westeros compositor is integrated with the WPE Browser, any application/link using WPE can be used to demonstrate a Westeros compositor.
To run a Westeros-enabled application:
- Set the following environment variables prior to running a compositor-enabled application:
$ export XDG_RUNTIME_DIR=/run/user/0/
$ export WAYLAND_DISPLAY=WPE
- Run the Westeros compositor for WPE display server:
$ westeros --renderer /usr/lib/libwesteros_render_gl.so.0.0.0 --display WPE
- Run the wizardkit UI Application:
$ WPELauncher http://<RaspberryPi Hybrid Ip>:80/wizardkit/ui/guide.html
- Run the pre-built Westeros bits included with the test case:
$ westeros_test --display WPE
RDK Wi-Fi Sub-system overview
In this section we will get an overview on the kind of Wifi support offered by RDK, how WPA supplicant is playing an important role on managing Wifi Driver, event notification and communication to different applications
In RDK we support integrated Wi-Fi chips as well as USB based Wi-Fi adapters. Implementation differences between on board Wi-Fi & USB Wi-Fi adapter are abstracted from Upper layers i.e. application doesn’t know what kind of Wi-Fi device or connection they are accessing.
RDK Wifi uses wpa_supplicant wireless daemon for connection management with the Wi-Fi driver. wpa_supplicant is designed to be a "daemon" that runs in the background and acts as the backend component controlling the wireless connection. wpa_supplicant also offers a control and monitoring interface to handle different wireless commands. Wi-Fi subsystem uses generic drivers such as NL80211 brings in wide range of vendor equipment's under coverage.
RDK Wi-Fi stack extensively uses commonly available Linux wireless utilities which brings most of the USB based and on-chip wireless equipment under our coverage. It provides support for diagnostics and connection management from remote and native applications. It uses IARM, which is a Linux D-BUS based communication protocol for managing Wi-Fi event notification and communication across different applications.
WiFi is a new features that is added in RDK video community devices. Recently Wi-Fi features is added to a Hardware Development (Raspberry Pi) video platform. As of now feature wise almost covered the client and access point related things, and we are continuing to work on remote management and diagnostics functionalities to be included into the Wi-Fi code.
Where does Raspberry-Pi Wi-Fi stand?
1.Basic Feature wise R-PI Wi-Fi is almost at the same level as that of other RDK platforms.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAwOTYwIiwiZGlhZ3JhbU5hbWUiOiJDb21wYXJpc2lvbi5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiV2ktRmkiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjI2MTgxNjU1LCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjoyNjE4MTY1NSwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6IjY1ZTQzYmI4LTcxNzgtNGU5NC05OGU0LTViN2I3YmRlMmYwMiIsInByZXZpZXdOYW1lIjoiQ29tcGFyaXNpb24uZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTQ0MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
Main difference that we can derive are:
In RPI:
- Raspberry-Pi is light weight and the abstraction layers are mainly written around common linux utilities.
- In R-PI we have a partial set of TR-181 APIs implemented which is needed for basic debugging.
In Other RDK Platform:
- In case of Other commercial RDK platforms, some proprietary code is used along with generic wireless code.
- Network manager can facilitate on-boarding process through a service called as lostfound.
- Also more OEM/SoC calls are used to expose more private features.
Wi-Fi Architecture
In this section, we will get the details on the architecture, layers, and how different RDK components interact with the wifi driver to enable Core wifi functionality.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMjM4IiwiZGlhZ3JhbU5hbWUiOiJ3aWZpIGFyY2hpdGVjdHVyZS5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiV2ktRmkiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjI2MTgxNjU1LCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjoyNjE4MTY1NSwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6IjIyOGEyMjNhLTJhZmUtNDdhNS1hZTA2LWU4Y2M1Njc0ZGE1NyIsInByZXZpZXdOYW1lIjoid2lmaSBhcmNoaXRlY3R1cmUuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTQ4MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
Application:
In top of the eco-system we have wide range of application which requires wireless network access. This may be a cloud based UI application, a diagnostics webpage or a console application such as test automation kit which will be required to verify readiness of a new RDK box with respect to different component features. This can be a HTML based webpage or a native console application requesting Wi-Fi functionalities.
Service manager:
Service manager is the contact point between external applications and native RDK. It is present in RDK as a library which when plugged in to a browser such as WPE or Qt enhances its capability to make communication from web applications to native RDK components through Java script. This exposes Java Script as well as native APIs, have decision making ability to route the request to appropriate RDK component.
IARM Message Bus:
RDK provides a common message and event notification mechanism known as IARM which passes the calls from upper layer i.e. service manager to actual network manager. A D-Bus based event and messaging mechanism propagates requests from application layer to lower layers. Sends event notification from Lower (network or HAL) layer to application layer.
Wi-Fi Network Manager:
Wi-Fi network manager is a daemon which handles network states and network interfaces. It handles Wireless initialization and management. This maintains the Wi-Fi state machine, initializes Wi-Fi subsystem & manages connection & disconnection events.
Wi-Fi generic HAL:
It is an Abstraction of Wireless driver calls and various linux wireless utilities to present a set of APIs for common wireless operation. It provides a set of APIs as per RDK specification for connection, management & diagnostic related activities. Abstracts implementation details and SoC dependencies from network management layer.
Linux wireless utility:
Tools such as wpa_supplicant, wereless-tools, net-link library, etc. which provides support for most of the common Wi-Fi chips.
Driver & Firmware:
Provided by SoC/OEM manufacturer. The kernel space driver and firmware binaries will be provided by Wi-FI SOC or OEM and it should be present in the defined path in the RDK box.
Use Cases
Let us see in what types of network topology one wireless enabled RDK box can operate. We can see two use cases here,
In first case we will see a straight forward network where we will have an IP headend for TV channels, VOD, etc.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMjQwIiwiZGlhZ3JhbU5hbWUiOiJXaWZpMS5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiV2ktRmkiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjI2MTgxNjU1LCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjoyNjE4MTY1NSwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6ImJlNzdiOGIzLWMzYzctNGE4MC1hZGUxLTA1YjIwNTYzNzNmNyIsInByZXZpZXdOYW1lIjoiV2lmaTEuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTQ4MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
- In the above picture, the data will be received by a RDK Broadband device which will be our entry point to the home network. This will act as a video gateway. The network connectivity from RDK broadband device to IP headend will be through a high speed network such as fiber optics, etc.
- From the RDK broadband device, all clients in a home network will receive internet and video data through the wireless network. The RDK broadband device will be the access point and video devices such as Raspberry Pi will act as wifi clients.
In second use case, we wanted to show how a legacy network can be extended to operate with wifi enable devices,
In the figure, we use a RDK Video gateway to receive data from Cable media and relay to a RDK broadband device through MoCA network. In this network topology,
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAwOTg2IiwiZGlhZ3JhbU5hbWUiOiJtb2NhMi5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiV2ktRmkiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjI2MTgxNjU1LCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjoyNjE4MTY1NSwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6IjRiMzhmZWYwLWE5ZmItNDkyNS05MzUyLWNlOGYwZmYyNWUyYiIsInByZXZpZXdOYW1lIjoibW9jYTIuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTQ1MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
RDK client devices will be able to access the QAM channel from the Video gateway and internet through the broadband device. Video and internet data will be received by the Broadband Device and sent to Wireless clients.
Wi-Fi Service Manager
Service Manager can be used for a wide range of services but in this context we wlll focus on the wifi service only.
- ServiceManager provides a uniform mechanism for discovering and consuming Wifi service on a target device.
- It is a Bridge between browser based application and the native RDK.
- It Provides capability for applications to use wifi services from other applications such as HTML 5, Java scripts, etc.
- All the service registrations are received by Service Manager and after registration, it announces the service availability to interested applications.
- It is one of the well-known facility for cloud-based applications to gain access to device vended functionality.
- Here the advantage is , applications need not know which other component are providing which type of services.
- Service manager provides some callback method which is basically for handling asynchronous events that is sent through other applications.
- for example events such as connecting to AP or disconnected from AP are generated by wifi Manager and sent to service manager.
Some of major API details are provided which is available under the header include/services/wifimanagerservice.h. Generally in case of each service, there are two common API for registering and un-registering particular service. When we register a service, we are making it available to the other application. And when we un-register it will no longer be accessible to the upper layer application.
Refer to Wifi Manager APIs for a complete list of APIs provided by Wifi Service manager.
Wi-Fi Network Manager
Wifi- network manager, which takes several responsibility for managing Wifi in Video device
- It dynamically detect the Network interfaces, send notifications to subscribers
- Supports diagnostics both local and cloud based applications
- Setup and update the network routes based on priorities, wifi connection status, availability, etc
- It also Listen to home networking updates to determine the routes for which communication to be established in outside world
- It provide Modular approach to add/remove new network interface types and also provide support for configuring routing rules
Refer to netsrvmgr for more detail such as APIs, Events and Error codes.
Wi-Fi Communication Workflow
In the below sequence diagram, we will see how an HTML application will interact with Wifi manager through Service manager. We can see that for each functionality we have an uniform API name across different component, which enable simplicity in development and the set off APIs can be mapped easily. For example, If we take one API that is getConnectionType(), which we can use to get the active interface type which may be Wifi or LAN interface.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMjQyIiwiZGlhZ3JhbU5hbWUiOiJzZXF1ZW5jZS5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiV2ktRmkiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjI2MTgxNjU1LCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjoyNjE4MTY1NSwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6ImY3ZjBlMjI0LTRlMDgtNDRiMi04MTRmLWY1NDFjZTI4YmZjYSIsInByZXZpZXdOYW1lIjoic2VxdWVuY2UuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTQ4MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
In first place, we will have Java Script functions registered with Service manager. Then Service manager will have an internal implementation for that API with error handling and managing result.
When the call is propagated, to the actual handler daemon (Wifi manager) through message bus, it will be translated to a IARM RPC call.
On the receiving side, Wifi manager will invoke actual Wi-Fi HAL API to get the result.So, we have seen a similar set of API are presented by different components to achieve the task.
An example, we have an user interface application where we want to show an icon based on whether Wi-Fi network is up. In that case we can take the help of service manager API to get the current state. Here service manager will internally call an RPC call with the Wifi manager to invoke the specific function. Then the wifi manager will invoke the actual HAL API to retrieve all the details and returns to the caller in a JSON formatted string. This status string will be then return to the application for displaying the appropriate icon based on UP/DN status.
Use Case: AP Discovery & Establishing Wi-Fi connection with AP
Here we will walkthrough the different RDK component involved in the process and starting from Application which is the imitator, ending with Wi-Fi HAL which is the provider of the functionality. We will also see the messaging formats in which the RDK components communicate.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMjQ0IiwiZGlhZ3JhbU5hbWUiOiJ3aWZpMi5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiV2ktRmkiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjI2MTgxNjU1LCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjoyNjE4MTY1NSwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6Ijg0OTFkOTc2LWY1MGUtNGM3NS04ZjY1LTAxMDlkM2EzOGE0MiIsInByZXZpZXdOYW1lIjoid2lmaTIuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTQ4MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
Initiating the connection: Here application may need to enable the WiFi if required. In which case he has call the initialization routine and network manager will handle the further operation
Getting a list of connection: When the WiFi system is up, application can request for a scan operation and then the neighbor scan API will be called by network manager. Which intern calls a Wi-Fi HAL API and return the result in JSON formatted string.
Selecting a preferred network: User can select a network from the list of Available AP.
Providing credential for the preferred network: Application has to handle the prompts for passphrase, network security Key, etc. and initiate the connection process.
Validation of the credential: Wifi manager will take the parameter and select the appropriate method to pass credential to WPA supplicant via an Wi-Fi HAL function. WPA supplicant will perform the actual sequence of operation to validate and establish the connection which will be an asynchronous process. i.e whenever the connection is established an appropriate event will be generated and notify to the caller.
Results: Application when receive the connection establish/failed event can show a visual confirmation.
Wi-Fi Integration Requirement
For integrating Wifi feature in a new RDK platform, following basic requirement can be kept in mind,
- First we need to have the OEM or SOC provider driver and firmware available with us so that we can integrate with our platform.
- There are Generic linux wireless packages need to be integrated with the platform.
- Most importantly, all the compatibility issues regarding Wifi driver and platform need to be addressed before hand, so that there is no issues regarding performance or connection glitches.
- We will need build support files for integration.
- A new HAL has to be written for the platform.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxMjQ2IiwiZGlhZ3JhbU5hbWUiOiJ3aWZpMy5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiV2ktRmkiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjI2MTgxNjU1LCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjoyNjE4MTY1NSwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6IjQ4YTA1ZmFkLTkxZDEtNGMwYi1hNTBlLWYzZDRiMGM0YzU1NSIsInByZXZpZXdOYW1lIjoid2lmaTMuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTQ4MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
RDK Wifi Specification mentions, all communication from network manager to the Wifi Driver has to be through WPA supplicant. So the basic requirement is to add WPA supplicant and its related packages such as netlink library and wireless tools. When all the dependency are added to the platform, we have to write a Wi-Fi HAL customized in our platform. Then we have to add the Wifi support in build framework via adding appropriate packages in image recipe as well as machine configuration file.
Code Walk-through: Folder structure
Looking at the below folder structure of the wifi HAL code in reference wifi & device specific wifi, We can see both follow similar naming conventions. We have 2 common files: wifi_common_hal.c and wifi_client_hal.c
In wifi_common_hal.c:
- Here we have defined most of the diagnostic APIs and utility functions.
In wifi_client_hal.c:
- It Mainly defines the internal state management functions, threads for monitoring the events coming from wpa_supplicant and connection related functions.
- It also defines callback functions for sending back the state changes and error events to wifi manager
- In generic wifi HAL, we have 3 header functions for defining AP, client & common APIs.
- In Raspberry Pi, the device specific HAL has dependency of WPA client library and libnl.
Code Walk-through: Wi-Fi HAL Recipe
This is a simple recipe which defines build rules for WIFI HAL library code. Here we can see that after defining some common stuff, it defines 2 environment variables i.e. PROVIDES , RPROVIDES_PN, both of which are assigned to virtual/wifi-hal. We can also see that wpa_supplicant and wifi-hal-headers as dependencies in the below code.
Code Walk-through: Network Manager
Debugging and Log analysis
TODO
API Documentation
To know more about SoC/Application level APIs details use in RDK, refer the link WIFI API Documentation
Wayland - What and Why?
- Primarily a protocol for compositionof different surfaces/layers.
- compositor + display server + window manager.
- Uses EGLto avoid OS specific windowing functionality.
- Started as a replacement for the X Windowing System (X11).
- Unlike X has no rendering API.
- Its implementations are lightweightwith a small footprint
- Wayland is primarily focused on performance, code maintainability and security
Webkit for Wayland
- Wayland provides simple, elegant, graphics compositing integration between different layers using EGL (interface between Khronos rendering APIs)
- Wayland started as a replacement for the X Windowing System (X11).
- Wayland is not an implementation but a protocol specification between a display server and its clients
- Its implementations are lightweight with a small footprint
- Wayland is primarily focused on performance, code maintainability and security
Advantage of WPE over QtWebKit
Newer WebKit= newer features:
- Contributions in the “upstream” direction are also important to the growth of the RDK, to attract more development and grow the community.
- It’s much faster then QT.
- For Gstreamer, we contributed a way to expose the video fragments, e.g. MPEG DASH smooth streaming, from the browser using Media Source Extensions (MSEs).
Faster:
- WebKit2 w/ Threaded compositor vs. QT single thread WebKit1 architecture.
- UI Process, Web Process, Network Process and Database Process
- New JavaScript Core optimization feature: “Faster Than Light” JIT
- JSC inline with modern day HTML5 development (e.g. better JIT support for closures)
Smaller:
- Compared to QTWebkit, WPE is about 30% smaller — around 22 Megabytes,
- On average, compared to 32 Megabytes while packing 60% more features
A Traditional Approach for Rendering
In traditional approach, the central role of X-Server and the steps required to get contents on to the screen is presented in below diagram.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNDQ4IiwiZGlhZ3JhbU5hbWUiOiJBIFRyYWRpdGlvbmFsIGFwcHJvYWNoIGZvciByZW5kZXJpbmcuZHJhd2lvIiwiYXNwZWN0IjoiIiwibGlua3MiOiJhdXRvIiwiY2VvTmFtZSI6IldQRSIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MzE3MTk0NDIsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjMxNzE5NDQyLCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiMDIyOGE4NjAtNWIwYy00OTMxLTk3NjgtYTgzYzgzM2RiMTYyIiwicHJldmlld05hbWUiOiJBIFRyYWRpdGlvbmFsIGFwcHJvYWNoIGZvciByZW5kZXJpbmcuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTUxMDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
Wayland Approach for Rendering
Removed X-Server and the compositor is the display server. Lets the compositor send the input event directly to the client and lets the client sent the damage event directly to the compositor.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNDQ2IiwiZGlhZ3JhbU5hbWUiOiJXYXlsYW5kIGFwcHJvYWNoIGZvciByZW5kZXJpbmcuZHJhd2lvIiwiYXNwZWN0IjoiIiwibGlua3MiOiJhdXRvIiwiY2VvTmFtZSI6IldQRSIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6MzE3MTk0NDIsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjMxNzE5NDQyLCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoxLCJtYWNyb0lkIjoiZTNkYzczOGQtMDVhNS00Y2I3LTg0NjQtZjM0ZTUzNmE5ODc1IiwicHJldmlld05hbWUiOiJXYXlsYW5kIGFwcHJvYWNoIGZvciByZW5kZXJpbmcuZHJhd2lvLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiJudWxsIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjE0Njk0NTUxMDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
Wayland - What and Why?
“Wayland is a protocol for a compositor to talk to its client as well as a C lib implementation of that protocol”. Weston is the reference implementation for wayland. Westeros is a compositor, a replacement of Weston. This provides clear interface towards graphics and input.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNDQ0IiwiZGlhZ3JhbU5hbWUiOiJ3YXlsYW5kLmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJXUEUiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjMxNzE5NDQyLCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjozMTcxOTQ0MiwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6ImIxMWEwYTQ3LTQ5NDgtNDE2Ni1iMjU1LTc2NzhhNjQzZTMwNyIsInByZXZpZXdOYW1lIjoid2F5bGFuZC5kcmF3aW8ucG5nIiwibGljZW5zZVN0YXR1cyI6Ik9LIiwic2VydmljZSI6IiIsImlzVGVtcGxhdGUiOiIiLCJ3aWR0aCI6Im51bGwiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2MTQ2OTQ1NTEwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
Wayland Process flow:
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNDQyIiwiZGlhZ3JhbU5hbWUiOiJ3YXlsYW5kIHByb2Nlc3MgZmxvdy5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiV1BFIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjozMTcxOTQ0MiwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6MzE3MTk0NDIsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEsIm1hY3JvSWQiOiIyMTMyMzlmZi1kODdiLTQxYzgtYTQ0MC1kOTAyNThjNjY0MDgiLCJwcmV2aWV3TmFtZSI6IndheWxhbmQgcHJvY2VzcyBmbG93LmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU1MTAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
Why Westeros?
- Westeros is smalland simple.
- Being small, easier to understand and maintain.
- Caters to needs of embedded systems over traditional desktop computing.
- Shared library that provides an APIfor creating and operating a compositor.
- Use the included sample compositor app OR implement a custom compositor.
- Allows an application to create a Wayland display within itself to create what we call an embedded compositor.
- Main UI can then control application windowandlifecycle.
Westeros Use Case
Gives the hosting application (MSO Guide) control over the presentation and composition of 3rd party applications.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNDQwIiwiZGlhZ3JhbU5hbWUiOiJ3ZXN0ZXJvcyB1c2UgY2FzZS5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiV1BFIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjozMTcxOTQ0MiwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6MzE3MTk0NDIsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEsIm1hY3JvSWQiOiJiZGE3OTQ0Ny1mN2U5LTQ5YWQtOGFhNy0xODFjNDg5OWM2MzYiLCJwcmV2aWV3TmFtZSI6Indlc3Rlcm9zIHVzZSBjYXNlLmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU1MTAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
Why WPE
- Newer WebKit= newer features
- WebKit2 w/ Threaded compositor vs. QT single thread WebKit1 architecture.
- New JavaScript Core optimization feature: “Faster Than Light” JIT
- Compared to QTWebkit, WPE is about 30% smaller —around 22 Megabytes.
WPE Architecture
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNDM4IiwiZGlhZ3JhbU5hbWUiOiJ3YXlsYW5kMi5kcmF3aW8iLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiV1BFIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjozMTcxOTQ0MiwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6MzE3MTk0NDIsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjEsIm1hY3JvSWQiOiI4YzRjNjc3NS0xOTc1LTQzMjUtODU4My03ZGNkNzNiYzZlNWUiLCJwcmV2aWV3TmFtZSI6IndheWxhbmQyLmRyYXdpby5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoibnVsbCIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYxNDY5NDU1MTAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
WPE and Wayland Clients
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNDM2IiwiZGlhZ3JhbU5hbWUiOiJXZWJraXQgZm9yIFdheWxhbmQgYXJjaGl0ZWN0dXJlLmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJXUEUiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjMxNzE5NDQyLCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjozMTcxOTQ0MiwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6ImEyZDc3MjlhLTJhMzctNGUzZi04OTMxLTNjN2NjZWJkMjIxOCIsInByZXZpZXdOYW1lIjoiV2Via2l0IGZvciBXYXlsYW5kIGFyY2hpdGVjdHVyZS5kcmF3aW8ucG5nIiwibGljZW5zZVN0YXR1cyI6Ik9LIiwic2VydmljZSI6IiIsImlzVGVtcGxhdGUiOiIiLCJ3aWR0aCI6Im51bGwiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2MTQ2OTQ1NTEwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
Code Restructure
- Code move:
- Source / WPE —> ThirdParty/ WPE & ThirdParty/ WPE-platform
- Easier up-streaming
- Port acceptance
- Refactor WPE to C back-ends
- New IPC mechanism
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlotWW9nb21heWEgTWFoYXJhbmEiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiWi1Zb2dvbWF5YSBNYWhhcmFuYSIsImxhbmd1YWdlIjoiZW4iLCJ1aUNvbmZpZyI6Int9IiwiZGlhZ3JhbURpc3BsYXlOYW1lIjoiIiwic0ZpbGVJZCI6IiIsImF0dElkIjoiMTQ0OTAxNDM0IiwiZGlhZ3JhbU5hbWUiOiJDb2RlIHJlc3RydWN0dXJlLmRyYXdpbyIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJXUEUiLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjMxNzE5NDQyLCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjozMTcxOTQ0MiwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MSwibWFjcm9JZCI6ImNlYWNiMmY3LTNjMTctNGVmNS04ZjQ0LWY0N2YzYjEwNjM2OSIsInByZXZpZXdOYW1lIjoiQ29kZSByZXN0cnVjdHVyZS5kcmF3aW8ucG5nIiwibGljZW5zZVN0YXR1cyI6Ik9LIiwic2VydmljZSI6IiIsImlzVGVtcGxhdGUiOiIiLCJ3aWR0aCI6Im51bGwiLCJzaW1wbGVWaWV3ZXIiOmZhbHNlLCJsYXN0TW9kaWZpZWQiOjE2MTQ2OTQ1NTEwMDAsImV4Y2VlZFBhZ2VXaWR0aCI6ZmFsc2UsIm9DbGllbnRJZCI6IiJ9
Work Accomplished in RDK
- Ported on RPI
- MIPS support for BCM targets
- Addition of Intel-CE and other BCM configurations
- MSE and EME implementation for YouTube leanback
- Parity or better than QtWebKit.
- Shadow Dom
- Wayland Support
- Fullscreen API
- MIPS JIT Architecture Change
- Walyland Reference Backend
- Speech APIs & reference implementation
- Geolocation
- Notifications
- PlayReady DRM
- Automated test runner
- IndexdDB Support
- Injected Bundles
- Full MSE Compliance
- WebCrypto
- View Backends for non-Wayland
- Gamepad Support
Functional Test (HTML5): QTWebkit Vs WPEWebKit
These tests are based on the site https://html5test.com/
Functional Test(CSS3): QTWebkit Vs WPEWebKit
These tests are based on the site http://css3test.com/
Repositories
WPE Support with RDK - Recipes
Weston:
- meta-rdk-ext/recipes-graphics/wayland/
waylandwayland_1.6.0.bbwayland-native_1.6.0.bbwestonweston_1.6.0.bb
Westeros:
- meta-rdk-video/recipes-graphics/westeros
westeros.bb westeros.inc westeros-simplebuffer.bbwesteros-simpleshell.bbwesteros-sink.bb
WPE Webkit:
- meta-rdk-ext/recipes-extended/wpe-webkit/
wpe-webkit_0.1.bbwpe-webkit_0.2.bb wpe-webkit.inc
WPE Support with RDK - Build
- WPE Support is provided with specific image types
- Source meta-cmf/setup-environment
- Select the required machine configuration
- Build the image with WPE package support. E.g.
- bitbakerdk-generic-hybrid-wpe-image
- bitbakerdk-generic-mediaclient-wpe-image
How to work with WPE
- Step 1: Fork WPE on GitHub.com
- Step 2: Apply changes on your fork
- Step 3: Test your changes
- Step 4: Submit pull request to WPE master
- Step 5: Prepare for comments, rework if necessary
- Step 6: Wait for merge notification
Overview
Universal Plug and Play (UPnP) is a set of networking protocols that permits networked devices, such as personal computers, printers, Internet gateways, Wi-Fi access points and mobile devices to seamlessly discover each other's presence on the network and establish functional network services for data sharing, communications and entertainment. UPnP uses -
- To discover the devices in the network.
- To gather additional information from the devices in network.(e.g receiver id, fog url, etc)
- To use the gathered additional information obtained for other running processes.
Universal Plug and Play (UPnP) is an implementation of the generic GUPnP framework for device discovery and using services from control points. GUPnP is a library for implementing both UPnP clients and services using GObject and LibSoup. It allows for fully asynchronous use without using threads and so cleanly integrates naturally into daemons, and supports all of the UPnP features.
The GUPnP framework consists of the following libraries:
- GSSDP implements resource discovery and announcement over SSDP.
- GUPnP implements the UPnP specification
- Resource announcement and discovery.
- Description.
- Control.
- Event notification.
- Presentation (GUPnP includes basic web server functionality through libsoup).
Procedure involving in implementation of the GUPnP Client:
- Finding Services: Initialize GUPnP and create a control point targeting the service type. Then we connect a signal handler so that we are notified when services we are interested in are found.
- Invoking Actions: GUPnP has a set of methods to invoke actions where you pass a NULL-terminated varargs list of (name, GType, value) tuples for the in-arguments, then a NULL-terminated varargs list of (name, GType, return location) tuples for the out-arguments.
- Subscribing to state variable change notifications: It is possible to get change notifications for the service state variables that have attribute sendEvents="yes".
UPnP Applications:
xdiscovery
- The UPnP daemon xdiscovery runs in system on MoCA interface.
- While starting the xdiscovery service, we create a UPnP control point with target device type as urn:schemas-upnp-org:device:BasicDevice:1.
- Once UPNP control point is added and active in the network, It searchs for the target device types in the network.
- The device-proxy-available Signal is emitted when any device which matches target types is found in the network and the event is handled in a callback routine.
- The discovery messages contains a few information about the device , Usually the device descriptions is in an XML file and it includes vendor specific information like Manufacturer, Model Name, Serial No, URL to vendor specific web sites etc. Also it lists the services as well if any.
- Each service description includes a list of commands to which the service responds with its parameters and arguments.
- The UPnP control point subscribes for the notification if any of the service variable changes during run time. After the device is discovered in the network, the UPnP control point send an action by calling the GUPnP API gupnp_service_proxy_send_action() to retrieve device info and its capabilities. After that it add or update the device in device list using its serial number.
Gateway set up : Internally UPnP uses a script /lib/rdk/gwSetup.sh to set up the gateway in client devices. Here we sets up the routing table, DNS setting etc.
{
"sno":"PAD200067027",
"isgateway":"yes",
"gatewayip":"169.254.106.182",
"gatewayipv6":"null",
"hostMacAddress":"84:e0:58:57:73:55",
"gatewayStbIP":"69.247.111.43",
"ipv6Prefix":"null",
"deviceName":"null",
"bcastMacAddress":"84:e0:58:57:73:59",
"recvDevType":"X1",
"buildVersion":"66.77.33p44d5_EXP",
"timezone":"US/Eastern",
"rawoffset":"-18000000",
"dstoffset":"60",
"dstsavings":"3600000",
"usesdaylighttime":"yes",
"baseStreamingUrl":"http://127.0.0.1:8080/videoStreamInit?recorderId=P0118154760",
"requiresTRM":"true",
"baseTrmUrl":"ws://127.0.0.1:9988",
"playbackUrl":"http://127.0.0.1:8080/hnStreamStart?deviceId=P0118154760&DTCP1HOST=127.0.0.1&DTCP1PORT=5000",
"dnsconfig":"search hsd.tvx.comcast.net;nameserver 75.75.75.75;nameserver 75.75.76.76;nameserver 69.252.80.80;",
"hosts":"69.247.111.43 pacexg1v3;",
"systemids":"channelMapId:1901;controllerId:3415;plantId:0;vodServerId:70001",
"receiverid":"P0118154760"
}
XCal-Device module
XcCal-Device module is responssible for getting the following device discovery information.
- Read the upnp configuration details from configuration file.
- Getting the input for different gateway to populate all the service veriables.
- It act like a server & whenever requested it will give the services details such as ipv6 ip address, receiver Id, etc.
- Once the xcal-device receive the services details, it will create a UPnP object and start publishing the UPnP data.
API Specification
Refer the link UPnP API Documentation for more implementation details of XCal-Device and XCal-Discovery used in RDK.