Tizen porting guide_2.0.beta_1025

SAMSUNG ELECTRONICS CO LTD.

Tizen Porting Guide Tizen the True Open Platform

9/10/2012

This document acts as a guide for porting and bringing up the Tizen OS on a new hardware platform.

Tizen Porting Guide

ⓒ 2012 SAMSUNG Electronics Co., Ltd. Proprietary

Page 1 of 143

Revision History

Version Date Comments

1.0 03/13/2012 Tizen Porting Guide Initial version

2.0-α 09/10/2012 Overall document update

Tizen Porting Guide


Page 2 of 143

Contents

CONTENTS ................................................................................................................................................ 2

INTRODUCTION ...................................................................................................................................... 6

About Tizen ............................................................................................................................................................... 6

Purpose of this document ......................................................................................................................................... 6

TIZEN ARCHITECTURE ......................................................................................................................... 7

The Application Layer ................................................................................................................................................ 8

The Core Layer ........................................................................................................................................................... 8

The Kernel Layer ........................................................................................................................................................ 9

DEVELOPMENT ENVIRONMENT SETUP ....................................................................................... 10

Tizen OS Development Setup .................................................................................................................................. 10

Introduction to OBS ................................................................................................................................................. 11

OBS Light ................................................................................................................................................................. 11 OBS Light server Appliance ............................................................................................................................ 12 OBS Light Client Appliance ............................................................................................................................ 12

Installation of SDK ................................................................................................................................................... 12

GETTING SOURCE CODE & BUILD .................................................................................................. 13

Platform Build .......................................................................................................................................................... 13

Kernel Build ............................................................................................................................................................. 13

TIZEN BOOTUP OVERVIEW .............................................................................................................. 15

Kernel Bootup .......................................................................................................................................................... 15

Platform Bootup ...................................................................................................................................................... 15

BSP CUSTOMIZATION ......................................................................................................................... 18

Bootloader Fundamentals ....................................................................................................................................... 18

Bootloader Setup and Build .................................................................................................................................... 18

Tizen Porting Guide


Page 3 of 143

Bootloader Commands Support .............................................................................................................................. 18

Bootloader Kernel Parameters ................................................................................................................................ 19

KERNEL FUNDAMENTALS ................................................................................................................. 20

Kernel Configurations .............................................................................................................................................. 20

Tizen File System ..................................................................................................................................................... 21 Virtual Filesystem (VFS ) ................................................................................................................................ 21 Tizen Partition Layout .................................................................................................................................... 22 File-system Hierarchy Standard in Tizen ........................................................................................................ 23 Configuration ................................................................................................................................................. 23 Reference....................................................................................................................................................... 23

MMC ........................................................................................................................................................................ 24 Description .................................................................................................................................................... 24 Reference....................................................................................................................................................... 25

SYSTEM ................................................................................................................................................... 26

System Framework .................................................................................................................................................. 26 Description .................................................................................................................................................... 26 Porting OAL Interface .................................................................................................................................... 28 Configuration ................................................................................................................................................. 36 Reference....................................................................................................................................................... 36

Sensor Framework ................................................................................................................................................... 40 Description .................................................................................................................................................... 40 Porting OAL Interface .................................................................................................................................... 42 Configuration ................................................................................................................................................. 46 Reference....................................................................................................................................................... 46

GRAPHICS AND UI ................................................................................................................................ 48

OpenGL .................................................................................................................................................................... 48 3D Graphics Library ....................................................................................................................................... 48 EGL (Embedded-System Graphics Library) .................................................................................................... 49 Porting ........................................................................................................................................................... 50 OpenGL ES ..................................................................................................................................................... 50

X server .................................................................................................................................................................... 54

Input Driver ............................................................................................................................................................. 54 Description: ................................................................................................................................................... 54 Porting OAL Interface: ................................................................................................................................... 55 Configuration ................................................................................................................................................. 56

Video Driver ............................................................................................................................................................. 57 Description: ................................................................................................................................................... 57 Porting OAL Interface: ................................................................................................................................... 58

Tizen Porting Guide


Page 4 of 143

Configuration ................................................................................................................................................. 64 References ..................................................................................................................................................... 64

MULTIMEDIA ......................................................................................................................................... 66

Camcorder ............................................................................................................................................................... 66 Description .................................................................................................................................................... 66 Porting OAL Interface .................................................................................................................................... 67 Configuration ................................................................................................................................................. 73 References ..................................................................................................................................................... 77

Radio........................................................................................................................................................................ 79 Description .................................................................................................................................................... 79 Porting OAL Interface .................................................................................................................................... 79 Configuration ................................................................................................................................................. 79 References ..................................................................................................................................................... 79

Audio ....................................................................................................................................................................... 81 Description .................................................................................................................................................... 81 Porting OAL Interface .................................................................................................................................... 82 Configuration ................................................................................................................................................. 83 References ..................................................................................................................................................... 86

Player ....................................................................................................................................................................... 88 Description .................................................................................................................................................... 88 Porting OAL Interface .................................................................................................................................... 88 Configuration ................................................................................................................................................. 89 References ..................................................................................................................................................... 90

Codec ....................................................................................................................................................................... 91 Description .................................................................................................................................................... 91 Porting OAL Interface .................................................................................................................................... 93 Configuration ................................................................................................................................................. 96 References ..................................................................................................................................................... 98

CONNECTIVITY ..................................................................................................................................... 99

Bluetooth ................................................................................................................................................................. 99 Description .................................................................................................................................................. 100 Porting OAL Interface .................................................................................................................................. 101 Configuration ............................................................................................................................................... 101 References ................................................................................................................................................... 102

WLAN ..................................................................................................................................................................... 104 Description: ................................................................................................................................................. 104 Porting OAL Interface: ................................................................................................................................. 105 Configuration: .............................................................................................................................................. 105 References: .................................................................................................................................................. 105

NFC ........................................................................................................................................................................ 107 Description .................................................................................................................................................. 107

Tizen Porting Guide


Page 5 of 143

Porting OAL Interface .................................................................................................................................. 108 Configuration ............................................................................................................................................... 110 Reference..................................................................................................................................................... 110

LOCATION ............................................................................................................................................ 111 Description .................................................................................................................................................. 111 Porting OAL Interface .................................................................................................................................. 115 Configuration ............................................................................................................................................... 117 References ................................................................................................................................................... 118

TELEPHONY ........................................................................................................................................ 119 Description .................................................................................................................................................. 119 Porting OAL Interface .................................................................................................................................. 120 Configuration ............................................................................................................................................... 134

APPENDIX............................................................................................................................................ 135

Sensor Processor Plugin APIs ................................................................................................................................. 135

NFC OAL API........................................................................................................................................................... 137

Tizen Porting Guide


Page 6 of 143

Introduction

About Tizen Tizen is an open source standards-based software platform, targeted towards multiple device segments, including smart phones, tablets, netbooks, in-vehicle infotainment devices, smart TVs, and more.

Purpose of this document The intent of this document is to provide information and instruction to boot Tizen on new hardware and create products based on the Tizen OS. The Tizen porting guide takes you through the porting process by elaborating the Tizen architecture, the tools needed, the development environment setup, as well as creating a Tizen Image and demonstrating the modifications needed across various functional areas.

Tizen Porting Guide


Page 7 of 143

Tizen Architecture

The figure below illustrates the Tizen architecture for smartphone and tablet devices.

Tizen Porting Guide


Page 8 of 143

The Application Layer

Tizen supports web applications. Tizen web applications leverage the full power of the platform, just like native applications.

The Core Layer

The Core layer consists of the Tizen API and Tizen Core Service.

Tizen API

Tizen web applications can be developed using the Tizen Web API. The Tizen Web API is a collection of W3C (HTML5 and more), Khronos WebGL, and newly defined device APIs.

Tizen Core Services

Application Framework The Application Framework provides application management, including launching other applications using the package name, URI, or MIME type. It also launches pre-defined services, such as the system dialer application. The Application Framework also notifies applications of common events, such as low memory events, low battery, changes in screen orientation, and push notification.

Base Base contains Linux* base essential system libraries that provide key features, such as database support, internationalization, and XML parsing.

Connectivity Connectivity consists of all network- and connectivity-related functionalities, such as 3G, Wi-Fi, Bluetooth, HTTP, and NFC (Near Field Communication). Data network is based on ConnMan (Connection manager), which provides 3G and Wi-Fi based network connection management.

Graphics and UI Graphics and UI consist of the system graphic and UI stacks, which includes the EFL (Enlightenment Foundation Libraries), an X11-based window management system, input methods, and OpenGL® ES*. The heart of the Graphics component, the EFL, is a suite of libraries. It is for creating rich graphics with ease, for all UI resolutions. The libraries build UIs in layers, allowing for 3D transformations and more. The EFL includes the Evas canvas API library and the elementary widget library.

Location Location provides location based services (LBS), including position information, geocoding, satellite information, and GPS status. It is based on GeoClue, which delivers location information from various positioning sources, such as GPS, WPS (Wi-Fi Positioning System), Cell ID, and sensors.

Messaging Messaging consists of SMS, MMS, Email, and IM.

Multimedia Multimedia is based on GStreamer. It provides support for media, including video, audio, imaging, and VoIP. It also provides media content management for managing media file metadata information.

Tizen Porting Guide


Page 9 of 143

PIM (Personal Information Management) PIM enables managing user data on the device, including managing calendar, contacts, tasks, and retrieving data about the device context (such as device position and cable status).

Security

Security is responsible for security deployment across the system. It consists of platform security enablers, such as access control, certificate management, and secure application distribution.

System

System consists of system and device management features, including: Interfaces for accessing devices, such as sensors, display, or vibrator. Power management, such as LCD display backlight dimming/off and application processor sleep. Monitoring devices and handling events, such as USB, MMC, charger, and ear jack events. System upgrade. Mobile device management.

Telephony

Telephony consists of cellular functionalities communicating with the modem: Managing call-related and non-call-related information and services for UMTS and CDMA. Managing packet service and network status information for UMTS and CDMA. Managing SMS-related services for UMTS and CDMA. Managing SIM files, phone book, and security. Managing SIM Application Toolkit services for UMTS.

Web

Web provides a complete implementation of the Tizen Web API optimized for low power devices. It includes WebKit, which is a layout engine designed to allow web browsers to render web pages. It also provides web runtimes for web applications.

The Kernel Layer

The Kernel layer includes Linux kernel and device drivers.

Tizen Porting Guide


Page 10 of 143

Development Environment Setup

This section provides a brief overview about setting up your development environment on your host system, such as your Ubuntu* system. The below figure briefly describes the Tizen development environment setup.

Follow the steps below to set up the development environment on your Ubuntu system.

Tizen OS Development Setup Please refer to the following links to set up the Tizen OS Development environment and to obtain infomation regarding devlopment.

https://source.tizen.org/os-development 1. Work Flow

This section explains GIT/Gerrit based source code management and review process, package creation using Open Build Service(OBS), and code submission methods, including development and upstream branches.

2. Developer Guide This section describes registration and information on a development environment

https://source.tizen.org/os-development

Tizen Porting Guide


Page 11 of 143

setup for GIT/Gerrit, SSH, GIT Build system, Image creator, and install tools. It includes the code and package submission using GIT and OBS buildsystem and the complete development flow.

3. Git Build System The GBS(Git-Build-System) is a custom command line tool that supports Tizen package development. This section explains about auto-generating tarballs based on git repositories, performing local and report builds, and OBS code submission. This section also has procedure to monitor remote build log and status.

4. MIC Image Creator This tools is used to create images for Tizen. This section provides detailed explainations of image creation, conversion and chrooting into image procedure.

As is explained in the above URLs, Tizen development requires Open(SuSE) Build system and the required components. In the following sections, we will briefly introduce various such build requirements.

Introduction to OBS The Open Build Service (OBS) is an open and complete distribution development platform that provides a transparent infrastructure for development of Linux distributions, used by openSUSE, MeeGo, and other distributions. (Supporting also Fedora, Debian, Ubuntu, RedHat, and other Linux distributions). OBS provides the developers an easy way of using web-based and command based interface to achieve development activities. OBS maintains a consistent build environment, which each developer can rely on for various Linux distributions. For more information on OBS, you can refer to this link:

https://build.tizen.org/ OBS can be set up locally or we can refer any available OBS services. http://doc.opensuse.org/products/draft/OBS/obs-best-practices_draft/cha.obs.best-practices.localsetup.html is one of the links that talks about setting up OBS server locally. To make use of any available OBS servers, user credentials are required. Each OBS implemetiation can have more customized tools to achieve the build servies. You can find information on Tizen OBS and its customized build tool, named git-build-System(GBS), in this link https://source.tizen.org/os-development/git-build-system/

OBS Light OBS Light is an OBS base development process, but which is lighter to use. It creates an encapsulation of OBS and presents a lighter face of OBS.

http://openbuildservice.org/

https://build.tizen.org/

http://doc.opensuse.org/products/draft/OBS/obs-best-practices_draft/cha.obs.best-practices.localsetup.html

http://doc.opensuse.org/products/draft/OBS/obs-best-practices_draft/cha.obs.best-practices.localsetup.html

https://source.tizen.org/os-development/git-build-system/

http://en.wikipedia.org/wiki/Open_Build_Service

Tizen Porting Guide


Page 12 of 143

OBS Light server Appliance

This is a ready-to-use OBS for MeeGo and Tizen. openSUSE Build Service(OBS) 2.3.0-1.6. The openSUSE Build Service appliance contains the complete OBS stack, including a Worker, the Backend, API, Webclient, and osc, the command line client. FakeOBS is an added utility, through which we can achieve priovate OBS Builds.

OBS Light Client Appliance

OBS Client Appliance consists of a command line (obslight) and a graphical user interface GUI (obslightgui). OBS Client includes MIC to create a bootable image.

http://en.opensuse.org/openSUSE:OBS_Light_Manual http://en.opensuse.org/openSUSE:OBS_Light_Fakeobs http://susestudio.com/a/e0uuBG/obs-obs-server-obs-light http://en.opensuse.org/openSUSE:OBS_Light_Installation

Installation of SDK

The Tizen SDK is a comprehensive set of tools for developing Tizen web applications. It consists of Web IDE, Emulator, tool chain, sample code, and documentation. The beta release of the Tizen SDK runs on Windows*, as well as Ubuntu. Tizen Web applications may be developed without relying on an official Tizen IDE, as long as the application complies with Tizen packaging rules. Use the link below to download the Tizen SDK.

https://developer.tizen.org/sdk

http://en.opensuse.org/openSUSE:OBS_Light_Manual

http://en.opensuse.org/openSUSE:OBS_Light_Fakeobs

http://susestudio.com/a/e0uuBG/obs-obs-server-obs-light

http://en.opensuse.org/openSUSE:OBS_Light_Installation

https://developer.tizen.org/sdk

Tizen Porting Guide


Page 13 of 143

Getting Source Code & Build

Follow this link to download the full source code for your Tizen platform and kernel https://review.tizen.org/git/

Refer to below link for more information

Sorurce code Management on Tizen releases: GIT/Gerrit: https://review.tizen.org/gerrit

Tizen Build setup OBS: https://build.tizen.org/

Tizen Bug Tracking system Jira: https://bugs.tizen.org/jira

Download URL: http://download.tizen.org/

Platform Build Follow the link below to get learn how to add something like below: https://source.tizen.org/os-development/developer-guide Follow the link below to build the source code by using git build system. https://source.tizen.org/os-development/git-build-system

Kernel Build

Follow the steps below steps to build the Tizen kernel.

Install and set up the osc, OBS client tools on your system.

Get the kernel source package and spec file from OBS . You can see kernel-3.0.15.tar.gz and kernel.spec file.

$ osc co TIZEN:2.0:System kernel

Createdefconfig kernel configuration file as per the target requirement. The configuration files available under arch/arm/configs/ can be modified by adding and removking kernel configuration options to create a customized default config, file like xyz_defconfig.

Copy the new config file (such as xyz_defconfig) into the arch/arm/configs/ folder inside the kernel source directory. This step can be skipped to use the existing defconfig file.

https://review.tizen.org/git/

https://review.tizen.org/gerrit

https://build.tizen.org/

https://bugs.tizen.org/jira

http://download.tizen.org/

https://source.tizen.org/os-development/developer-guide

https://source.tizen.org/os-development/git-build-system

Tizen Porting Guide


Page 14 of 143

The following command is used to apply the custom config file such as xyz_defconfig for the target, this command can be updated within the spec file to specify the custom defconfig file.

make xyz_defconfig

The following command is used to build the kernel RPM package inside the kernel directory.

$ osc build armv7el –no-verify --clean

Once the build is successful, the RPM kernel package is created under/var/tmp/build-root/abuild/rpmbuild/RPMS/armv7l/kernel-3.0.15-1.armv7l.rpm. The kernel RPM package is downloaded on to the target and installed, as below

# rpm –Uvh kernel-3.0.15-1.armv7l.rpm

Instead of using the RPM kernel package, the kernel uImage can also be downloaded to the target. The uImage is created under /var/tmp/build-root/home/abuild/rmpbuild/BUILD /kernel-3.0.15/arch/arm/boot/uImage after the successful build. Create a tarball to download the kernel to your target .

$ cd /var/tmp/build-root/home/abuild/rpmbuild/BUILD/kernel-

3.0.15/arch/arm/boot/

$ tar cvf tizen-kernel.tar uImage

Tizen Porting Guide


Page 15 of 143

Tizen Bootup Overview

This section provides a brief overview of the typical booting sequence, starting from boot loader to the kernel and the platform.

Kernel Bootup The Tizen bootup process is the same as any other Linux kernel. We just need to make sure that the correct machine ID and the boot arguments are passed from the boot loader.

Platform Bootup The system-plugin-slp is an OAL plugin for booting the Tizen platform. Thisplugin shall be modified as per the platform bootup sequence requirements from the vendor. The platform bootup, using the OAL plugin (system-plugin-slp), is mentioned below and is applicable for Tizen SDK Bootup.

Tizen Porting Guide


Page 16 of 143

Special file-systems like /proc, /tmp, /var, /sys and /dev are mounted during ‘mount *1+'.

Make device node about NULL device.

Run hotplug daemon of Linux.

Script checks for special booting mode. For example, in charging mode or during FOTA (Firmware upgrade On The Air), it runs scripts from /etc/rc.d/rc2.d. This directory should have the scripts for the special booting mode. After exiting special booting mode, the target will be restarted.

For the first time booting after downloading, resize all ext4 partitions before mounting them and configure the device information.

General file-systems for Tizen like /opt, /opt/media are mounted during ‘mount *2+'.

Set device node permissions for security.

Start modem booting.

Run scripts in /etc/rc.d/rc3.d. Detailed sequence of rc3.d scripts are described in the next chapter.

The following section provides an overview on the init script sequence for the Tizen platform.

Tizen Porting Guide


Page 17 of 143

In the Tizen SDK, rc.sysinit runs every scripts on rc3.d in the order indicated above. For example:

S05dlog is run for dlog.

S10sqlfs-mount and S12vconf-init is run for vconf which is configuration system for Tizen.

S20xserver is for xserver - Xorg, and window manager - enlightenment.

Others are run for each module. The scripts, which are not important for bringing up the menu screen, are launched after the S46menudaemon script.

In S46menudaemon script, register /opt/share/applications/*.desktop files, change the VCONFKEY_START value to 1, and then run the menu-screen.

The Tizen Git repository for the system-plugin-slp is https://review.tizen.org/git/adaptation/system-plugin-slp.git;a=summary

The rpm package installation of this plugin is: #zypper install system-plugin-slp

Note: Verify that the installation command is correct.

Tizen Porting Guide


Page 18 of 143

BSP Customization

This section covers the basic configuration, set up, and build procedure required for building the boot loader and the kernel image.

Bootloader Fundamentals Boot loader is a small piece of software that is required to perform the basic hardware and peripheral initialization and load the kernel to RAM. For the Tizen platform, the boot loader comes in two parts. The first part is the primary boot loader and the second part is the secondary boot loader. The primary boot loader is the Samsung proprietary boot loader and is also called s-boot. The secondary boot loader is the open source boot loader u-boot, which is customized further for the Tizen platform. If your platform is already loaded with the compatible boot loader software, then you can skip this section and move directly to the kernel section.

Bootloader Setup and Build Follow the steps to build the Tizen boot loader

SSet up OBS (Open Build Service) on the host system.

Get bootloader source from OBS, as shown below:

$ osc co TIZEN:2.0:System u-boot

Execute command to build the boot loader image:

$ osc build armv7el --no-verify --clean

Once the build is successful, the bootloader RPM package is created under /var/tmp/build-root/home/abuild/rpmbuild/

Create a bootloader tarball to download the boot loader onto the target

$ cd /var/tmp/build-root/home/abuild/rpmbuild/BUILD/u-boot-

0.1.1

$ tar cvf bootloader.tar u-boot.bin

Bootloader Commands Support The Tizen boot loader supports various commands, which are used with u-boot prompt before loading the kernel. Below are some examples of the commands used in boot loader.

Example:

usb

reset

printenv

Tizen Porting Guide


Page 19 of 143

setenv

saveenv

ramdump

pit

help

You can find the details about each command using the help command followed by the command name. Example:

<u-boot prompt> help ramdump

ramdump - Kernel lockup/panic logger

Usage:

ramdump show klog/dlog - log print on console

ramdump show blog <index[-1(default), 0]> - log print on console

ramdump save <ram/klog/dlog/blog/fb> - log save as file on UMS

ramdump logo - draw logo

ramdump check - check header info

Bootloader Kernel Parameters The command line parameters can be passed from boot loader to the kernel. Here are some example command line parameters. Example:

console=ttySAC2,115200n8

fbmem=24M@0x66800000

csa=/dev/mmcblk0p1

bootloader_log=1167@0x62d08010

Tizen Porting Guide


Page 20 of 143

Kernel Fundamentals

The kernel is the operating system that drives the platform. Here the kernel refers to the open source Linux kernel that is customized for the Tizen platform. The following section will give a brief overview about the Tizen kernel setup, configuration, and the build procedure for building a Linux kernel for your Tizen platform. The output of the kernel binary will be a uImage that is suitable only for u-boot boot loader. If you have chosen for a secure booting configuration in your boot loader, then this uImage should be compatible with your boot loader.

Kernel Configurations

To download the Tizen kernel source package, refer to “Getting Source code and Build” section in this document. Set up or modify your kernel configuration, use the appropriate defconfig file from arch/arm/configs/. For more detailed information about Tizen kernel configuration and kernel building, refer to the section “Kernel Build” under “Getting Source code and Build” in this document.

Note: Tizen uses INOTIFY and does not use DNOTIFY. So, you should disable DNOTIFY from your kernel configuration.

If you want to use initramfs, you can use these configurations:

CONFIG_INITRAMFS_SOURCE

CONFIG_INITRAMFS_ROOT_UID

CONFIG_INITRAMFS_ROOT_GID

CONFIG_INITRAMFS_COMPRESSION_NONE/GZIP/BZIP2/LZNA/LZO

Tizen Porting Guide


Page 21 of 143

Tizen File System

Virtual Filesystem (VFS )

The virtual file system (VFS) is an interesting aspect of the Linux kernel because it provides a common interface abstraction for file systems (ext2, jfs, ext4, etc...). The VFS provides a switching layer between the SCI (System call interface) and the file systems supported by the kernel, as shown in 7.1

Figure 7.1

At the top of the VFS is a common API abstraction of functions, such as open, close, read, and writes. At the bottom of the VFS are the file system abstractions that define how the upper-layer functions are implemented with respect to specific file system.

Below the file system layer is the buffer cache, which provides a common set of functions to the file system layer (independent of any particular file system). This caching layer optimizes access to the physical devices by keeping data around for a short time (or speculatively read ahead, so that the data is available when needed). Below the buffer cache are the device drivers, which implement the interface for the particular physical device.

Tizen Porting Guide


Page 22 of 143

Tizen Partition Layout

The following description is an example of the Tizen partition layout. The product vendor can modify the sequence or partition layout for their devices, as needed.

Figure 7.2 The ‘boot’ partition is mounted in ‘/boot’ of rootfs. Here s-boot, u-boot, and kernel image are saved as a file format, provided as system.tar. 1. CSA (Configuration Saved Area) is for non-volatile data that is calibration value of modem, etc. 2. The boot partition includes kernel image, boot-loader image, and modem image. Additionally, it can have device driver modules. 3. Third partition is reserved for the future. 4. The ‘platform’ partition is mounted on the root directory ( / ). It contains fundamental frameworks for Tizen and some general utility for Linux. It may be provided as platform.img file. 5. The ‘data’ partition is mounted on ‘/opt’ and it includes applications, libraries of applications, and the platform database. It may be provided as a data.img file. 6. CSC (Customer Software Configuration) ‘csc’ partition is mounted on '/mnt/csc'. It can store the customer’s software configuration, such as default language, time zone, etc. 7. UMS (USB Mass Storage) partition is mounted on ‘/opt/media’ and it includes default (media) contents. It may be provided as ums.img. 8. Each image file, ‘platform.img’, ‘data.img’, and ‘ums.img’ can be zipped for downloading, like IMAGE_NAME.tar.gz.

Tizen Porting Guide


Page 23 of 143

File-system Hierarchy Standard in Tizen Each partition has this hierarchy:

Figure 7.3

Supported filesystems in Tizen Filesystems that Tizen supports are Extended 4 (Ext 4) file-system, and MSDOS VFAT file-system. The Tizen kernel has to be compiled to enable support for the other file systems like JFS, XFS, BTRFS, and Reiserfs.

Default File-system in Tizen The Extended (Ext 4) file-system is configured as a default file-system for Tizen.

Configuration

The ext4 kernel configuration is done like this standard kernel configuration.

Reference

CONFIG_EXT4_FS=y CONFIG_EXT4_FS_XATTR=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y These are the configuration option to enable in kernel configuration file.

Tizen Porting Guide


Page 24 of 143

MMC

Description

Tizen supports MultiMediaCard, Secure Digital, and Secure Digital I/O Support. The MMC driver is implemented on top of host controller (such as SDHCI controller driver) and supports MMC, SD, SD High Speed, and SDHC cards. If MMC is your booting device, read-write APIs, partition management, and flashing should be provided at the boot loader.

Features Overview: The MMC/SD/SDIO driver supports these features:

The driver is built in-kernel MMC cards, including high speed cards SD cards, including SD high speed and SDHC cards

MMC subsystem code structure in kernel is at /driver/mmc

MMC subsystem structure is divided into three parts:

Tizen Porting Guide


Page 25 of 143

MMC block device driver /driver/mmc/card/

Protocol stack for MMC, SD, SDIO /driver/mmc/core/

Host controller driver /driver/mmc/host/

Hotplug MMC event handling in Tizen: Based on the hotplug event handling, the notification is passed to the System server for device status changes. It detects, mounts, and monitors the status of the sd card.

Reference

Kernel Configuration

CONFIG_MMC_BLOCK

CONFIG_MMC

CONFIG_MMC_SDHCI (For SDHCI host Interface enable)

sys interface: /dev/mmcblk0pX

Here ‘X’ denotes the MMC partition number. Details of partition mount point for Tizen are covered under Tizen partition Layout.

Tizen Porting Guide


Page 26 of 143

System

System Framework

Description

The System framework module abstracts low level system functions and manages the Tizen platform, in terms of platform policy, with the following major functionality.

The System framework contains these sub-components:

System server

The system server handles system events like out of memory, battery level, plug & play device status as well as handles process watchdog.

Power manager

The power manager is a session daemon that runs to manage the power for a system. It provides conditional state transition. The power manager transitions with any wakeup event, shifting to a higher power state. Similarly, based on timeouts, it transits to the next lower power state. The Tizen Power manager functionalities control display backlight dimming/off anddevice sleep.

Power manager conditional state transition

When an application such as a media player is running, there may be no input from the user for a long time, but the LCD should not be dimmed or turned off. Applications can request that the Power manager not change to a specific state.

Tizen Porting Guide


Page 27 of 143

Conditional state transition

Lock : keep system from entering lower state than specific state For example, lock(LCD_OFF) forces system to be in LCD_NORMAL, LCD_DIM or LCD_OFF. Unlock : allow system to enter lower state than specific state

Controlling the device’s power status and sleep mode. sys interface: /sys/power/state

/sys/power/wakeup_count

/dev/event0

/dev/event1

Device manager

Providing the interface to controlling all devices

LCD backlight dimming/off, application processor sleep

System monitoring and events handling from devices and system

Process/battery level/low memory monitoring

USB/MMC/charger/earjack event handling

Interfaces for accessing devices

LCD, touch, LED, vibrator, etc.

System OAL

The System OAL interface provides function pointers for OEMs to plug in their device/platform specific code to the System framework.

Tizen Porting Guide


Page 28 of 143

Porting OAL Interface

The OAL interface provides function pointers for OEMs to plugin their device/platform specific code to System framework. OEM developers should implement API defined in devman_plugin_intf.h and compile their library as libslp_devman_plugin.so. OEM APIs can be grouped as power, battery, haptics, LED, light, and memory. Device Manager (devman) upon initialization calls const OEM_sys_devman_plugin_interface* OEM_sys_get_devman_plugin_interface() , which in turn returns the address of implemented OEM APIs.If and when applications request device manager APIs then appropriate OEM APIs referred by OEM_sys_devman_plugin_interface would be called. Devman library uses sysfs for interfaces with device drivers and kernel. sysfs is a virtual file system provided by Linux 2.6 or above. Configuration: Install the OEM library as libslp_devman_plugin.so to /usr/lib

OAL API definitions are in the devman_plugin_intf.h header file: typedef struct {

int (*OEM_sys_get_display_count) (int *value);

int (*OEM_sys_get_backlight_min_brightness) (int index, int *value);

int (*OEM_sys_get_backlight_max_brightness) (int index, int *value);

int (*OEM_sys_get_backlight_brightness) (int index, int *value, int power_saving);

int (*OEM_sys_set_backlight_brightness) (int index, int value, int power_saving);

int (*OEM_sys_set_backlight_dimming) (int index, int value);

int (*OEM_sys_get_backlight_acl_control) (int index, int *value);

int (*OEM_sys_set_backlight_acl_control) (int index, int value);

int (*OEM_sys_get_lcd_power) (int index, int *value);

int (*OEM_sys_set_lcd_power) (int index, int value);

int (*OEM_sys_get_image_enhance_mode) (int *value);

int (*OEM_sys_set_image_enhance_mode) (int value);

int (*OEM_sys_get_image_enhance_scenario) (int *value);

int (*OEM_sys_set_image_enhance_scenario) (int value);

int (*OEM_sys_get_image_enhance_tone) (int *value);

int (*OEM_sys_set_image_enhance_tone) (int value);

int (*OEM_sys_get_image_enhance_outdoor) (int *value);

int (*OEM_sys_set_image_enhance_outdoor) (int value);

int (*OEM_sys_get_image_enhance_tune) (int *value);

int (*OEM_sys_set_image_enhance_tune) (int value);

int (*OEM_sys_image_enhance_info) (int *value);

int (*OEM_sys_set_display_frame_rate) (int value);

int (*OEM_sys_get_uart_path) (int *value);

int (*OEM_sys_set_uart_path) (int value);

int (*OEM_sys_get_usb_path) (int *value);

int (*OEM_sys_set_usb_path) (int value);

int (*OEM_sys_get_haptic_vibetones_level_max) (int *value);

Tizen Porting Guide


Page 29 of 143

int (*OEM_sys_get_haptic_vibetones_level) (int *value);

int (*OEM_sys_set_haptic_vibetones_level) (int value);

int (*OEM_sys_set_haptic_vibetones_enable) (int value);

int (*OEM_sys_set_haptic_vibetones_oneshot) (int value);

int (*OEM_sys_get_battery_capacity) (int *value);

int (*OEM_sys_get_battery_capacity_raw) (int *value);

int (*OEM_sys_get_battery_charge_full) (int *value);

int (*OEM_sys_get_battery_charge_now) (int *value);

int (*OEM_sys_get_battery_present) (int *value);

int (*OEM_sys_get_battery_health) (int *value);

int (*OEM_sys_get_battery_polling_required) (int *value);

int (*OEM_sys_get_jack_charger_online) (int *value);

int (*OEM_sys_get_jack_earjack_online) (int *value);

int (*OEM_sys_get_jack_earkey_online) (int *value);

int (*OEM_sys_get_jack_hdmi_online) (int *value);

int (*OEM_sys_get_jack_usb_online) (int *value);

int (*OEM_sys_get_jack_cradle_online) (int *value);

int (*OEM_sys_get_jack_tvout_online) (int *value);

int (*OEM_sys_get_jack_keyboard_online) (int *value);

int (*OEM_sys_get_leds_torch_max_brightness) (int *value);

int (*OEM_sys_get_leds_torch_brightness) (int *value);

int (*OEM_sys_set_leds_torch_brightness) (int value);

/* TODO: Change args type */

int (*OEM_sys_set_power_state) (int value);

/* TODO: Should determine enum values of wakeup_count nodes */

int (*OEM_sys_get_power_wakeup_count) (int *value);

int (*OEM_sys_set_power_wakeup_count) (int value);

int (*OEM_sys_get_memnotify_node) (char *node);

int (*OEM_sys_get_memnotify_victim_task) (int *value);

int (*OEM_sys_set_memnotify_threshold_lv1) (int value);

int (*OEM_sys_set_memnotify_threshold_lv2) (int value);

int (*OEM_sys_get_process_monitor_node) (char *node);

int (*OEM_sys_set_process_monitor_mp_pnp) (int value);

int (*OEM_sys_set_process_monitor_mp_vip) (int value);

int (*OEM_sys_get_cpufreq_cpuinfo_max_freq) (int *value);

int (*OEM_sys_get_cpufreq_cpuinfo_min_freq) (int *value);

int (*OEM_sys_get_cpufreq_scaling_max_freq) (int *value);

int (*OEM_sys_set_cpufreq_scaling_max_freq) (int value);

int (*OEM_sys_get_cpufreq_scaling_min_freq) (int *value);

int (*OEM_sys_set_cpufreq_scaling_min_freq) (int value);}

OEM_sys_devman_plugin_interface;

const OEM_sys_devman_plugin_interface *OEM_sys_get_devman_plugin_interface();

Device manager (devman) gets the pointer to the structure OEM_sys_get_devman_plugin_interface in variable plugin_intf, as shown below in the code. const OEM_sys_devman_plugin_interface *(*OEM_sys_get_devman_plugin_interface)

();

OEM_sys_get_devman_plugin_interface = dlsym(dlopen_handle,

"OEM_sys_get_devman_plugin_interface");

if ((error = dlerror()) != NULL) {

ERR("dlsym() failed: %s", error);

dlclose(dlopen_handle);

return;

}

Tizen Porting Guide


Page 30 of 143

plugin_intf = OEM_sys_get_devman_plugin_interface();

if (!plugin_intf) {

ERR("get_devman_plugin_interface() failed");

dlclose(dlopen_handle);

return;

}

OAL API reference implementation: Sample implementation code for OEM_sys_get_backlight_brightness()

This function gets the current brightness of the backlight unit and the output is stored in the variable “value”. The “value” can range from :0 <= value <= MAX_BACKLIGHT_BRIGHTNESS The path for input and output parameters of OEM APIs can be found in file devman_define_node_path.h #define BATTERY_CAPACITY_PATH "/sys/class/power_supply/battery/capacity"

#define BATTERY_CHARGE_FULL_PATH "/sys/class/power_supply/battery/charge_full"

#define BACKLIGHT_PATH "/sys/class/backlight/"

#define BACKLIGHT_MAX_BRIGHTNESS_PATH BACKLIGHT_PATH"%s/max_brightness"

#define BACKLIGHT_BRIGHTNESS_PATH BACKLIGHT_PATH"%s/brightness"

int OEM_sys_get_backlight_brightness(int index, int *value, int power_saving)

{

int ret = -1;

char path[MAX_NAME+1];

int max_brightness;

int pwr_saving_offset;

if (index >= DISP_MAX) {

devmgr_log("supports %d display node", DISP_MAX);

return ret;

}

snprintf(path, MAX_NAME, BACKLIGHT_BRIGHTNESS_PATH,

disp_info[index].bl_name);

ret = sys_get_int(path, value);

devmgr_log("path[%s]value[%d]power_saving[%d]", path, *value,

power_saving);

if (power_saving){

snprintf(path, MAX_NAME, BACKLIGHT_MAX_BRIGHTNESS_PATH,

disp_info[index].bl_name);

ret = sys_get_int(path, &max_brightness);

if (ret)

{

devmgr_log("Can't read max_brightness node[%s]", path);

return ret;

}

pwr_saving_offset = (PWR_SAVING_CANDELA_CRITERION *

max_brightness / MAX_CANDELA_CRITERION) + 0.5;

Tizen Porting Guide


Page 31 of 143

if (*value > max_brightness - pwr_saving_offset)

*value = max_brightness;

else

*value = *value + pwr_saving_offset;

devmgr_log("power_saving result[%d]", *value);

}

return ret;

}

The function, sys_get_int(path,value) provides access to kernel device driver node parameters. The parameter “path” is defined in the file devman_define_node_path.h , as described above. The value to be get/set is stored in parameter “value”. In similar ways , functions like sys_get_str, sys_set_int, sys_set_str, and sys_get_node are implemented to set/get the parameter values at the respective path. Here is the sample implementation for sys_get_int.

int sys_get_int(char *fname, int *val)

{

char buf[BUFF_MAX];

if (sys_read_buf(fname, buf) == 0) {

*val = atoi(buf);

return 0;

} else {

*val = -1;

return -1;

}}

static int sys_read_buf(char *file, char *buf)

{

int fd;

int r;

fd = open(file, O_RDONLY);

if (fd == -1) {

return -ENOENT;

}

r = read(fd, buf, BUFF_MAX);

if ((r >= 0) && (r < BUFF_MAX))

buf[r] = '\0';

else {

return -EIO;

}

close(fd);

return 0;

}

Tizen Porting Guide


Page 32 of 143

Power manager

The various power states include Normal, LCD_DIM, LCD_OFF, and SLEEP and the device can switch from one state to another, as shown in the above diagram. The values for different states The power states are defined in the below enum. typedef enum

{

POWER_STATE_NORMAL, /**< Normal state */

POWER_STATE_SCREEN_DIM, /**< Screen dim state */

POWER_STATE-SCREEN_OFF, /**< Screen off state */

} power_state_e;

Function Prototype Description (0-success, others -failure)

int (*OEM_sys_set_power_state) (int value); The function sets the device to suspend mode (0: Suspend Mode).

Mandatory

int (*OEM_sys_get_power_wakeup_count) (int *value);

The function gets the current “wakeup_count”. Mandatory

int (*OEM_sys_set_power_wakeup_count) (int value);

The function sets the “wakeup_count” with input value.

Mandatory

int (*OEM_sys_get_cpufreq_cpuinfo_max_freq) (int *value);

The function gets the limitation of max cpu frequency value : cpu frequency (KHz).

Optional

int (*OEM_sys_get_cpufreq_cpuinfo_min_freq) (int *value);

The function gets the limitation of min cpu frequency value : cpu frequency (KHz).

Optional

int (*OEM_sys_get_cpufreq_scaling_max_freq) (int *value);

The function gets the current max cpu frequency (CPUINFO_MIN_FREQ <= value <= CPUINFO_MAX_FREQ in KHz).

Optional

int (*OEM_sys_set_cpufreq_scaling_max_freq) (int value);

The function sets the current max cpu frequency (CPUINFO_MIN_FREQ <= value <= CPUINFO_MAX_FREQ in KHz).

Optional

int (*OEM_sys_get_cpufreq_scaling_min_freq) (int *value);

The function gets the current min cpu frequency (CPUINFO_MIN_FREQ <= value <= CPUINFO_MAX_FREQ in KHz).

Optional

int (*OEM_sys_set_cpufreq_scaling_min_freq) (int value);

The function sets the current min cpu frequency (CPUINFO_MIN_FREQ <= value <= CPUINFO_MAX_FREQ in KHz).

Optional

int (*OEM_sys_get_uart_path) (int *value); The function gets the current path of uart node (0: CP, 1: AP).

Optional

int (*OEM_sys_set_uart_path) (int value); The function sets the current path of uart node (0: CP, 1: AP).

Optional

int (*OEM_sys_get_usb_path) (int *value); The function gets the current path of usb node (0: CP, 1: AP).

Optional

int (*OEM_sys_set_usb_path) (int value); The function sets the current path of usb node (0: CP, 1: AP).

Optional

int (*OEM_sys_get_jack_charger_online) (int *value);

The function gets the charger online status (0: Offline, 1: Online).

Mandatory

Tizen Porting Guide


Page 33 of 143

int (*OEM_sys_get_jack_earjack_online) (int *value);

The function gets the earjack online status (0: Offline, 1: Online).

Mandatory

int (*OEM_sys_get_jack_earkey_online) (int *value);

The function gets the earkey online status (0: Offline, 1: Online).

Mandatory

int (*OEM_sys_get_jack_hdmi_online) (int *value);

The function gets the hdmi online status (0: Offline, 1: Online).

Optional

int (*OEM_sys_get_jack_usb_online) (int *value);

The function gets the usb online status (0: Offline, 1: Online).

Optional

int (*OEM_sys_get_jack_cradle_online) (int *value);

The function gets the cradle online status (0: Offline, 1: Online).

Optional

int (*OEM_sys_get_jack_tvout_online) (int *value);

The function gets the TV out online status (0: Offline, 1: Online).

Optional

int(*OEM_sys_get_jack_keyboard_online) (int *value);

The fuction gets the keyboard interface status. Optional

Vibrator

Vibrator interfaces are used to for accessing vibrator device. They provides functions to control and retrieve vibrator parameters.

Function Prototype Description (0: Success, Others: Failed)

int (*OEM_sys_get_haptic_vibetones_level_max) (int *value)

The function gets the max vibration feedback intensity level.

Optional

int (*OEM_sys_get_haptic_vibetones_level) (int *value)

The function gets the current vibration feedback intensity level (0 <= value <= VIBETONES_LEVEL_MAX).

Optional

int (*OEM_sys_set_haptic_vibetones_level) (int value)

The function sets the current vibration feedback intensity level (0 <= value <= VIBETONES_LEVEL_MAX).

Optional

int (*OEM_sys_set_haptic_vibetones_enable) (int value)

The function enables the vibration with current intensity level (0: Off, 1: On).

Mandatory

int (*OEM_sys_set_haptic_vibetones_oneshot) (int value)

The function enables the oneshot vibration with current intensity level (mili-second).

Optional

Image Enhancement

Image Enhancement interfaces provides functions to control the Image Quality Enhancement Algorithm.

Tizen Porting Guide


Page 34 of 143


int (*OEM_sys_get_image_enhance_mode) (int *value);

The function gets the mode of image enhance algorithm

(0 : DYNAMIC, 1 : STANDARD, 2 : NATURAL, 3 : MOVIE) Optional

int (*OEM_sys_set_image_enhance_mode) (int value);

The function sets the mode of image enhance algorithm

(0 : DYNAMIC, 1 : STANDARD, 2 : NATURAL, 3 : MOVIE) Optional

int (*OEM_sys_get_image_enhance_scenario) (int *value);

The function gets the scenario of image enhance algorithm

(0 : UI, 1 : GALLERY, 2: VIDEO, 3 : VTCALL, 4 : CAMERA, 5 : BROWSER, 6 : NEGATIVE, 7 : BYPASS)

Optional

int (*OEM_sys_set_image_enhance_scenario) (int value);

The function sets the scenario of image enhance algorithm

(0 : UI, 1 : GALLERY, 2: VIDEO, 3 : VTCALL, 4 : CAMERA, 5 : BROWSER, 6 : NEGATIVE, 7 : BYPASS)

Optional

int (*OEM_sys_get_image_enhance_tone) (int *value);

The function gets the tone of image enhance algorithm

(browser scenario - 0 : TONE_1, 1 : TONE_2, 2 : TONE_3) (other scenario - 0 : NORMAL, 1: WARM, 2: COLD)

Optional

int (*OEM_sys_set_image_enhance_tone) (int value);

The function sets the tone of image enhance algorithm

(browser scenario - 0 : TONE_1, 1 : TONE_2, 2 : TONE_3) (other scenario - 0 : NORMAL, 1: WARM, 2: COLD)

Optional

int (*OEM_sys_get_image_enhance_outdoor) (int *value);

The function gets the outdoor of image enhance algorithm

(0 : OUTDOOR_OFF, 1: OUTDOOR_ON) Optional

int (*OEM_sys_set_image_enhance_outdoor) (int value);

The function sets the outdoor of image enhance algorithm (0 : OUTDOOR_OFF, 1: OUTDOOR_ON)

Optional

int (*OEM_sys_image_enhance_info) (int *value);

This function reports whether Image Quality Enhancement Algorithm is supported

Optional

int (*OEM_sys_set_display_frame_rate) (int value);

The function sets the frame rate of LCD

(0 : OFF - 60HZ, 1 : ON - 40HZ) Optional

Light

Light interfaces provides functions to control light, brightness, and get and set brightness of LED and to control power status of LCD power.


int (*OEM_sys_get_backlight_max_brightness) (int index, int *value)

The function gets the max brightness of backlight unit.

Mandatory

Int (*OEM_sys_get_backlight_min_brightness) (int index, int *value)

The function gets the min brightness of backlight unit.

Mandatory

int (*OEM_sys_get_backlight_brightness) (int index, int *value, int power_saving)

The function gets the current brightness of backlight unit (0 <= value <= MAX_BACKLIGHT_BRIGHTNESS).

Mandatory

int (*OEM_sys_set_backlight_brightness) (int index, int value, int power_saving)

The function sets the current brightness of backlight unit (0 <= value <= MAX_BACKLIGHT_BRIGHTNESS).

Mandatory

Tizen Porting Guide


Page 35 of 143

int (*OEM_sys_set_backlight_dimming) (int index, int value)

The function sets the dimming status of backlight unit (0: Off, 1: On).

Mandatory

int (*OEM_sys_get_backlight_acl_control) (int index, int *value)

The function gets the current ACL control status of backlight unit (0: Off, 1: On).

Optional

int (*OEM_sys_set_backlight_acl_control) (int index, int value)

The function sets the current ACL control status of backlight unit (0: Off, 1: On).

Optional

int (*OEM_sys_get_lcd_power) (int index, int *value)

The function gets the current LCD power status (0: Off, 1: On).

Optional

int (*OEM_sys_set_lcd_power) (int index, int value)

The function sets the current LCD power status (0: Off, 1: On).

Optional

int (*OEM_sys_get_leds_torch_max_brightness) (int *value)

The function gets the max brightness of the led torch.

Optional

int (*OEM_sys_get_leds_torch_brightness) (int *value)

The function gets the current brightness of the led torch (0 <= value <= TORCH_MAX_BRIGHTNESS).

Optional

int (*OEM_sys_set_leds_torch_brightness) (int value)

The function sets the current brightness of the led torch (0 <= value <= TORCH_MAX_BRIGHTNESS).

Optional

Keytouch OAL interfaces

Key and touch event OAL interfaces uses standard input driver methods. These interfaces are used to get the key and touch events. The standard input structure in include/linux/input.h is: struct input_event {

struct timeval time; __u16 type; __u16 code; __s32 value;

};

Battery

Battery Interfaces provide access to battery status functions to retrieve current battery status information.

Function Name Description (0: Success, Others: Failed)

int (*OEM_sys_get_battery_capacity) (int *value)

The function gets the current battery capacity (0 %< value < 100%).

Mandatory

int (*OEM_sys_get_battery_capacity_

The function gets the current battery capacity (0% < value < 10000%).

Mandatory

Tizen Porting Guide


Page 36 of 143

raw) (int *value)

int (*OEM_sys_get_battery_charge_full) (int *value)

The function gets the current battery full charge status (0: Not full charge, 1: Full charge).

Mandatory

int (*OEM_sys_get_battery_charge_now) (int *value)

The function gets the battery charging status (0: Not charging, 1: Charging).

Mandatory

int (*OEM_sys_get_battery_present) (int *value)

The function gets the battery installation status (0: Not charging, 1: Charging).

Mandatory

int (*OEM_sys_get_battery_health) (int *value)

The function gets the temperature status (0: UNKNOWN, 1: good, 2: overheat, 3: dead 4: overvoltage, 5: unspecified, 6: cold, 7: health max

Optional

Utility

These utility OAL interfaces monitor process, notify low memory warning, and kill the process.

Function Name Description (0: Success, Others: Failed)

int (*OEM_sys_get_memnotify_node) (char *node);

The function gets the node of out of memory notification.

Mandatory

Int (*OEM_sys_get_memnotify_victim_task) (int *value);

The function gets the pid of victim process to be killed in OOM.

Mandatory

Int (*OEM_sys_set_memnotify_threshold_lv1) (int value);

The function sets the memory size of thershold OOM level 1.

Mandatory

Int (*OEM_sys_set_memnotify_threshold_lv2) (int value);

The function sets the memory size of thershold OOM level 2.

Mandatory

Int (*OEM_sys_get_process_monitor_node) (char *node);

The function gets the node that send pid of unexpected killed proccess.

Mandatory

Int (*OEM_sys_set_process_monitor_mp_pnp) (int value);00

The function sets the pid of the process regarded as a permanent process.

Mandatory

Int (*OEM_sys_set_process_monitor_mp_vip) (int value);

The function sets the pid of the process regarded as vip process type.

Mandatory

Configuration

None

Reference

Packagename: device-manager-plugin-exynos Include file : devman_define_node_path.h

Tizen Porting Guide


Page 37 of 143

Source file: device_manager_plugin_exynos.c

PM Kernel Configuration Power management options

[*] Power Management support

Linux Suspend Resume Code is located at kernel/power Generic Device/Bus suspend resume code located at drivers/base/power/ Device/Bus level suspend resume code in .suspend and .resume callbacks for each device driver or bus driver

sys interface: /sys/kernel/power/

CPU Idle

It is a generic framework for supporting software-controlled idle processor power management. It includes modular cross-platform governors that can be swapped during runtime.

[*] CPU idle PM support

The default CPU Idle governor is the menu governor and the code is located at drivers/cpuidle.

sys interface: /sys/devices/system/cpu/cpuidle/

CPU DVFS

It allows you to change the clock speed of CPUs on the fly. This is a nice method to save power, because the lower the CPU clock speed, the less power the CPU consumes.

There are different generic CPU frequency governors, like performance, powersave, userspace,

Tizen Porting Guide


Page 38 of 143

ondemand, etc., to control transitions among various Operating Points. The code is located at drivers/cpufreq.

sys interface: /sys/devices/system/cpu/cpufreq/

CPU Hotplug

In addition to the above, Tizen Power management provides extra features to support dynamic cpu hotplug to reduce power consumption.

To enable this feature, select this configuration:

-*- Support for hot-pluggable CPUs (EXPERIMENTAL)

sys interface: /sys/devices/system/cpu/

To support dynamic CPU hotplug to reduce power consumption, select this configuration System Type Support dynamic cpu hotplug

sys interface: /sys/module/pm_hotplug/

System OAL Kernel configuration

CONFIG_SLP_PROCESS_MON CONFIG_INPUT CONFIG_INPUT_MISC CONFIG_INPUT_MOUSEDEV(Optional) CONFIG_INPUT_KEYBOARD(Optional) CONFIG_INPUT_TOUCHSCREEN(Optional) CONFIG_FB CONFIG_FB_S3C CONFIG_BACKLIGHT_CLASS_DEVICE CONFIG_LCD_CLASS_DEVICE CONFIG_LCD_S6E8AA0 CONFIG_MMC CONFIG_MMC_BLOCK CONFIG_MMC_SDHCI_S3C CONFIG_MMC_S3C_DEV_HSMMC* CONFIG_USB_EXYNOS_SWITCH CONFIG_UART_SELECT CONFIG_VIBETONZ CONFIG_CHARGER_MANAGER CONFIG_PM CONFIG_PM_SLEEP

Tizen Porting Guide


Page 39 of 143

CONFIG_JACKMON CONFIG_CPU_FREQ CONFIG_RTC_DRV_S3C CONFIG_RTC_DRV_MAX8997

Tizen Porting Guide


Page 40 of 143

Sensor Framework

Description

Sensor devices are used widely in mobile devices to enhance user experience. Most modern mobile OSs have a framework which manages sensor hardware on the platform and provides convenient API to the application.

Types of Sensors

Tizen supports individual plugin frameworks for these sensors:

Accelerometer sensor

Gyroscope sensor

Proximity sensor

Motion sensor

Geomagnetic sensor

Light sensor

Note: Details are not available for Ambient light, Magnetic sensors

Accelerometer sensor

The accelerometer sensor is used to measure the acceleration of the device. The three dimensional coordinate system is used to illustrate the direction of the acceleration. When a phone is moving along an axis, the acceleration is positive if it moves in a positive direction.

Gyroscope sensor

A gyroscope is a device used primarily for navigation and measurement of angular velocity. Gyroscopes measure how quickly an object rotates. This rate of rotation can be measured along any of the three axes X, Y, and Z.

Proximity sensor

A proximity sensor can detect the presence of nearby objects without any physical contact. That is, it indicates if the device is close or not close to the user.

Motion sensor

A motion sensor is a virtual sensor that uses the accelerometer and gyroscope sensors. Motion sensor detects snap, panning, tilt, shake, overturn, and double tap event.

Geomagnetic sensor

A geomagnetic sensor indicates the strength of the geomagnetic flux density in the X, Y, and Z axes. This sensor is used to find the orientation of a body, which is a description of how it is aligned to the space it is in.

Light sensor

A light sensor measures the amount of light that it receives or the surrounding light conditions. The ambient light state is measured as a step value, where 0 is very dark and 10 is bright sunlight.

Tizen Porting Guide


Page 41 of 143

Figure: Sensor Framework Architecture

Components of Sensor Framework

The Sensor framework provides a sensor server for creating plugins and a medium through which the client applications are connected to the sensor hardware to exchange data. The sensor plugins retrieve data from sensor hardware and enable the client applications to use the data for specific requirements. Here's the description of the sensor framework components:

Sensor Library

The application that wants to access the sensor service should communicate with the daemon through the sensor API library. An API library allows the application to access the sensor service. As shown in the below diagram, applications/middleware frameworks can have the sensor-framework client library in the process context.

Sensor Server

The sensor server is a daemon which communicates uniquely to sensor drivers in the system and dispatches sensor data to the application. The sensor server takes care of interacting with the sensor driver in hardware initialization, driver configuration, and data fetching, to manage

Tizen Porting Guide


Page 42 of 143

all sensors on the platform.

Type of plugins in sensor framework

Sensor Plugin

Sensor plugins takes care of interacting with the sensor driver. Plug-ins process data from sensor drivers and communicate it to the sensor server. Processor: Active component (it has a thread) that processes data or makes events from a filter or from sensor data. Filter: Passive component that converts sensor raw data to other types of data Sensor: Passive component that gets raw data from the kernel node

Figure: Sensor Framework Components


The sensor OAL includes the processor plugin, the filter plugin, and the sensor plugin. The accelerometer sensor (accel) is taken as an example to illustrate each plugin prototype implementation.

Processor Plugin

Active component (it has a thread) that processes data or makes events from a filter or from sensor data.

Tizen Porting Guide


Page 43 of 143

Prototype implementation of processor plugin

class accel_processor : public cprocessor_module {

public:

/*define enums*/

/*define structures*/

accel_processor();

virtual ~ accel_processor();

const char *name(void);

int id(void);

int version(void);

bool update_name(char *name);

bool update_id(int id);

bool update_version(int version);

bool add_input(csensor_module * sensor);

bool add_input(cfilter_module * filter);

long value(char *port);

long value(int id);

cprocessor_module *create_new(void);

void destroy(cprocessor_module * module);

static void *working(void *inst);

static void *stopped(void *inst);

virtual bool start(void);

virtual bool stop(void);

bool add_callback_func(cmd_reg_t * param);

bool remove_callback_func(cmd_reg_t * param);

bool check_callback_event(cmd_reg_t * param);

long set_cmd(int type, int property, long input_value);

int get_property(unsigned int property_level, void *property_data);

int get_struct_value(unsigned int struct_type, void *struct_values);

bool waiting_for_data(unsigned long time_us, bool real_update = false);

private: /* Define private data structures and functions*/ };

Refer to the Appendix for sensor the processor plugin API’s.

Sensor Plugin

A passive component that gets raw data from the kernel node.

Prototype implementation sensor plugin

class caccel:public csensor_module {

public:

/*define enums*/

/*define structures*/

caccel();

virtual ~ caccel();


int version(void);

Tizen Porting Guide


Page 44 of 143

int id(void);

bool is_data_ready(bool wait = false);

long value(const char *port);

long value(int id);


bool update_version(int ver);


int port_count(void);

const char *port(int idx);

bool need_polling(void);

long polling_interval(void);

bool update_polling_interval(unsigned long val);

int get_sensor_type(void);




bool calibration(int iteration);

int check_hw_node(void);

bool start(void);

bool stop(void);

void reset(void);

private:

/* Define private data structures and functions*/

};

Prototype Description bool is_data_ready(bool wait)

When sensor data is available that can be read from sensor node, then return that status. This function waits during polling time and calls update_value. If wait is true, then wait during polling interval time.

int port_count(void)

Returns the port count in sensor. For example, accelerometer sensor has X, Y, Z port. In this case, port_count function return 3.

const char *port(int idx)

Returns port name by index number. When port(0) called in the accelerometer sensor, then this function returns ‘x’.

void reset(void)

Reset s sensor node.

bool start(void) / bool stop(void)

This function enables or disables the sensor. It is the interface for the on or off function for the sensor. It starts or stops function success, then returns true. Otherwise, it returns false.

bool need_polling(void)

This function announces that sensor’s data reading type is polling or interrupt. If it is true, it is polling, otherwise it is interrupt.

Tizen Porting Guide


Page 45 of 143

long polling_interval(void)

It senses the need to poll data. Then returns the polling interval time by ms.

bool update_polling_interval(unsigned long val)

Updates polling interval by ms.

void lock(void)

Locks the sensor and blocks the other component’s access.

void unlock(void)

Unlocks the sensor and releases the other component's access.

Filter Plugin

A passive component that converts sensor raw data to other types of data.

Prototype implementation filter plugin class caccel:public csensor_module {

public:

/* Define enums*/

/* Define structures*/

caccel();

virtual ~ caccel();


int version(void);

int id(void);

bool is_data_ready(bool wait = false);

long value(const char *port);

long value(int id);


bool update_version(int ver);


int port_count(void);

const char *port(int idx);

bool need_polling(void);

long polling_interval(void);

bool update_polling_interval(unsigned long val);

int get_sensor_type(void);




bool calibration(int iteration);

int check_hw_node(void);

bool start(void);

Tizen Porting Guide


Page 46 of 143

bool stop(void);

void reset(void);

private:

/* Define private data structures and functions*/

}

Configuration

Sensor Framework loads configuration files sf_sensor.conf , sf_filter,conf , sf_processor.conf , sf_datastream.conf for loading sensor, filter, and processor plugins. Each configuration file supports the following fields and values:

disable=yes/no override=yes/no path=Absolute path of a component id=decimal version=decimal

Between [ and ], the names of plugin are placed. If don’t want to use the plugin, set disable to yes Example of a sample configuration file:

[kxsd9_sensor] disable=no override=yes path=/opt/x1/lib/sensor_framework/libkxsd9.so id=1111 version=1 poll=100 [ak8973b_sensor] disable=yes override=yes path=/opt/x1/lib/sensor_framework/libak8973b.so id=1113 version=1 poll=100

Reference Reference kernel configuration for sensors, will vary with different vendor types.

Sensor components Kernel Config Device nodes

Accelerometer CONFIG_INPUT_KR3DH

/dev/input/event0/ /dev/ input/event1/ /dev/ input/event2/

Tizen Porting Guide


Page 47 of 143

/dev/ input/event3/ /dev/ input/event4/ /dev/ input/event5/

Proximity CONFIG_INPUT_GP2A Light sensor CONFIG_INPUT_GP2A Electronic compass CONFIG_SENSORS_AK8975

Tizen Porting Guide


Page 48 of 143

Graphics and UI

This figure provides a brief overview of the Tizen UI and graphics architecture.

Description:

Tizen provides high performance 3D graphics as a component of UI & Graphics, as shown in the figure above. There are hardware-accelerated OpenGL ES (Open Graphics Library Embedded System) and EGL (Embedded-System Graphics Library) for 3D applications, such as 3D games. OpenGL ES is an application programming interface (API) for advanced 3D graphics, targeted at handheld and embedded devices. To overcome device constraints, such as, limited processing capabilities and memory availability, it provides a subset of the functionality in OpenGL. But embedded system-specific features were added to enhance rendering efficiency, such as, precision qualifiers to the shading language from OpenGL ES 2.0.

OpenGL

3D Graphics Library

The diagram provides an overview of the interface for Tizen high performance 3D graphics library with OpenGL.

Tizen Porting Guide


Page 49 of 143

Description:

EGL is a “glue” layer between OpenGL ES and the underlying native platform window system - X window system. EGL communicates with X Window to get information from the application window. And it creates a drawing surface and manages rendering context and resources.

Description of each component of 3D Graphics:

OpenGL ES (Open Graphics Library Embedded System)

OpenGL is a software interface to graphics hardware.

It is designed as a hardware-independent interface to be used for many different hardware platforms.

OpenGL ES is a subset of the OpenGL designed for embedded systems.

OpenGL ES accepts primitives, such as points, lines, and triangles, and converts them into pixels using a graphics pipeline, known as the OpenGL state machine.

EGL (Embedded-System Graphics Library)

Tizen Porting Guide


Page 50 of 143

EGL is a (mostly) platform-independent API and an interface between rendering APIs,

such as OpenGL ES or OpenVG and an underlying native platform window system.

It communicates with X window system, and creates drawing surfaces and manages

rendering contexts.

EGLDisplay (X Display): Encapsulates all of the system dependencies for interfacing

with the native windowing system.

EGLSurface: Encapsulates rendering destinations (window surface, pixmap surface),

which are tied to X Window and X Pixmap.

EGLContext: Encapsulates OpenGL ES rendering context, which holds the state of GL

server/client.

The following diagram gives a brief overview of EGL interface.

Porting

3D graphics vendors must provide these porting requirements for OpenGL ES/EGL:

OpenGL ES

The required version of OpenGL ES: 1.1 and 2.0

The driver must support the following extensions to OpenGL ES 1.1:

GL_OES_framebuffer_object GL_OES_blend_subtract GL_OES_blend_func_separate GL_OES_matrix_palette GL_OES_draw_texture GL_OES_texture_cube_map GL_OES_query_matrix

Tizen Porting Guide


Page 51 of 143

GL_OES_point_size_array

The driver must support the following extensions to OpenGL ES 2.0:

GL_OES_EGL_image GL_EXT_texture_format_BGRA8888 GL_OES_get_program_binary GL_OES_texture_npot GL_OES_fragment_precision_high GL_OES_rgb8_rgba8 GL_OES_depth24 GL_OES_vertex_half_float GL_OES_texture_float GL_OES_compressed_ETC1_RGB8_texture GL_OES_packed_depth_stencil GL_OES_standard_derivatives GL_OES_element_index_uint GL_OES_mapbuffer GL_EXT_multi_draw_arrays GL_OES_vertex_array_object GL_IMG_texture_compression_pvrtc GL_OES_read_format GL_EXT_multisampled_render_to_texture

You need some tools for generating a binary shader on Linux.

EGL

The minimum version required for EGL is 1.4. EGL must support DRI2. Common 3D applications use DRI2 based EGL. The 3D composite window manager needs DRI2 based EGL usually.

FBDEV based EGL( optional )

The FBDEV should consist of a triple buffer. It should be performed with page flipping instead of copying the buffer. To avoid tearing problem, perform with LCD vsync signal. Usually, compositor enables

vsync using eglSwapInterval() API.

DRI2 based EGL( mandatory )

It’s a very important requirement. It should be performed with X11 DRI2 protocol.

Tizen Porting Guide


Page 52 of 143

It should support texture from pixmap. (using EGL_KHR_image_pixmap and GL_OES_EGL_image)

GPU synchronization API

To avoid flickering, we need an internal EGL API, which is used to wait for completion of the buffer copy command.

Limitation of EGL surface

The FBDEV should consist of a triple buffer. The driver must support the following extensions to EGL 1.4:

EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_image_pixmap EGL_KHR_lock_surface EGL_KHR_fence_sync EGL_KHR_reusable_sync EGL_IMG_context_priority

Need some method to allow the CPU to read and write the texture memory area of GPU

Header and Library name

Header files and libraries should be provided according to the Khronos API Implementers Guide. The following table gives a brief overview about the EGL library path and the respective header files.

LIBRARY PATH FILES

/usr/include/EGL egl.h eglext.h eglplatform.h

/usr/include/GLES gl.h glext.h glplatform.h

/usr/include/GLES2 gl2.h gl2ext.h gl2platform.h

/usr/include/KHR khrplatform.h

Tizen Porting Guide


Page 53 of 143

/usr/lib libEGL.so libGLESv1_CM.so libGLESv2.so

Note:

You may need to implement some memory management techniques for sharing memory between your CPU and the graphics processing unit.

Tizen Porting Guide


Page 54 of 143

X server

X server is an X Window System display server that provides a basis for Graphical User Interface (GUI) and rich input capabilities for your system. It creates a hardware abstraction layer where software is written to use a generalized set of commands, allowing for device independence and reuse of programs on any system that implements X.

Input Driver The following figure provides a basic introduction about X window system and X input driver.

Description:

X Window System

X Window system provides the interface for the manipulation of resources, which are windows, pixmap, gc, etc. X clients send the requests to the X server for drawing something or for manipulating windows. The X server accepts the clients’ requests and sends back replies to the requests. In addition, the X server sends X events when input events from input devices are

Tizen Porting Guide


Page 55 of 143

pending or when X server encounters something that the X client may be interested in, such as configure or exposure events. X server: The X server reads event(s) from the internal event queue and makes/sends X event(s) to the X client(s). X input driver: X input driver reads input event stream from each input device node, makes X internal event(s), and put the event(s) into X server's internal event queue. For doing this, X input driver mainly uses interfaces implemented on xf86 DDX layer inside X server.

evdev driver

Implements for reading input event(s) stream originated from kernel evdev subsystem and for creating X internal event(s).

Supports device(s) such as keyboard, mouse, touchpad, touch screen, and so on.

evdev multi-touch driver

Implements for reading MT protocol event stream originated from kernel evdev subsystem, for interpreting them and for creating X internal event(s).

Supports touch screen device(s).

Porting OAL Interface:

The following section provides a brief understanding about X server and X input driver.

Evdev module: An evdev contains these drivers:

Driver for absolute pointing device like touch-screen.

Driver for relative pointing device like mouse.

Driver for key (board) device, including HW key and BT/USB keyboard.

Each driver sets up each input device, and will depends on X server's configuration.

After the device setup is done, the device reads input event(s) from device node, creates internal event(s) and put them in input event queue inside X server.

To make X input driver working, module must be loaded and must be registered as an input driver by X server.

Module, driver and device must provide following(s): o Module: module information. o Driver: driver information. o Device: read() for reading input event(s), proc() for controlling device status.

Refer to the following link, which contains information about the data structures and functions for each module and device.

http://www.x.org/wiki/Development/Documentation/XorgInputHOWTO


Tizen Porting Guide


Page 56 of 143

The module's basic information will be stored inside XF86ModuleData (xf86Module.h) and will be provided to X server.

Configuration

ServerFlags

AllowEmptyInput: "true" means that X server will be started without any keyboard/mouse driver.

AutoAddDevices: "false" means that hot plugged input device(s) will not be supported.

AutoEnableDevices: "true" means that 'DevicePresenceNotify event will be sent to all X client(s) by default.

InputClass

Identifier: sets unique input device name.

Driver: sets driver for device.

MatchDevicePath: sets path of device node to be handled by the device. Wildcard can be used.

Option: sets known option(s) and custom option(s) to be used inside driver for setting up device(s) or for

Enabling/disabling certain feature(s). Integer, Boolean, string type can be used.

MatchIsTouchScreen, MatchIsTablet, MatchIsPointer, MatchIsKeyboard

Checks that the found device matches one of above device type and sets the type for the device if matched.

Tizen extension for Evdev multi-touch driver

Provides one legacy single touch protocol

Provides two kinds of MT protocol o MT protocol A (which includes Tracking ID) o MT protocol B

Supporting new touch protocol can be done by one of followings: o Implementation of new touch protocol inside driver. o Cloning evdev multi-touch driver and implementation new touch protocol

inside the driver. o Conversion from new protocol to existing protocol, which is supported by

evdev multi-touch driver.

Tizen Porting Guide


Page 57 of 143

Video Driver The following figure provides a brief overview about the X server and the X video driver.

Description:

X Window System:

X Window system provides the interface for the manipulation of resources, which are windows, pixmap, gc, etc. X clients send the requests to X server for drawing something or for manipulating windows. X server accepts the clients’ requests and sends back replies to the requests. In addition, the X server sends X events to the client when input events from devices are pending or when X server encounters events that the X client may be interested, such as configure or exposure events.

X server

X server gets the requests from X clients and delivers them to the xf86 porting layer. Input events are processed by the X server and the X server sends them to the X clients.

X video driver

The X video driver is the driver library, which contains the implementation to support xf86 DDX layer, to display something to a screen.

Driver Module: o Implementation of a driver module for xf86 DDX.

Mode Setting: o Implementation for the devices to display images on it.

EXA:

Tizen Porting Guide


Page 58 of 143

o Implementation for Graphic acceleration Architecture. Memory allocation and exa draw primitives.

DRI2: o Implementation for DRI2 (Direct Rendering Infrastructure ver.2).

XV: o XFree86 offers the X Video Extension (XV), which allows clients to treat video

as any other primitive and ``Put'' video into drawables mode. By default, the extension reports no video adaptors as being available because the DDX layer has not been initialized.

Mode Setting

Kernel module for Display mode setting.

Functionality: o Crtc control and management o Connector control and management o Encoder control and management o Framebuffer control and management

MemMgr

Kernel module for graphic memory management.

Functionality: o control by mode setting o control by GPU o shared memory among processes

Device Driver:

Video controller hardware to control the kernel side of the module.

Porting OAL Interface:

The X video driver should implement the following driver module and extensions, using the interface provided by xf86 DDX and X extensions in the X server.

Driver Module

XF86ModuleData: o A symbol data which the X server finds when the X server load drivers. o The name of data is defined as modnameModuleData format. modname is the

name of the X video driver.

Example:

XF86ModuleData of sec_drv.so driver is defined below:

Tizen Porting Guide


Page 59 of 143

_X_EXPORT XF86ModuleData secModuleData = {&SECVersRec, SECSetup, NULL};

References Header: For xf86 header information, refer to this link:

http://source.tizen.org/git/?p=pkgs/xorg/server/xorg-server.git;a=blob;f=hw/xfree86/common/xf86Module.h

To implement a driver module, refer to this link : http://www.x.org/releases/X11R7.6/doc/xorg-server/DESIGN.txt

ScrnInfoPtr

The data structure should be initialized during the initialization of X video driver.

The probe functions are called when initializing the X server. The function pointers are mapped in the probe function of the X video driver.

The variables of ScrnInfoPtr set up by the function pointers of ScrnInfoPtr.

The function pointers of ScrnInfoPtr:

xf86ProbeProc *Probe

xf86PreInitProc *PreInit

xf86ScreenInitProc *ScreenInit

xf86SwitchModeProc *SwitchMode

xf86AdjustFrameProc *AdjustFrame

xf86EnterVTProc *EnterVT

xf86LeaveVTProc *LeaveVT

xf86ValidModeProc *ValidMode

References Header: For detailed header information, refer to this link:

http://source.tizen.org/git/?p=pkgs/xorg/server/xorg-server.git;a=blob;f=hw/xfree86/common/xf86str.h

Mode Setting:

xf86CrtcConfigPtr o The data structure contains the information of outputs, crtcs, and the

configuration of outputs and crtcs. o The function pointers, which is xf86CrtcConfigFuncsRec *funcs, has to be set in

the X video driver. o The function pointers of xf86CrtcConfigFuncsRec are: o Bool (*resize)(ScrnInfoPtr scrn, int width, int height);

References Header:

http://source.tizen.org/git/?p=pkgs/xorg/server/xorg-server.git;a=blob;f=hw/xfree86/modes/xf86Crtc.h

http://source.tizen.org/git/?p=pkgs/xorg/server/xorg-server.git;a=blob;f=hw/xfree86/common/xf86Module.h

http://www.x.org/releases/X11R7.6/doc/xorg-server/DESIGN.txt




Tizen Porting Guide


Page 60 of 143

xf86CrtcPtr o The data structure contains the information of a crtc. o The X video driver creates the number of instances of crtcs as the number of

hardware crtcs. o The function pointers, which xf86CrtcFuncsRec *funcs, needs to be set in the X

video driver. o The function pointers of xf86CrtcFuncsRec are :

Bool (*set_mode_major)(xf86CrtcPtr crtc, DisplayModePtr mode,

Rotation rotation, int x, int y);

void (*set_cursor_colors) (xf86CrtcPtr crtc, int bg, int fg);

void (*set_cursor_position) (xf86CrtcPtr crtc, int x, int y);

void (*show_cursor) (xf86CrtcPtr crtc);

void (*hide_cursor) (xf86CrtcPtr crtc);

void (*load_cursor_argb) (xf86CrtcPtr crtc, CARD32 *image);

void (*destroy) (xf86CrtcPtr crtc);

Reference Header


xf86OutputPtr

The data structure contains the information of an output.

The X video driver creates the number of instances of outputs as the number of hardware connectors.

The function pointers, which xf86OutputFuncsRec *funcs, has to be set in the X video driver.

The function pointers of xf86OutputFuncsRec are:

void (*create_resources)(xf86OutputPtr output);

Bool (*set_property)(xf86OutputPtr output, Atom property,

RRPropertyValuePtr value);

Bool (*get_property)(xf86OutputPtr output, Atom property);

xf86OutputStatus (*detect)(xf86OutputPtr output);

int (*mode_valid)(xf86OutputPtr output, DisplayModePtr pMode);

DisplayModePtr (*get_modes)(xf86OutputPtr output);

void (*destroy) (xf86OutputPtr output);

Reference Header


EXA

ExaDriverPtr o The data structure contains the information on the X graphic acceleration.



Tizen Porting Guide


Page 61 of 143

o It contains the functionality of memory allocation of pixmap private and EXA drawing primitives.

o It contains the function pointers and the variables to be implemented by the X video driver.

o The function pointers and variables of ExaDriverPtr are:

int exa_major, exa_minor;

CARD8 *memoryBase;

unsigned long offScreenBase;

unsigned long memorySize;

int pixmapOffsetAlign;

int pixmapPitchAlign;

int flags;

int maxX;

int maxY;

void (*WaitMarker) (ScreenPtr pScreen, int marker);

Bool (*PrepareAccess)(PixmapPtr pPix, int index);

void (*FinishAccess)(PixmapPtr pPix, int index);

void *(*CreatePixmap)(ScreenPtr pScreen, int size, int align);

void (*DestroyPixmap)(ScreenPtr pScreen, void *driverPriv);

Bool (*ModifyPixmapHeader)(PixmapPtr pPixmap, int width, int

height, int depth, int

bitsPerPixel, int devKind, pointer pPixData);

Bool (*PixmapIsOffscreen)(PixmapPtr pPix);

Bool (*PrepareSolid) (PixmapPtr pPixmap, int alu, Pixel planemask,

Pixel fg);

void (*Solid) (PixmapPtr pPixmap, int x1, int y1, int x2, int y2);

void (*DoneSolid) (PixmapPtr pPixmap);

Bool (*PrepareCopy) (PixmapPtr pSrcPixmap, PixmapPtr pDstPixmap,

int dx, int dy, int alu,

Pixel planemask);

void (*Copy) (PixmapPtr pDstPixmap, int srcX, int srcY, int dstX,

int dstY, int width, int

height)

void (*DoneCopy) (PixmapPtr pDstPixmap);

Bool (*CheckComposite) (int op, PicturePtr pSrcPicture,

Pictureptr pMaskPicture, PicturePtr

pDstPicture);

Bool (*PrepareComposite) (int op, , PicturePtr pSrcPicture,

Pictureptr pMaskPicture,

PicturePtr pDstPicture, PixmapPtr pSrc, PixmapPtr, pMask,

PixmapPtr pDst);

void (*Composite) (PixmapPtr pDst, int srcX, int srcY, int maskX,

int maskY, int dstX, int dstY,

int width, int height);

void (*DoneComposite) (PixmapPtr pDst);

Bool (*UploadToScreen) (PixmapPtr pDst, int x, int y, int w, int

h, char *src, int src_pitch);

Bool (*DownloadFromScreen)(PixmapPtr pSrc, int x, int y, int w,

int h, char *dst, int dst_pitch);

Tizen Porting Guide


Page 62 of 143

Reference Header

http://source.tizen.org/git/?p=pkgs/xorg/server/xorg-server.git;a=blob;f=exa/exa.h

DRI2

DRI2InfoPtr o The data structure for DRI2 (Direct Rendering Infrastructure ver.2) o The role is management and control of DRI2 buffers. o It contains the function pointers and the variables to be implemented by the X

video driver. o The function pointers and variables of DRI2InfoPtr are:

const char *driverName;

const char *deviceName;

int fd;

DRI2CreateBufferProcPtr CreateBuffer;

DRI2DestroyBufferProcPtr DestroyBuffer;

DRI2CopyRegionProcPtr CopyRegion;

DRI2ScheduleSwapProcPtr ScheduleSwap;

DRI2GetMSCProcPtr GetMSC;

DRI2ScheduleWaitMSCProcPtr ScheduleWaitMSC;

DRI2AuthMagicProcPtr AuthMagic;

DRI2ReuseBufferNotifyProcPtr ReuseBufferNotify;

Reference Header

http://source.tizen.org/git/?p=pkgs/xorg/server/xorg- server.git;a=blob;f=hw/xfree86/dri2/dri2.h

XV

XF86VideoAdaptor o XFree86 offers the X video extension, which allows clients to treat video as any

other primitive and ``Put'' video into drawables. By default, the extension reports no video adaptors as being available because the DDX layer has not been initialized. The driver can initialize the DDX layer by filling out one or more XF86VideoAdaptorRecs, as described later in this document and passing a list of XF86VideoAdaptorPtr pointers to the following function:

Bool xf86XVScreenInit (ScreenPtr pScreen, XF86VideoAdaptorPtr

*adaptPtrs, int num)

o After doing this, the extension will report video adaptors as per the availability,

provided the data in their respective XF86VideoAdaptorRecs was valid. Then xf86XVScreenInit() copies data from the structure passed to it, so that the driver

http://source.tizen.org/git/?p=pkgs/xorg/server/xorg-server.git;a=blob;f=exa/exa.h

http://source.tizen.org/git/?p=pkgs/xorg/server/xorg-%20server.git;a=blob;f=hw/xfree86/dri2/dri2.h

Tizen Porting Guide


Page 63 of 143

may free it after the initialization. At the moment, the DDX supports only rendering into window drawables. Pixmap rendering will be supported after a sufficient survey of suitable hardware is completed. For more information, refer to this link: http://www.xfree86.org/current/DESIGN16.html#64

o It contains the function pointers and the variables to be implemented by the X video driver.

o The function pointers and variables of DRI2InfoPtr are:

flags

name

nEncodings, pEncodings

nFormats, pFormats

nPorts, pPortPrivates

nAttributes, pAttributes

nImages, pImages

typedef int (*PutVideoFuncPtr)( ScrnInfoPtr pScrn, short vid_x,

short vid_y, short drw_x, short drw_y, short vid_w, short vid_h,

short drw_w, short drw_h, RegionPtr clipBoxes, pointer data,

DrawablePtr pDraw )

typedef int (*PutStillFuncPtr)( ScrnInfoPtr pScrn, short vid_x,



DrawablePtr pDraw )

typedef int (*GetVideoFuncPtr)( ScrnInfoPtr pScrn, short vid_x,



DrawablePtr pDraw )

typedef int (*GetStillFuncPtr)( ScrnInfoPtr pScrn, short vid_x,



DrawablePtr pDraw )

typedef void (*StopVideoFuncPtr)(ScrnInfoPtr pScrn, pointer data,

Bool Exit)

typedef int (*SetPortAttributeFuncPtr)(ScrnInfoPtr pScrn, Atom

attribute, INT32 value, pointer data)

typedef int (*GetPortAttributeFuncPtr)(ScrnInfoPtr pScrn, Atom

attribute, INT32*value, pointer data)

typedef void (*QueryBestSizeFuncPtr)(ScrnInfoPtr pScrn, Bool

motion,short vid_w, short vid_h, short drw_w, short drw_h,

unsigned int *p_w, unsigned int *p_h, pointer data)

typedef int (*PutImageFuncPtr)( ScrnInfoPtr pScrn, short src_x,

short src_y, short drw_x, short drw_y, short src_w, short src_h,

short drw_w, short drw_h, int image, unsigned char* buf, short

width, short height, Bool Sync, RegionPtr clipBoxes, pointer data,

DrawablePtr pDraw )

typedef int (*QueryImageAttributesFuncPtr)(ScrnInfoPtr pScrn, int

image, unsigned short *width, unsigned short *height, int

*pitches, int *offsets)

http://www.xfree86.org/current/DESIGN16.html#64

Tizen Porting Guide


Page 64 of 143

Reference Header

http://source.tizen.org/git/?p=pkgs/xorg/server/xorg-server.git;a=blob;f=hw/xfree86/common/xf86xv.h

Configuration

None

References

OpenGL ES 1.X, 2.0 and EGL 1.4 API specifications are supported by Tizen. OpenGL ES/EGL APIs are managed by the Khronos group. For more information about OpenGL ES API and prototype, refer to the Khronos website (http://www.khronos.org/). Xorg Input driver http://www.x.org/wiki/Development/Documentation/XorgInputHOWTO

Khronos API Implementers Guide www.khronos.org/registry/implementers_guide.pdf X server Base open source: xorg-server Base version: 1.12.99.905 (Some patches have been added to 1.12.2) Base URL: http://cgit.freedesktop.org/xorg/xserver/snapshot/xserver-6619f5c0e1086b57888ff7146e8ed5897b50d440.tar.gz Xorg configuration http://www.x.org/releases/X11R7.7/doc/man/man5/xorg.conf.5.xhtml https://wiki.archlinux.org/index.php/Xorg http://linux.die.net/man/5/xorg.conf Evdev driver Base open source: xf86-input-evdev Base version: 2.3.2 Base URL: http://cgit.freedesktop.org/xorg/driver/xf86-input evdev/snapshot/xf86-input-evdev-2.3.2.tar.gz Evdev multi-touch driver Base open source: xf86-input-evdev

http://source.tizen.org/git/?p=pkgs/xorg/server/xorg-server.git;a=blob;f=hw/xfree86/common/xf86xv.h

http://www.khronos.org/


http://www.khronos.org/registry/implementers_guide.pdf

http://cgit.freedesktop.org/xorg/xserver/snapshot/xserver-6619f5c0e1086b57888ff7146e8ed5897b50d440.tar.gz

http://cgit.freedesktop.org/xorg/xserver/snapshot/xserver-6619f5c0e1086b57888ff7146e8ed5897b50d440.tar.gz

https://wiki.archlinux.org/index.php/Xorg

http://linux.die.net/man/5/xorg.conf

http://cgit.freedesktop.org/xorg/driver/xf86-input%20evdev/snapshot/xf86-input-evdev-2.3.2.tar.gz

http://cgit.freedesktop.org/xorg/driver/xf86-input%20evdev/snapshot/xf86-input-evdev-2.3.2.tar.gz

Tizen Porting Guide


Page 65 of 143

Base version: 2.3.1 Base URL: http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/snapshot/xf86-input-evdev-2.3.1.tar.gz

Kernel configurations for input devices CONFIGURATION PURPOSE

CONFIG_INPUT CONFIG_INPUT_MISC CONFIG_INPUT_EVDEV

For supporting input device

CONFIG_INPUT_EVDEV For evdev input system

CONFIG_INPUT_UINPUT For enabling input emulation

CONFIG_INPUT_TOUCHSCREEN For enabling touch screen

CONFIG_INPUT_KEYBOARD For enabling keyboard devices such as gpio-key, touch-key

CONFIG_KEYBOARD_GPIO For gpio-key

CONFIG_INPUT_MOUSEDEV CONFIG_INPUT_MOUSE_PSAUX

For mouse devices

http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/snapshot/xf86-input-evdev-2.3.1.tar.gz

http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/snapshot/xf86-input-evdev-2.3.1.tar.gz

Tizen Porting Guide


Page 66 of 143

Multimedia

Camcorder

Description

Multimedia FW Camcorder

The Multimedia camcorder framework controls the camera plugin of GStreamer to capture

camera data from the device. But, the kernel interfaces to control the camera device could

be different for different chipsets, so the camera plugin should be implemented specifically

for each chipset. Each config file contains its own specific hardware dependent information.

The Multimedia Camcorder framework reads and parses the information in these config files.

Camera source plugin for GStreamer

o Gets camera data (preview or captured image) from the camera device

o Inherit “GstPushSrc”

Config files

There are 3 config files for the Multimedia Camcorder framework, shown below and provided by “mmfw- sysconf-xxx”

o mmfw_camcorder.ini - The camcorder settings file. It includes mainly the selection of plugins and settings, which are used by the camcorder framework

Tizen Porting Guide


Page 67 of 143

and it defines the setting values or names of plugins, such as Video Input, Audio Input, Video Output, Video Encoder, and Audio Encoder

o mmfw_camcorder_dev_video_pri.ini - This file includes the settings of the high resolution rear camera. Each item shows the value, which can be supported by the camera module.

o mmfw_camcorder_dev_video_sec.ini - This file includes the settings of the low resolution front camera. Each item shows the value, which can be supported by the camera module.


GStreamer Camera plugin

o Because the kernel interfaces to control camera device can be different for different chipsets, the camera plugin should be implemented specifically for each chipset. To develop a new plugin, refer to the gsteamer plugin development guide: (http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/index.html)

o Any third party developer who wants to implement camera source plugin needs to derive it from GstPushSrc.

o When the camera source plugin is moving from NULL to READY state (GST_STATE_CHANGE_NULL_TO_READY), it should open the camera device using the open system call.

o In the plugin’s start virtual function (GstBaseSrc’s start function), the required formats and parameters should be set using IOCTL system calls and also the required number of buffers should be obtained according to the IO method.

o In the plugin’s create virtual function (GstBaseSrc’s create function), the plugin should get the raw buffers from the camera driver and needs to be pushed to the downstream element.

o Extra properties should be implemented for capture and setting.

Name Type Description

camera-id int Index number of camera to activate(front,rear etc)

capture-fourcc unsigned int Fourcc value for capture format

capture-jpg-quality unsigned int Quality of captured image(such as JPEG compressibility)

capture-width unsigned int Width of captured image

capture-height unsigned int Height of capured image

capture-count unsigned int Number to capture image

provide-exif boolean Whether EXIF data is included in captured image

vflip boolean Flip camera input vertically

hflip boolean Flip camera input horizontally

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/index.html


Tizen Porting Guide


Page 68 of 143

"gst-interfaces" should be applied for capture and setting. Refer "pkgs/gst-plugins-base0.10/gst-libs/gst/interfaces/cameracontrol* and colorbalance*" files.

return value of All gst_camera_control_* APIs:

-> TRUE : SUCCESS

-> FALSE : FAILURE

Interface function name Description gst_camera_control_set_capture_command (GstCameraControl* control, GstCameraControlCaptureCommand cmd)

Set capture command (start, stop, stop multishot). This is async API. Camera source plugin has a command queue in it. Control - is casted instance of camera source plugin cmd- enumerations for camera capture command. typedef enum {

GST_CAMERA_CONTROL_CAPTURE_COMMAND_NONE,

GST_CAMERA_CONTROL_CAPTURE_COMMAND_START,

GST_CAMERA_CONTROL_CAPTURE_COMMAND_STOP,

GST_CAMERA_CONTROL_CAPTURE_COMMAND_STOP_M

ULTISHOT,

} GstCameraControlCaptureCommand;

gst_camera_control_set_exposure( GstCameraControl *control, gint type, gint value1, gint value2)

Set exposure mode. 1] control - is casted instance of camera source plugin 2] type - enumerations for camera control exposure types. typedef enum

{ GST_CAMERA_CONTROL_F_NUMBER, GST_CAMERA_CONTROL_SHUTTER_SPEED, GST_CAMERA_CONTROL_ISO, GST_CAMERA_CONTROL_PROGRAM_MODE, GST_CAMERA_CONTROL_EXPOSURE_MODE, GST_CAMERA_CONTROL_EXPOSURE_VALUE, } GstCameraControlExposureType;

3] value1, value2 - ISO, Program mode and exposure mode are use only "value1" - F number, shutter speed, exposure value are use both (value1 and value2. value1 is numerator and value2 is denominator of them)

gst_camera_control_get_exposure Get exposure mode.

gst_camera_control_set_strobe( GstCameraControl *control, gint type, gint value)

Set strobe(flash) mode. 1] control - is casted instance of camera source plugin 2] type - if camera module supports a strobe (flash), "STROBE_MODE" should be supported. Others (control, capabilities, status, ev) are optional.

Tizen Porting Guide


Page 69 of 143

/** * Enumerations for Camera control Strobe types. */ typedef enum { GST_CAMERA_CONTROL_STROBE_CONTROL, GST_CAMERA_CONTROL_STROBE_CAPABILITIES, GST_CAMERA_CONTROL_STROBE_MODE, GST_CAMERA_CONTROL_STROBE_STATUS, GST_CAMERA_CONTROL_STROBE_EV, } GstCameraControlStrobeType;

3] value - is dependent on camera device. 0 is enough for API test.

gst_camera_control_get_strobe Get strobe(flash) mode

gst_camera_control_set_detect( GstCameraControl *control, gint type, gint value)

Set detection mode. 1] control - is casted instance of camera source plugin 2] type - enumerations for camera control Face detection types. typedef enum { GST_CAMERA_CONTROL_FACE_DETECT_MODE, GST_CAMERA_CONTROL_FACE_DETECT_NUMBER, GST_CAMERA_CONTROL_FACE_FOCUS_SELECT, GST_CAMERA_CONTROL_FACE_SELECT_NUMBER, GST_CAMERA_CONTROL_FACE_DETECT_STATUS, } GstCameraControlFaceDetectType;

3] value - is dependent on camera device. 0 is enough for API test

gst_camera_control_get_detect Get detection mode

gst_camera_control_set_zoom(GstCameraControl *control, GstCameraControlZoomType type, gint value)

Set zoom mode and level. 1] Control - is casted instance of camera source plugin such as GstCameraControl *control = NULL; control = GST_CAMERA_CONTROL(camerasrc_plugin); 2] type - enumerations for camera control zoom types. typedef enum { GST_CAMERA_CONTROL_DIGITAL_ZOOM, GST_CAMERA_CONTROL_OPTICAL_ZOOM, } GstCameraControlZoomType;

3] value (zoom level) - is dependent on camera device. 0 is enough for API test.

gst_camera_control_get_zoom Get zoom mode and level

gst_camera_control_set_focus( GstCameraControl *control, gint mode, gint range)

Set focus mode and range. 1] control - is casted instance of camera source plugin 2] mode - is dependent on camera device. 0 is enough for API test. 3] range

Tizen Porting Guide


Page 70 of 143

- is dependent on camera device. 0 is enough for API test.

gst_camera_control_get_focus Get focus mode and range

gst_camera_control_start_auto_focus( GstCameraControl *control)

Start auto focusing. 1] control - is casted instance of camera source plugin.

gst_camera_control_stop_auto_focus( GstCameraControl *control)

Stop auto focusing 1] control - is casted instance of camera source plugin

gst_camera_control_set_focus_level( GstCameraControl *control, gint manual_level)

Set focusing level for manual focus 1] control - is casted instance of camera source plugin 2] manual_level - is dependent on camera device. 0 is enough for API test.

gst_camera_control_get_focus_level Get focusing level for manual focus

gst_camera_control_set_auto_focus_area( GstCameraControl *control, GstCameraControlRectType rect)

Set auto focusing area. 1] control - is casted instance of camera source plugin 2] rect - struct GstCameraControlRectType brief For touch auto focusing area typedef struct {

gint x; gint y; gint width; gint height; }GstCameraControlRectType;

gst_camera_control_get_auto_focus_area Get auto focusing area

gst_camera_control_set_wdr( GstCameraControl *control, gint value)

Set wide dynamic range (wdr) mode. 1] control - is casted instance of camera source plugin 2] value - is dependent on camera device. 0 is enough for API test

gst_camera_control_get_wdr Get wide dynamic range mode

gst_color_balance_set_value Set color balance value (brightness, contrast, saturation, sharpness, white balance, color tone)

gst_color_balance_get_value Get color balance value (brightness, contrast, saturation, sharpness, white balance, color tone)

Extra signal should be implemented to get captured image Name Proto type Description

still-capture

Void user_function(GstElement *object, GstBuffer *arg0, GstBuffer *arg1,

Signal callback is called with captured image (arg0: main image,

http://arg0main/

Tizen Porting Guide


Page 71 of 143

GstBuffer *arg2, Gpointer user_data);

arg1:thumbnail image, arg2:screennail image) if user sets capture command

To understand the above description, an example is provided below to explain how to

implement the zoom feature in the camera plugin, which will be used by the camcorder

framework.

1. The camcorder framework will invoke

gst_camera_control_set_zoom( GstCameraControl *control, gint type, gint

value ).

2. The above function will in turn invoke the function.

gst_camerasrc_control_set_zoom( GstCameraSrc* camerasrc, gint type, gint

value ), which should be implemented in the camera plugin.

3. The above will call the required IOCTL.

CODE SNIP

/*Invoked by Camcorder*/

ret = gst_camera_control_set_zoom(control, zoom_typ

e, zoom_level);

/*Inside gst-plugin base*/

gst_camera_control_set_zoom( GstCameraControl *cont

rol, gint type, gint value )

{

GstCameraControlClass *klass = GST_CAMER

A_CONTROL_GET_CLASS( control );

if( klass->set_zoom )

{

return klass->set_zoom( control, ty

pe, value );

}

return FALSE;

}

http://arg1thumbnail/

http://arg2screennail/

Tizen Porting Guide


Page 72 of 143

/*Camera Plugin implementation*/

gst_camera_src_control_interface_init( GstCameraCont

rolClass *klass )

{

klass->set_zoom = gst_camera_src_control_set_zoom;

}

gst_camera_src _control_set_zoom( GstCameraControl*

control, gint type, gint value )

{

Type* this = (Type*)control; \

return gst_camerasrc_control_set_zoom( this, ty

pe, value ); \

}

gst_camerasrc_control_set_zoom( GstCameraSrc* camera

src, gint type, gint value )

{

gst_camerasrc_debug( "" );

int error = CAMERASRC_ERROR;

g_return_val_if_fail( camerasrc, FALSE );

switch( type )

{

case GST_CAMERA_CONTROL_DIGITAL_ZOOM:

error = camerasrc_set_control

(camerasrc->v4l2_handle, CAMERASRC_CTRL_DIGITAL

_ZOOM, value );

break;

case GST_CAMERA_CONTROL_OPTICAL_ZOOM:

error = camerasrc_set_control

(camerasrc->v4l2_handle, CAMERASRC_CTRL_OPTICAL

_ZOOM, value );

break;

default:

gst_camerasrc_debug( "Not supported

type." );

return FALSE;

}

return TRUE;

}

Tizen Porting Guide


Page 73 of 143

Configuration

Config files Read the keyword and its value from the file. Recognize the categories by using the keyword list of MSL camcorder, and save the member structure of MSL camcorder. Later, these values are used as attribute value or some other operation. The permission of this file is read-only to make sure the config files are read once before creating camcorder. Use a semicolon (“;”) to add comments in the config file.

Description of "mmfw_camcorder.ini"

//…

Finally the ioctl call is made

//…

int err = CAMERASRC_ERR_UNKNOWN;\

struct v4l2_control control;\

control.id = cid;\

control.value = in_value;\

camsrc_info("[VIDIOC_S_CTRL] >> [%x] reques

t with value %d", cid, in_value); \

err = _camerasrc_ioctl(handle, VIDIOC_S_CTR

L, &control);\

if(err != CAMERASRC_SUCCESS) {\

return err;\

}

int _camerasrc_ioctl(camerasrc_handle_t *handle, int r

equest, void *arg)

{

int fd = handle->dev_fd;

do {

err = ioctl (fd, request, arg);

} while (-1 == err && EINTR == errno);

……

return CAMERASRC_SUCCESS;

}

Tizen Porting Guide


Page 74 of 143

Category Entry Description

[General] General setting or information

SyncStateChange API running type. It should be 1 (TRUE).

ModelName Model name of target.

[VideoInput] Setting list related with video input

UseConfCtrl whether to use config file or not. It should be 1 (TRUE).

ConfCtrlFile0 or 1

The name of setting file to control camera device.

VideosrcElement

Source plugin which obtains camera input buffer from device.

[AudioInput] Setting list related with audio input

AudiosrcElement

Audio source plugin, which obtains audio for camcorder or voice record.

AudiomodemsrcElement Audio source plugin which obtains audio for call recording.

[VideoOutput] Setting list related with video output

DisplayDevice Supported output device list and default value.

Videosink Supported output surface list and default value.

VideosinkElementX Plugin name for X output surface and property setting list.

VideosinkElementEvas Plugin name for EVAS output surface and property setting list.

VideosinkElementGL Plugin name for GL output surface and property setting list.

VideosinkElementNULL Plugin name for NULL surface and property setting list.

[VideoEncoder] Define video encoder list for video recording

[AudioEncoder] Define audio encoder list for AV recording or voice recording

[Capture] Setting list related with image capture

UseEncodebin whether use “encodebin” to capture image or not. Recommend that keep this value as 0 (FALSE).

[Record]

Setting value list for each recording mode. Recommend that keep values of example config file.

[Mux] Mux plugin list related with the file container.

Description of "mmfw_camcorder_dev_video_pri.ini" for primary camera (generally rear main camera) and "mmfw_camcorder_dev_video_sec.ini" for secondary camera (generally front sub camera).

Tizen Porting Guide


Page 75 of 143

Category Entry Description [Camera] Describe the information

InputIndex Camera number to select (primary or secondary).

DeviceName Name of camera module.

PreviewResolution All supported preview resolution list that user can set and default values of this camera device.

CaptureResolution

A list of all supported capture resolutions a user can set, as well as the default values for this camera device.

FPS

A list of all supported FPS (Frame Per Second) settings a user can use, as well as the default values for this camera device.

PictureFormat

A list of all supported preview formats a user can set, as well as the default values for this camera device.

RecommendDisplayRotation

Default display rotation value for displaying camera input.

RecommendPreviewFormatCapture Recommended preview format for capturing images.

RecommendPreviewFormatRecord Recommended preview format for recording.

[Strobe] Settings about camera strobe(Flash)

StrobeMode Supported strobe mode and default values. This is converted to a real value and used in the kernel internally.

[Effect]

Settings about the effects

Brightness Supported range of brightness and default values.

Contrast Supported range of contrast and default values.

Saturation Supported range of saturation and default values.

Sharpness Supported range of sharpness and default values.

Whitebalance Supported white balance list and default values. This is converted to real value used in kernel internally.

ColorTone Supported color tone list and default values. This is converted to a real value and used in the kernel internally.

WDR Supported Wide Dynamic Range mode list and

Tizen Porting Guide


Page 76 of 143

default values. This is converted to a real value and used in the kernel internally.

[Photograph] Settings about camera shot

DigitalZoom Supported range of digital zoom level and default values.

OpticalZoom Supported range of optical zoom level and default values.

FocusMode Supported focus mode list and default value. This is converted to a real value and used in the kernel internally.

AFType

Supported AUTO focus mode list and default values. This is converted to a real value and used in the kernel internally.

AEType

Supported AUTO Exposure mode list and default value. This is converted to a real value and used in the kernel internally.

ExposureValue

Supported range of exposure value and default values.

ISO

Supported ISO list and default value. This is converted to a real value and used in the kernel internally.

ProgramMode

Supported program mode (scene mode) list and default value. This is converted to a real value and used in the kernel internally.

AntiHandshake Supported anti-hand shake mode list and default value. This is converted to a real value and used in the kernel internally.

[Capture]

Settings about image capture

OutputMode

Supported capture format list and default values.

JpegQuality

Supported range of JPEG quality and default values.

MultishotNumber

Supported range of multi shot count and default values.

SensorEncodedCapture

Whether or not the camera sensor support JPEG capture.

[Detect]

Settings about detect function

DetectMode Supported detect mode list and default values.

Tizen Porting Guide


Page 77 of 143

References

Driver Configuration

Set the kernel .config values for the camera like this:

CONFIG_VIDEO_DEV = y CONFIG_VIDEO_SAMSUNG = y CONFIG_VIDEO_SAMSUNG_V4L2 = y CONFIG_VIDEO_FIMC = y CONFIG_VIDEO_FIMC_MMAP_OUTPUT_CACHE = y CONFIG_VIDEO_FIMC_MIPI = y CONFIG_VIDEO_FIMG2D = y CONFIG_VIDEO_JPEG = y CONFIG_VIDEO_MFC5X = y

Kernel Node

For Camera : /dev/video1 Other CAMIF interfaces : /dev/video(0-3)

Camera source plugin makes direct use of V4L2 ioctls to interact with the camera driver. The list of ioctls is:

Driver methods Description

VIDIOC_S_CTRL Set the value of control.

VIDIOC_G_CTRL Get the value of control.

VIDIOC_S_PARM Set the value parameter.

VIDIOC_G_PARM Get the value of parameter.

VIDIOC_STREAMON START capture or output process during streaming.

VIDIOC_STREAMOFF STOP capture or output process during streaming.

VIDIOC_QBUF Enqueue an empty (capturing) or filled (output) buffer in the driver's incoming queue.

VIDIOC_DQBUF Dequeue a filled (capturing) or displayed (output) buffer from the driver's outgoing queue.

VIDIOC_REQBUFS Initiate Memory Mapping or User Pointer I/O.

VIDIOC_QUERYBUF Query the status of a buffer. To map the buffers call VIDIOC_QUERYBUF for each buffer to get the details about the buffer, and call mmap() to map it.

VIDIOC_S_JPEGCOMP Set JPEG encode parameters.

VIDIOC_G_JPEGCOMP Get JPEG encode parameters.

VIDIOC_ENUM_FMT Enumerate image formats.

VIDIOC_ENUM_FRAMESIZES Enumerate frame sizes.

VIDIOC_ENUM_FRAMEINTERVALS Enumerate frame intervals.

VIDIOC_S_INPUT Query or select the current video input.

VIDIOC_QUERYMENU Enumerate menu control items.

VIDIOC_QUERYCTRL Enumerate control items.

VIDIOC_QUERYCAP Query device capabilities.

Tizen Porting Guide


Page 78 of 143

For all GStreamer documentation, refer to:

o http://gstreamer.freedesktop.org/documentation/

To develop GStreamer plugins, refer to:

o http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/index.html

To develop V4L2, refer to:

o http://v4l2spec.bytesex.org/spec-single/v4l2.html

http://gstreamer.freedesktop.org/documentation/



Tizen Porting Guide


Page 79 of 143

Radio

Description

The radio interface part of the multimedia framework supports APIs to implement the following FM radio features, using Linux V4L2 interfaces.

o Tune a frequency

o Get/Set a frequency

o Scan all available frequencies

o Seek up/down

o Get frequency signal


The OAL interface for FM radio is the Linux kernel V4L2 interfaces. The radio module directly uses the V4L2 ioctls, to perform various radio hardware configurations.

The reference section explains those V4L2 interfaces used by the FM radio interface.

Configuration

None

References

Tizen Porting Guide


Page 80 of 143

Radio V4L2 interface for reference.

Driver methods Description

VIDIOC_QUERYCAP

Query device capabilities

VIDIOC_S_TUNER

Set tuner attributes

VIDIOC_S_CTRL

Set the value of a control

VIDIOC_G_CTRL

Get the value of a control

VIDIOC_S_FREQUENCY

Set tuner or modulator radio frequency

VIDIOC_G_FREQUENCY

Get tuner or modulator radio frequency

VIDIOC_S_HW_FREQ_SEEK Seek radio frequency

VIDIOC_QUERYCTRL

Enumerate controls

VIDIOC_G_TUNER

Get tuner attributes

Radio frequency value setting

The V4L2 interfaces VIDIOC_S_FREQENCY and VIDIOC_G_FREQUENCY configures and retrieves

the frequency value in (MHz) /(16 * 1000). It requires V4L2_TUNER_CAP_LOW capability

interface issued to the driver.

If libmm-radio gives VIDIOC_S_FREQUNCY with 140000, then it stands 87.5Mhz

(=1400000/(16*1000))

Radio signal strength:

The V4L2 interface VIDIOC_G_TUNER retrieves the signal strength which, is the unit of dbuV.

V4L2 specification:

http://v4l2spec.bytesex.org/spec-single/v4l2.html

Tizen Porting Guide


Page 81 of 143

Audio

Description

Avsystem

o Avsystem is a native Tizen component providing an API for handling the stream and the sound path in the upper layer. Avsystem has these significant features:

Provide interfaces for stream, such as open, close, read, write, etc.

Provide interfaces for sound path selections and switching.

Acquire the handle of session and reads (writes) stream data from (to) pulseaudio.

Control sound path and make alsa-scenario string from a given input, output, and stream type.

PulseAudio

o PulseAudio is a sound server accepting sound input from one or more sources and redirecting it to one or more sinks. PulseAudio has these significant features:

Tizen Porting Guide


Page 82 of 143

Software mixing of multiple audio streams

Support for multiple audio sources and sinks

An extensible plugin architecture with support for loadable modules

Low-latency operation

Support bluetooth audio devices

asound.conf

o A configuration file for ALSA drivers

o Most applications will work without them. They are used to allow extra functionality, such as routing and sample-rate conversion, through the alsa-lib layer.

o If you change this file, you need to run a command like this:

sudo /etc/init.d/alsa-utils restart

o Tizen uses this for defining pcm stream in MMFW


Avsystem

o Avsystem is a native Tizen component.

PulseAudio

o PulseAudio in the Tizen does not support udev.

o PulseAudio should be started as system mode.

o To support a variety of devices, some configuration files have been separated from PulseAudio to mmfw-sysconf. [Refer to the Configuration section].

o Do not change the default sink in /etc/pulse/system.pa. Default sink is used by some modules. If it was changed, there will be problems in sound playback.

load-module module-remap-sink sink_name=mono_alsa master=alsa_output.0.analog-stereo channels=1

asound.conf

o The name AIF2, AIF3 should not be changed.

o /etc/asound.conf has a dependency on the hardware. For more detailed information, see how to configure.

Tizen Porting Guide


Page 83 of 143

Configuration

PulseAudio configuration usage

o To support a variety of devices, some configuration files have been separated from PulseAudio to mmfw-sysconf. PulseAudio has various configuration files:

/etc/pulse/client.conf

Configuration file for PulseAudio clients. The PulseAudio client library reads configuration directives from a file ~/.pulse/client.conf on startup and when that file doesn't exist, from /etc/pulse/client.conf.

The configuration file is a simple collection of variable declarations. If the configuration file parser encounters either ; or #, it ignores the rest of the line until its end.

For the settings that take a boolean argument the values true, yes, on and 1 are equivalent, resp. false, on, off and 0.

See the man page of pulse-client.conf(5) for more information.

/etc/pulse/daemon.conf

Configuration file for the PulseAudio daemon. The PulseAudio sound server reads configuration directives from a file ~/.pulse/daemon.conf on startup, and when that file doesn't exist from /etc/pulse/daemon.conf. Note that the server also reads a configuration script on startup default.pa, which also contains runtime configuration directives.

The configuration file is a simple collection of variable declarations. If the configuration file parser encounters either ; or # it ignores the rest of the line until its end.

For the settings that take a boolean argument the values true, yes, on and 1 are equivalent, resp. false, on, off and 0.

See the man page pulse-daemon.conf(5) for more information.

/etc/pulse/default.pa

PulseAudio Sound Server Startup Script. This startup script is used only if PulseAudio is started per user (that is, not in the system mode). User mode is not recommended in the SLP. See the system.pa.

The PulseAudio sound server interprets the file ~/.pulse/default.pa on startup, and when that file doesn't exist, /etc/pulse/default.pa. It should contain directives in the PulseAudio CLI languages, as documented on http://pulseaudio.org/wiki/CLI.

/etc/pulse/system.pa

Pulseaudio Sound Server Startup Script. This startup script is used only if PulseAudio is started in system mode.

http://pulseaudio.org/wiki/CLI

Tizen Porting Guide


Page 84 of 143

It should contain directives in the PulseAudio CLI languages, as documented on http://pulseaudio.org/wiki/CLI.

/usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf

Default profile definitions for the ALSA backend of PulseAudio. This is used as fallback for all cards that have no special mapping assigned (and should be good enough for the vast majority of cards). ALSA devices are exposed in PulseAudio. An ALSA device string is used to open a device, channel to map and mixer path to use. This is encoded in a 'mapping'. Such multiple mappings can be bound together in a 'profile', which is then directly exposed in the UI as a card profile. Each mapping assigned to a profile will result in one sink/source, to be created if the profile is selected for the card.

In addition, there are a few more configuration files. Currently, they do not have a major impact, but can be modified, if necessary.

usr/share/pulseaudio/alsa-mixer/profile-sets/

o native-instruments-audio4dj.conf o native-instruments-audio8dj.conf

usr/share/pulseaudio/alsa-mixer-paths/

o analog-input-aux.conf o analog-input-fm.conf o analog-input-linein.conf o analog-input-mic-line.conf o analog-input-mic.conf o analog-input-mic.conf.common o analog-input-tvtuner.conf o analog-input-video.conf o analog-input.conf o analog-input.conf.common o analog-output-headphones-2.conf o analog-output-headphones.conf o analog-output-lfe-on-mono.conf o analog-output-mono.conf o analog-output-speaker.conf o analog-output.conf o analog-output.conf.common

How to apply and verify modifications

o To apply modifications, restart pulseaudio:

$ kill -9 <PulseAudio PID>

$ /usr/bin/pulseaudio --log-level=4 --system –D

http://pulseaudio.org/wiki/CLI

Tizen Porting Guide


Page 85 of 143

o To check that modules were loaded normally, run this:

$ pactl list

dump all currently loaded modules, available sinks, sources, streams, etc.

o The actual recording and playback

Check the behavior of the Kernel and ALSA.

o $ arecord –f <format> -c <channels> -r <rate> <filename> o $ aplay –f <format> -c <channels> -r <rate> <filename>

Check the behavior of the PulseAudio.

o $ parecord –f <format> -c <channels> -r <rate> <filename> o $ paplay –f <format> -c <channels> -r <rate> --raw <filename>

o PulseAudio troubleshooting

Typically, the default playback and capture device is used hw:0,0. This is set when load-module is detected in system.pa. However, some hardware may need to set a different default device. There are a few ways to solve this problem.

o Suppose your default device is card 0, device 3. A simple way to modify the /etc/pulse/system.pa file is to disable automatic detection and manually load sink and source modules:

### Alternatively use the static hardware detection module (for systems that ### lack HAL support) #load-module module-detect load-module module-alsa-sink device=hw:0,3 name=0.analog-stereo load-module module-alsa-source device=hw:0,3 name=0.analog-stereo… .endif

o Another way is to modify /usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf. The device-string is an ALSA device string.

[Mapping analog-stereo] device-strings = hw:0,3 channel-map = left,right paths-output = analog-output analog-output-speaker analog-output-headphones analog-output-headphones-2 analog-output-mono analog-out paths-input = analog-input analog-input-mic analog-input-linein analog-input-aux analog-input-video analog-input-tvtuner analog-inpu priority = 10

asound.conf

o In this file, some configurations have a dependency on the hardware. Format, channels, and such values can be changed depending on the hardware.

pcm. !default {

Tizen Porting Guide


Page 86 of 143

type hw card 0 } ctl. !default { type hw card 0 } pcm. AIF2{ type hw card 0 device 1 format S16_LE channels 2 rate 8000 } pcm. AIF3{ type hw card 0 device 3 } #LPaudio of C210 not yet implemented pcm. lpaudio { type null }

o The name AIF2, AIF3 should not be changed.

o AIF2 is used for a modem interface

o AIF3 is used for a bluetooth interface

o The highlighted parameters for AIF2, AIF3 can be changed by hardware configuration and this should be matched with hardware configuration.

References

Driver Configuration for Samsung chipset:

Listed below is an example of the kernel .config values to be set for audio in the Samsung chipset.

CONFIG_SOUND=y CONFIG_SND=y CONFIG_SND_TIMER=y CONFIG_SND_HWDEP=y CONFIG_SND_JACK=y

Tizen Porting Guide


Page 87 of 143

CONFIG_SND_SOC = y CONFIG_SND_SOC_SAMSUNG = y CONFIG_SND_SAMSUNG_I2S = y CONFIG_SND_SOC_SLP_TRATS_MC1N2 = y CONFIG_SND_SOC_I2C_AND_SPI = y CONFIG_SND_SOC_MC1N2=y

PulseAudio : Version : 0.9.21 Website: http://www.freedesktop.org/wiki/Software/PulseAudio ALSA Website: http://www.alsa-project.org

http://www.freedesktop.org/wiki/Software/PulseAudio

http://www.alsa-project.org/

Tizen Porting Guide


Page 88 of 143

Player

Description

The multimedia player framework controls the player plugins (demuxer, codecs and renderer plugins) of GStreamer to play media content. But, the kernel interfaces to control codecs could be different for different chipsets, so corresponding codecs plugins should be implemented specifically for each chipset.


There is no specific OAL for multimedia player framework. Player plugins, mentioned consist of the following components as part OAL interface: gst-openmax codec plugins, video/audio renderer plugins. Refer to OAL sections of Codecs for gst-openmax plugin details, Avsystem for audio (Avsystem), X11 (UI-framework) for display (X11

Player Plugins

Gst-openmax codec plugins

X11 video renderer/AVSystem

audio renderer

Tizen Porting Guide


Page 89 of 143

Video Driver).

Configuration

Config file

o The multimedia player framework uses “mmfy_player.ini” config file to set various parameters for selecting different codecs/display plugins, etc.

o “mmfy_player.ini” config file is provided by “mmfw-sysconf-xxx” package.

o In the final stage of development, the permission for this file needs to be changed to read-only.

How to Configure

o File name: mmfw_player.ini

o One player.ini file is needed in each board (or model).

o Codec plugins for this board are located in /usr/lib/gstreamer-0.10. Changing the codec plugin does not mean modifying this ini file because the player supports the auto plugin feature.

o As needed, these following setting values can be used for developing

element exclude keyword

A general section keyword, it means that these codec plugins do not link in the player pipeline. The default value is ffdec_

If you want to use the ffmpeg s/w codec plugin for testing, you can remove this ffdec_ keyword.

If there are many codec plugins which have the same rank and same feature, it causes problems to select the codec you want. So you need to add the plugin name to exclude unwanted plugins.

video converter element

The default is the ffmpegcolorspace plugin. If you do not want this plugin, you can remove it, and change it to another converter plugin.

audio filter

By default, the s/w audio effect plugins based on arm architecture are used. So, if the platform is set to another architecture process, this value needs to be set to false. And, How to make and use such plugin is under the review.

Tizen Porting Guide


Page 90 of 143

References

Display Driver Configuration for Samsung chipset:

Listed below is an example of the kernel .config values to be set for display in the Samsung chipset:

CONFIG_DRM = y CONFIG_FB = y CONFIG_FB_S3C = y CONFIG_FB_S3C_LCD_INIT = y CONFIG_FIMD_EXT_SUPPORT = y CONFIG_FIMD_LITE_SUPPORT = y

Kernel Node

Frame buffers- /dev/fb(0-4)

gst-openmax version : 0.10.1.0

o http://gstreamer.freedesktop.org/src/gst-openmax/

o http://www.freedesktop.org/wiki/GstOpenMAX

For all GStreamer documentation, refer to:

o http://gstreamer.freedesktop.org/documentation/

For developing GStreamer plugins, refer to:

o http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/index.html

For more information about OpenMAX IL components, refer to:

o http://www.khronos.org/openmax/il/

http://gstreamer.freedesktop.org/src/gst-openmax/

http://www.freedesktop.org/wiki/GstOpenMAX




Tizen Porting Guide


Page 91 of 143

Codec

Figure 1. Shows two types of codec plugins, such as gstreamer type and OpenMAX type codec plugin.

Description

Gstreamer codec plugin

o Gstreamer codec plugin can be linked and used easily to gstreamer pipeline, which is used in multimedia FW.

OpenMAX codec plugin

o Some of the codec vendors provide OpenMAX IL components and not Gstreamer plugins, Tizen provides gst-openmax plugins to use OpenMAX IL components.

o Gstreamer pipeline, which is used in Multimedia FW can control and transfer data to OpenMAX IL component using gst-openmax plugin.

Tizen Porting Guide


Page 92 of 143

Description of each component of codec

Gstreamer codec plugin

Figure 2. Shows the example of decoder codec plugin, which is provided as a gstreamer element. If the codec plugin is provided, the player can link this plugin to its pipeline immediately.

For detailed information about gstreamer usage, go to reference section.

In addition, to link a gstreamer pipeline, the capability of codec plugin can be negotiated with the linked element in the pipeline.

To know detailed information, such as capability of an element, we can use “#gst-

inspect (element name)” command.

OpenMAX component codec plugin

Tizen Porting Guide


Page 93 of 143

Figure 3 shows the example of decoder codec plugin, which is provided as an OpenMAX component type.

To use OpenMAX component in gstreamer, we provided the gst-openmax (open source) package. By using this package, gstreamer can recognize and use an OpenMAX component as a gstreamer element.

Gst-openmax is a gstreamer plugin that allows communication with OpenMAX IL components. The usage of this gst-openmax plugin is the same as other gstreamer plugins, but if you want more detailed information about this plugin, you can refer this web site:


If you want to know about OpenMAX IL, please refer to this web site:

http://www.khronos.org/openmax/

As shown Figure 1, gst-openmax plugin refers to a configuration file: gst-openmax.conf. This file is included in mmfw-sysconf package, and installed to /usr/etc/gst-openmax.conf in target device.


OpenMAX Component Codec Plugin


http://www.khronos.org/openmax/

Tizen Porting Guide


Page 94 of 143

o An industry standard that provides an abstraction layer for computer graphics, video, and sound routines.

o The interface abstracts the hardware and software architecture in the system.

o The OpenMAX IL API allows the user to load, control, connect, and unload the individual components. This flexible core architecture allows the Integration Layer to easily implement almost any media use case and mesh with existing graph-based media frameworks.

o The key focus of the OpenMAX IL API is portability of media components

o OpenMAX IL interfaces between media framework, such as GStreamer and a set of multimedia components (such as an audio or video codecs).

o gst-openmax is a GStreamer plug-in package that allows communication with OpenMAX IL components.

o Gst-openmax structuring is classified into different object classes based on the functionality. Such as filter like elements use GstOmxBaseFilter object, source elements uses GstOmxBaseSrc & so on. The following is the object structuring of a video decoder plugin in gst-openmax:

o If a 3rd party developer needs to develop a decoder plugin on top of OpenMAX IL component & add it to gst-openmax package, one has to follow these steps:

Derive video/audio decoder’s object from GstOmxVideoDec/GstOmxAudioDec object

Derive video/audio decoder’s object class from GstOmxVideoDecClass/GstOmxAudioDecClass

Implement type_base_init () function of decoder’s object:

http://en.wikipedia.org/wiki/GStreamer

http://en.wikipedia.org/wiki/Codec

Tizen Porting Guide


Page 95 of 143

o Implement type_class_init () function of decoder’s object like below:

o Implement type_instance_init() function of decoder’s object like below:

o Decoder plugin will get compressed frame in sinkpad’s virtual chain function (that is pad_chain (), which is implemented in GstOmxBaseFilter) and then OpenMax Gstreamer decoder plugin will pass the compressed frame to the respective decoder’s OpenMax-IL component. Refer gst-openmax package for pad_chain() function implementation.

GstElementClass *element_class;

element_class = GST_ELEMENT_CLASS (g_class);

gst_element_class_set_details_simple (element_class,

"OpenMAX IL MPEG-4 video decoder",

"Codec/Decoder/Video",

"Decodes video in MPEG-4 format with OpenMAX IL", "Felipe

Contreras");

{

GstPadTemplate *template;

template = gst_pad_template_new ("sink", GST_PAD_SINK,

GST_PAD_ALWAYS, generate_sink_template ());

gst_element_class_add_pad_template (element_class, template);

}

static void

type_class_init (gpointer g_class, gpointer class_data)

{

GObjectClass *gobject_class;

GstOmxBaseFilterClass *basefilter_class;

gobject_class = G_OBJECT_CLASS (g_class);

basefilter_class = GST_OMX_BASE_FILTER_CLASS (g_class);

gobject_class->finalize = finalize;

}

static void

type_instance_init (GTypeInstance * instance, gpointer g_class)

{

GstOmxBaseVideoDec *omx_base;

omx_base = GST_OMX_BASE_VIDEODEC (instance);

omx_base->compression_format = OMX_VIDEO_CodingMPEG4;

}

Tizen Porting Guide


Page 96 of 143

o GstOmxBaseFilter also has ouput_loop () function implementation, which will be running as a task on source pad of decoder plugin and, once a decoded buffer is available, the same will be pushed to next downstream element (e.g. renderer element). This API will be blocked till OpenMax IL decoder component gives decoded raw buffer. Please refer gst-openmax package for ouput_loop() function implementation.

New decoder plugin xxx_get_type() function need to be registered with get_type array of function pointers in gstomx.c file.

Also new plugin details need to be registered in gst_openmax.conf file, like other plugins.

Configuration

OpenMAX component codec plugin

o OpenMAX component codec plugin cannot be linked to gstreamer directly. Hence, we use gst-openmax plugin to link OpenMAX component and gstreamer.

o Gst-openmax is a gstreamer plugin that allows communication with OpenMAX IL components.

o Gst-openmax plugin refers a configuration file, such as gst-openmax.conf. This file is included in mmfw-sysconf package, and installed /usr/etc/gst-openmax.conf in target device.

This file needs to change appropriately, according to vendors which provide OpenMAX component.

o gst-openmax.conf

The following values of each item in the lists separated by commas.

Each gstreamer element is separated by a semicolon.

Tizen Porting Guide


Page 97 of 143

Example:

Each value needs to be changed appropriately, according to vendors which provide OpenMAX component.

When you finished these settings, the other is same as gstreamer type codec plugin. Hence, you can test this codec same way.

Use of codec plugin in Player

o Because the player uses auto plugging, it doesn’t need an additional setting.

If the decoder plugin has acceptable capability, this plugin can be linked with a player pipeline in order of rank.

If the codec name is included in the excluded keyword in /usr/etc/mmfw_player.ini (mmfw-sysconf package), it will be excluded in player pipeline.

Use of codec plugin in Camcorder

o Because camcorder clarified its audio, video, and image encoder in /usr/etc/mmfw_camcorder.ini file (mmfw-sysconf package), you need to change this category value to set your own codec name.

Tizen Porting Guide


Page 98 of 143

References

gst-openmax version : 0.10.1.0



For all GStreamer documentation, refer


For developing GStreamer plug-ins, refer


For more information about OpenMAX IL components, refer

http://www.khronos.org/openmax/il/





Tizen Porting Guide


Page 99 of 143

Connectivity

Bluetooth

Bluetooth is the short range communication used to communicate between two devices. In Tizen, we use open source Bluetooth components like Bluez and Obexd. Bluez and Obexd run as the daemon and there will be an interface library Bluetooth Framework, used for applications to access Bluez or Obexd over D-Bus interface. This section explains the Bluetoooth architecture on the Tizen platform and how Tizen can be ported, along with the configuration parameters and its values. The below figure explains the Bluetooth architecture on Tizen.

Bluetooth version supported - Bluetooth 3.0

Profiles supported - FTP, OPP, MAP, PBAP, A2DP, AVRCP, HSP/HFP, RFCOMM, HID, HDP, PAN profiles are supported.

Application Definition: Provides Dialogue for user. It controls BlueZ/ObexD/PulseAudio Daemon.

Tizen Porting Guide


Page 100 of 143

BT Framework

o Tizen BT is based on the Open Source BlueZ Project. BlueZ provides DBUS API and based on it, Tizen BT framework provides the C Language API, we recommend application developers use our BT framework.

o BT provides a standard interface between BT chip and AP, called the HCI (Host Controller Interface). HCI can be implemented on USB, UART, SDIO, but for the mobile environment, UART is used most.

Depending on the Chip Vendor, HCI Interface Activation could be different. The vendor would provide HCI Configuration and initial scripts

o Ex> Broadcom: It provides firmware and a loading tool.

Description

Application

o This is a user dialogue that controls the BlueZ/ObexD/PulseAudio Daemon

ObexD

o Obexd is the open source component, obexd 0.46 is supported

o Object exchange daemon

o Supports OPP, FTP, PBAP, SYNC, MAP profile stack

BluetoothD

o Bluetoothd is the open souce component, Bluez 4.101 is supported

o Bluetooth central daemon

o Support GAP, SDP, A2DP, AVRCP, HFP, HSP profile stack

Bluetooth Subsystem

o Provide BT unix socket. Each protocol can be accessed by it’s socket.

o Protocol - L2CAP, RFCOMM, SCO, HCI

Bluetooth Driver

o BT Chip Driver

o In case of UART, Linux kernel provides the interface.

o GPIO configuration, rfkill (Radio Frequency Management) and power management can be handled by both the vendor and the porting engineer.

BT Firmware Loading Module

o Depending on the environment, it loads BT firmware to BT chip.

o Tizen and chipset vendor need to implement this together.

Tizen Porting Guide


Page 101 of 143

o Package : bluetooth-tools


The following OAL scripts are run during BT stack start and end sequences. These scripts will invoke BT chip specific (such as Broadcom) scripts, provided by the chipset vendor to perform chip specific configuration and these scripts are available with bluetooth-dev-tools.under. When this package is installed, it copies these scripts under /usr/etc/Bluetooth/.

bt-stack-up.sh – This script file is used to run the hardware specific script file/files to power up or start BT hardware along the background processes, such as bluez and obexd.

bt-stack-down.sh – This script file is used to run the hardware specific script file/files to power down or stop BT hardware along with the background processes, such as bluez and obexd.

bt-reset-env.sh – This script file is used to reset the BT chip by running bt-stack-down.sh along with resource clean up.

Tizen BT Obex profiles

In Tizen, for the obex based profiles, we are using the obexd opensource ver 0.44.

BT Obex profiles server (obexd)

obexd –d –noplugin=syncevolution,pcsiut –symlinks –r /ftp_ folder

BT Obex profiles client (obex-client)

obex-client

Configuration

There are a few configuration changes that need to be made to enable the specific chipset and the scripts and other configuration information, like UART speed, UART terminal (tty) to be opened specific to the chipset. these changes should be provided by the chipset vendor.

Below is the example of BCM4330 Bluetooth chipset by Broadcomm.

hciattach - Project bluez/tools/hciattach.c is patched to enable the BCM4330 chipset specific hciattach tool. This service attaches the BT UART HCI interface to the bluetooth stack at baud rate of 921600. It is also responsible for loading the BT firmware on BCM4330.

Tizen Porting Guide


Page 102 of 143

The Bluetooth UART used is /dev/ttySAC0

The Broadcom firmware used is BCM4330B1_002.003.0379.0449.hcd

The UART speed configuration is 921600 for BCM4330B1

The bcmtool used is bcmtool_4330b1

The .bd_addr contains the unique bluetooth address, which is generated during first bluetooth activation

How to register the bluetooth device:

bcmtool_4330b1 /dev/ttySAC0 –FILE=BCM4330B1_002.003.0379.0449.hcd –BAUD=921600 –ADDR=.bd_addr –SETSCO=0,0,0,0,0,0,0,3,3,0 –LP

Attaching a serial device using UART HCI to the bluetooth stack for a broadcom device

hciattach /dev/ttySAC0 –S 921600 bcm2035 921600 flow

Running the bluetooth daemon version 4.98

bluetoothd

Device up and setting up the device name, SSP mode enabling

hciconfig hci0 up

hciconfig hci0 name “Tizen”

hciconfig hci0 sspmode 1

Turn on the bluetooth radio

rfkill unblock bluetooth

Turn off the bluetooth radio

rfkill block bluetooth

References Open source components versions : BlueZ 4.101, ObexD 0.46

Reference: http://www.bluez.org/

Reference kernel configuration for BT

The following kernel .config are enabled for Broadcom Bluetooth support:

CONFIG_BT=y

CONFIG_BT_L2CAP=y

CONFIG_BT_RFCOMM=y

CONFIG_BT_RFCOMM_TTY=y

http://www.bluez.org/

Tizen Porting Guide


Page 103 of 143

CONFIG_BT_BNEP=y

CONFIG_BT_HIDP=y

CONFIG_BT_HCIUART=y

CONFIG_BT_HCIUART_H4=y

CONFIG_BCM4330=y

CONFIG_RFKILL=y

CONFIG_RFKILL_INPUT=y

CONFIG_RXTRA_FIRMWARE_BCM4330=”BCM4330.hcd”

The following kernel .config are enabled for Bluetooth AVRCP support:

CONFIG_INPUT_MISC=y

CONFIG_INPUT_UINPUT=y

The following kernel .config are enabled for Bluetooth HID support:

CONFIG_INPUT_GP2A=y

CONFIG_INPUT_KR3DH=y

The following kernel .config are enabled for Bluetooth Audio (SCO-over-PCM) support:

CONFIG_BT_SCO=y

CONFIG_INPUT_GP2A=y

CONFIG_INPUT_KR3DH=y

The following kernel .config are enabled for Bluetooth Audio (SCO-over-PCM) support:

CONFIG_BT_SCO=y

Tizen Porting Guide


Page 104 of 143

WLAN

Description:

This section of the guide provides a step-by-step explanation of what's involved in adding a new Wi-Fi driver and making Wi-Fi work. Feature Overview:

WLAN (802.11 b/g/n)

WPS PBC

EAP (AKA, SIM) TIZEN uses wpa_supplicant as the platform interface to the Wi-Fi device. Your Wi-Fi driver must be compatible with the standard wpa_supplicant.

Tizen Porting Guide


Page 105 of 143

The TIZEN WLAN architecture is centered on the Linux wireless (IEEE-802.11) subsystem (Reference 2). The Linux wireless SW stack defines the WLAN HW adaptation SW interfaces that need to be used in TIZEN. In practice, the required interfaces are defined by cfg80211 for FullMAC WLAN devices and by mac80211 for SoftMAC WLAN devices. In addition, a Linux network interface needs to be supported towards the Linux TCP/IP stack. Connection Manager (ConnMan) is a daemon for managing internet connections within embedded devices running the Linux operating system. WPA Supplicant: wpa_supplicant is a WPA Supplicant with support for WPA and WPA2 (IEEE 802.11i / RSN). Supplicant is the IEEE 802.1X/WPA component that is used in the client stations. It implements key negotiation with a WPA Authenticator and it controls the roaming and IEEE 802.11 authentication/association of the WLAN driver (Reference 3).

Porting OAL Interface: WLAN Driver plugin is specific to a Wi-Fi chipset. This includes firmware and tools specific to Wi-Fi chipsets. Wi-Fi chipset firmware and tools files should be copied to WLAN driver plugin directory, build, and installed before testing Wi-Fi functionality. The WLAN driver plugin contains a file called wlan.sh (/usr/bin/wlan.sh), which is used to turn Wi-Fi on or off. When net_wifi_power_on() API is called, the load driver request is sent to the NET-CONFIG daemon. The NET-CONFIG daemon turns Wi-Fi ON using the wlan.sh script file. Similarly, the net_wifi_power_off() API requests unloading of the Wi-Fi driver.

Turning Wi-Fi ON/OFF:

Usage of /usr/bin/wlan.sh script: wlan.sh start : Power up the Wi-Fi driver in station mode by loading the driver and running the firmware file. wlan.sh stop : Power down the Wi-Fi driver. All other Wi-Fi related functionality is handled by the ConnMan daemon.

Configuration: None

References: Connection Manager(ConnMan) project website: http://connman.net/

http://connman.net/

Tizen Porting Guide


Page 106 of 143

Linux wireless (IEEE-802.11) subsystem: http://linuxwireless.org/

Information on Linux WPA/WPA2/IEEE 802.1X Supplicant: http://hostap.epitest.fi/wpa_supplicant/

Latest ConnMan release: http://git.kernel.org/?p=network/connman/connman.git;a=summary

WLAN driver plugin git path: /slp/pkgs/w/wlandrv-plugin

Reference kernel configurations

These options need to be enabled if the driver supports the cfg802.11 configuration API, instead of the wireless extension API. (Refer to: http://linuxwireless.org).

o CONFIG_CFG80211 o CONFIG_LIB80211 o CONFIG_MAC80211 (Enable this flag, if the driver supports softMAC feature).

On the other hand, the configuration options below should be enabled in the kernel if the driver supports wireless extension APIs.

o CONFIG_WIRELESS_EXT=y o CONFIG_WEXT_CORE=y o CONFIG_WEXT_PROC=y o CONFIG_WEXT_PRIV=y o CONFIG_WEXT_SPY=y o CONFIG_WIRELESS_EXT_SYSFS=y

http://linuxwireless.org/

http://hostap.epitest.fi/wpa_supplicant/

http://git.kernel.org/?p=network/connman/connman.git;a=summary

Tizen Porting Guide


Page 107 of 143

NFC

Description

The NFC application enables the user to read and/or import the content written on an NFC tag, edit the content written on an NFC tag, write and save data in an NFC tag, and load and save the NFC data from or in a file.

The NFC client acts as an interface between the NFC app and the NFC manager, while writing or editing tag information in any physical tag.

The NFC manager is the main interface, which actually deals with NFC physical tags, creates a connection with tags and detects it. It’s a daemon process to control the NFC chipset (such as NXP pn544). It provides Tag read/write service and basic P2P communication service. It provides basic API to client application.

The NFC stack contains the required plugin, based on the NFC chipset. Currently, nfc-plugin-nxp is used for the NXP chipset.

The NFC plugin acts as an interface between the NFC chipset with the NFC framework (nfc-manager). It should implement according to the interface provided by the nfc-manager.

Tizen Porting Guide


Page 108 of 143


The NFC plugin is implemented as a shared library and it interfaces the TIzen nfc-manager and the vendor NFC chip. The NFC manager will load the libnfc-plugin.so library at run time from “/usr/lib/libnfc-plugin.so”. Any vendor-specific plugin will be installed within the same path. The plugin should be written with predefined OAL API interfaces.

During initialization, the nfc-manager loads the nfc-plugin.so, searches for the ‘onload’ API, and calls the ‘onload’ API with an interface structure instance as an argument for mapping of all the OAL interfaces. These OAL/OEM interfaces are implemented according to the underlying NFC chipset. Once the mapping is done, the NFC manager will interact with nfc-plugin, which implements the vendor specific OAL interfaces.

‘onload‘ function for reference :

Bool onload(net_nfc_oem_interface_s *oem_interfaces)

{

oem_interfaces->init = xxx; // xxx refers to plugin APIs

oem_interfaces->deinit = xxx;

oem_interfaces->register_listener = xxx;

oem_interfaces->unregister_listener = xxx;

oem_interfaces->check_firmware_version = xxx;

......

return true;

}

The NFC OAL interfaces are defined in this structure:

Ref er net_nfc_oem_controller.h

typedef struct _net_nfc_oem_interface_s

{

net_nfc_oem_controller_init init;

net_nfc_oem_controller_deinit deinit;

net_nfc_oem_controller_register_listener register_listener;

net_nfc_oem_controller_unregister_listener unregister_listener;

net_nfc_oem_controller_check_firmware_version check_firmware_version;

net_nfc_oem_controller_update_firmware update_firmeware;

net_nfc_oem_controller_get_stack_information get_stack_information;

net_nfc_oem_controller_configure_discovery configure_discovery;

net_nfc_oem_controller_get_secure_element_list

get_secure_element_list;

Tizen Porting Guide


Page 109 of 143

net_nfc_oem_controller_set_secure_element_mode

set_secure_element_mode;

net_nfc_oem_controller_connect connect;

net_nfc_oem_controller_connect disconnect;

net_nfc_oem_controller_check_ndef check_ndef;

net_nfc_oem_controller_check_target_presence check_presence;

net_nfc_oem_controller_read_ndef read_ndef;

net_nfc_oem_controller_write_ndef write_ndef;

net_nfc_oem_controller_make_read_only_ndef make_read_only_ndef;

net_nfc_oem_controller_transceive transceive;

net_nfc_oem_controller_format_ndef format_ndef;

net_nfc_oem_controller_exception_handler exception_handler;

net_nfc_oem_controller_is_ready is_ready;

net_nfc_oem_controller_llcp_config config_llcp;

net_nfc_oem_controller_llcp_check_llcp check_llcp_status;

net_nfc_oem_controller_llcp_activate_llcp activate_llcp;

net_nfc_oem_controller_llcp_create_socket create_llcp_socket;

net_nfc_oem_controller_llcp_bind bind_llcp_socket;

net_nfc_oem_controller_llcp_listen listen_llcp_socket;

net_nfc_oem_controller_llcp_accept accept_llcp_socket;

net_nfc_oem_controller_llcp_connect_by_url connect_llcp_by_url;

net_nfc_oem_controller_llcp_connect connect_llcp;

net_nfc_oem_controller_llcp_disconnect disconnect_llcp;

net_nfc_oem_controller_llcp_socket_close close_llcp_socket;

net_nfc_oem_controller_llcp_recv recv_llcp;

net_nfc_oem_controller_llcp_send send_llcp;

net_nfc_oem_controller_llcp_recv_from recv_from_llcp;

net_nfc_oem_controller_llcp_send_to send_to_llcp;

net_nfc_oem_controller_llcp_reject reject_llcp;

net_nfc_oem_controller_llcp_get_remote_config get_remote_config;

net_nfc_oem_controller_llcp_get_remote_socket_info

get_remote_socket_info;

net_nfc_oem_controller_sim_test sim_test;

net_nfc_oem_controller_test_mode_on test_mode_on;

net_nfc_oem_controller_test_mode_off test_mode_off;

net_nfc_oem_controller_support_nfc support_nfc;

} net_nfc_oem_interface_s;

The nfc_oem_interface_s is exported in the nfc-plugin. Using this interface structure, the nfc-ma

nager communicates with the OAL interfaces at run time. The NFC plugin will load when the nfc-

manager is started and the plugin init() function will be called. The init function will initialize th

e NFC chip.

Tizen Porting Guide


Page 110 of 143

int (*init) (net_nfc_oem_controller_init*) ;

This is the deinit() function the nfc-manager issues to de-initialize the NFC chip:

int (*deinit) (net_nfc_oem_controller_deinit *);

Sending the Notification to upper Layer (NFC Service)

Please, you can refer the phdal4nfc_message_glib.c. We use the g_idle_add_full for handling

the message in NFC Service. So we can use the callback client asynchronously in the client

context. We post a message in queue. The message will be processed by a client thread.

Reference implementation of NFC plugin

Sample code snippets cannot be reproduced. This is proriatory code. You can refer nfc-plugin-emul and nfc-plugin-nxp.

Configuration The nfc-plugin package should be saved to ‘/usr/lib/libnfc-plugin.so’ at install time. When nfc-manager starts, it looks for the plugin library and loads the it dynamically from this path.

Reference

Kernel Config Using Pn544 : CONFIG_PN544_NFC Using Pn65n : CONFIG_PN65N_NFC

API references available are under the Appendix

Tizen Porting Guide


Page 111 of 143

Location

SLP Location Framework

Description

Location provides location based services (LBS), including the position information, geocoding, satellite information, and GPS status. It is based on GeoClue that delivers location information receiving from various positioning sources, such as GPS, WPS (Wi-Fi Positioning System), Cell ID, and sensors.

Features Overview

Hybrid positioning solution

o GPS (Global Positioning System)

o WPS (Wi-Fi Positioning System and cell towers)

o PDR (Pedestrian Dead Reckon)

Getting the current position, last know position, accuracy, distance, and velocity.

Getting satellite information of GPS and GLONASS.

Tizen Porting Guide


Page 112 of 143

Notifying a user when they enter or exit a predefined set of boundaries, known as geo-fence, like school attendance zones or neighborhood boundaries.

Geocoding and reverse Geocoding.

Location framework Description

Location Library

SLP gives applications access to the location services supported by the device through the location library, which provides APIs to determine location and bearing of the underlying device (if available).

o GPS (Global Positioning System)

GPS provides position information, velocity, and satellite information. It is used to get current position of a local device.

o WPS (Wi-Fi Positioning System)

WPS provides position information and velocity information. It needs to connect to remote service to get information.

o SPS (Sensor Positioning System)

Sensor provides position information, velocity, and satellite information. It usesa GPS chipset and sensors to provide dead reckoning.

o GEOCODE

Geocode provides address related information, such as country name, city name, or street name. It is using remote service to match given position with adequate information.

GeoClue Library

GeoClue is a modular geoinformation service built on top of the D-Bus messaging system. GeoClue is Free Software, licensed under GNU LGPL. It is developed for Linux, but should be portable to any platform that uses D-Bus.

GeoClue defines a set of geoinformation APIs, but it also includes some providers that implement those APIs.

Here is a list of services provided through GeoClue with the included implementations:

o GeocluePosition

o holds position data (latitude, longitude, altitude)

o GeoclueAddress

o returns a HashTable of address information (divided into "street", "postalcode", "area", "locality", "region", "country", etc...)

o GeoclueVelocity

Tizen Porting Guide


Page 113 of 143

o reports velocity information, in the form of speed, direction, and climb

o GeoclueGeocode

o converts an address to a position (latitude, longitude, altitude)

o GeoclueReverseGeocode

o converts a position to an address

o GeoclueAccuracy

o reports the horizontal and vertical accuracy levels. This can be applied to each of the previous services, except for GeoclueVelocity

Geoclue Providers

GPS Manager

o A process that provides position information, velocity, NMEA[1], and satellite information.

o It performs satellite navigation calculations and manages the satellite selection process.

o It calculates one’s current location using information provided by a GPS receiver, which supports autonomous, MS-based, MS-assisted, and enhanced autonomous GPS operation.

geoclue-pdr

o geoclue-pdr calculates one's current position by using a previously determined position and advances that position based upon known or estimated speeds over elapsed time, and course formation with sensors, such as accelerometer, compass, and gyroscope.

geoclue-xps

o A process that calculates the position of a device through near-by Wi-Fi access points and Cell towers.

geoclue-nominatim.

o A process that gives an address or a position provided by Nominatim service.

o Nominatim is a tool to search OpenStreetMap data by name and address and to generate synthetic addresses of OSM points (reverse geocoding). It can be found at: http://nominatim.openstreetmap.org.

Geoclue interfaces supported by geoclue providers:

API gps-manager Geoclue-nominatim

gc_iface_position_emit_position_changed o

http://nominatim.openstreetmap.org/

http://nominatim.openstreetmap.org/

Tizen Porting Guide


Page 114 of 143

gc_iface_position_get_position o

gc_iface_velocity_emit_velocity_changed o

gc_iface_velocity_get_velocity o

gc_iface_satellite_emit_satellite_changed o

gc_iface_satellite_get_satellite o

gc_iface_nmea_emit_nmea_changed o

gc_iface_nmea_get_nmea o

gc_iface_address_emit_address_changed

gc_iface_address_get_addres

gc_iface_geocode_address_to_position o

gc_iface_geocode_freeform_address_to_position o

gc_iface_reverse_geocode_position_to_address o

gc_iface_geoclue_emit_status_changed o

GPS Manager

GPS Manager provides position, velocity, NMEA, and satellite information by communicating with a GPS chip.

Functionalities of GPS manager:

o GPS initialization/de-initialization and open/close control.

o Provides the position result for location library.

o Location session management-determination for session termination based on session status.

o Serial interface with the GPS receiver.

o Enables GPS chipset to support multi-mode AGPS and standalone GPS positioning methods.

o Supported operation modes.

o Standalone

A GPS receiver device in which the receiver provides all of its own data needs and performs all position calculations, without connection to an external network or server.

o Assistant GPS

A user-plane communication protocol that enables a mobile set to communicate with an A-GPS server in a simple, network-independent way on TCP/IP networks.

SUPL[2] SET Initiated : originate from the SET

http://10.89.55.57:8080/#_ftn2

Tizen Porting Guide


Page 115 of 143

SUPL Network Initiated : originate from within the SUPL network

Control plane

All of the information related to A-GPS on the CCH[3] of a wireless network session. The control plane provides location-aware, voice-based emergency services over wireless circuit-switched data. The sessions are designed for E-911 emergency services in the United States.

Name Version License URL

GeoClue 0.12 LGPL http://geoclue.freedesktop.org

GeoClue is a modular geoinformation service buit on top of D-Bus messaging system. Geoclue is

free software, licenced under GNU LGPL. It is developed for Linux, but should be portable to a

ny platform that uses D-Bus.


The GPS plugin is implemented based on Tizen GPS manager for vendor specific GPS device.

The GPS plugin is implemented as a shared library and the gps-manager loads a specific GPS

plugin at runtime. A GPS plugin should be written with predefined interfaces.

The gps-manager-plugin-dev source package is installed on OBS by adding the following command in the package spec file.

BuildRequires: pkgconfig(gps-manager-plugin)

With gps-manager-plugin-dev package source files can be found in:

/usr/include/gps-manager-plugin/*.h

/usr/lib/pkgconfig/gps-manager-plugin.pc.

gps_manager_plugin_intf.h includes the API interfaces for the communication between the g

ps-manager and its GPS plugin.

typedef struct {

/** Initialize plugin module and register callback function for event delivery */

int (*init) (gps_event_cb gps_event_cb, gps_server_param_t * gps_params);

/** Deinitialize plugin module */

int (*deinit) (gps_failure_reason_t *reason_code);

http://10.89.55.57:8080/#_ftn3

Tizen Porting Guide


Page 116 of 143

/** Request specific action to plugin module */

int (*request) (gps_action_t gps_action, void *data,

gps_failure_reason_t *reason_code);

} gps_plugin_interface;

const gps_plugin_interface *get_gps_plugin_interface();

get_gps_plugin_interface() function should be exported in GPS plugin. It gives gps_plugin_interf

ace structure to the gps-manager, and the gps-manager will be communicated by these interfac

es. When the gps-manager is started, a GPS plugin will be loaded and init() function is called. At

this moment, A GPS device should be initialized. (power control, firmware download, etc...)

int (*init) (gps_event_cb gps_event_cb, gps_server_param_t * gps_params);

When init() function is called, gps_event_cb is set. GPS events and data from a GPS device is deli

vered by registered call back function "gps_event_cb".

typedef int (*gps_event_cb) (gps_event_info_t *gps_event_info);

GPS events are described in below.

typedef enum {

GPS_EVENT_START_SESSION = 0x0000,/**< The session is started */

GPS_EVENT_STOP_SESSION, /**< The session is stopped */

GPS_EVENT_REPORT_POSITION = 0x0100,/**< Bring up GPS position data */

GPS_EVENT_REPORT_SATELLITE, /**< Bring up GPS SV data */

GPS_EVENT_REPORT_NMEA, /**< Bring up GPS NMEA data */

GPS_EVENT_SET_OPTION = 0x0200,/**< The option is set */

GPS_EVENT_GET_REF_LOCATION = 0x0300,/**< Get the reference location for AGPS */

GPS_EVENT_GET_IMSI, /**< Get IMSI for identification */

GPS_EVENT_OPEN_DATA_CONNECTION = 0x0400,/**< Request opening data network connection */

GPS_EVENT_CLOSE_DATA_CONNECTION, /**< Request closing data network connection */

GPS_EVENT_DNS_LOOKUP_IND, /**< Request resolving host name */

GPS_EVENT_AGPS_VERIFICATION_INDI, /**< Verification indicator for AGPS is required

GPS_EVENT_FACTORY_TEST = 0x0500,/**< Factory test is done */

GPS_EVENT_ERR_CAUSE = 0xFFFF /**< Some error is occurred */

} gps_event_id_t;

Tizen Porting Guide


Page 117 of 143

The GPS events will contain specific GPS event data which is part of gps_event_data_t and the

GPS configuration is delivered by gps_server_param_t structure, refer to gps_manager_extra_d

ata_types.h. When the gps-manager want to make a request to GPS device, the request() functi

on is called.

int (*request) (gps_action_t gps_action, void *data, gps_failure_reason_t *reason_code);

Each request is classified by gps_action_t.

typedef enum {

GPS_ACTION_SEND_PARAMS = 0x00,

GPS_ACTION_START_SESSION,

GPS_ACTION_STOP_SESSION,

GPS_INDI_SUPL_VERIFICATION,

GPS_INDI_SUPL_DNSQUERY,

GPS_ACTION_START_FACTTEST,

GPS_ACTION_STOP_FACTTEST,

GPS_ACTION_REQUEST_SUPL_NI

} gps_action_t;

With the standalone GPS (Unassisted GPS), GPS_ACTION_START_SESSION and GPS_ACTION_ST

OP_SESSION are mandatory actions. If the GPS_ACTION_START_SESSION is delivered, the GPS

plugin shall startacquisition of satellites and report the GPS_EVENT_START_SESSION event to t

he gps-manager by the gps_event_cb callback function. Oncethe acquisitions completed and p

osition is fixed, its position should be delivered by the gps_event_cb with the GPS_EVENT_REPO

RT_POSITION event id and the position data.

To shut down the gps-manager, deinitialize the GPS device with the gps-manager call deinit()

function.

int (*deinit) (gps_failure_reason_t *reason_code);

Configuration

None

Tizen Porting Guide


Page 118 of 143

References

None

Tizen Porting Guide


Page 119 of 143

Telephony

Description Telephony provides modem services to applications by providing an interface between applications and modem and performing book keeping of certain modem services. Telephony provides this functionality through the following entities:

Telephony Server

Telephony API (TAPI) Library

Telephony Plug-ins The diagram below provides an overview of the Telephony's various entities.

Telephony Server

The Telephony Server is a key Tizen service, which maintains state information related to

modem services and connects applications to modem plug-ins through the TAPI library.

Telephony API (TAPI) Library

The TAPI Library provides an interface to applications to access various Telephony services. The

TAPI library runs in the context of calling application process and communicates with the

telephony server through the IPC mechanism. TAPI provides comprehensive and flexible access

to Telephony capabilities; providing full control over a call. Applications, consequently, must be

Tizen Porting Guide


Page 120 of 143

aware of details, such as Telephony call states. An asynchronous programming model is

available, primarily to help applications execute multiple requests concurrently along with the

TAPI functions that may take a relatively long time to execute. TAPI additionally provides

Telephony related services required by other frameworks and components like, messaging

service framework for sending SMS messages.

Refer to Tizen source website http://review.tizen.org/git/ for the package at

framework/telephony/libslp-tapi.git.

Telephony Plug-Ins

Telephony plugins provide an adaptation interface that can be used to customize Telephony

components. Telephony plugins mainly handle requests, responses and notifications between

Application Processor (AP) and Communication Processor (CP) through any format of IPC

message, including AT command. Telephony supports features through this Telephony plugins:

Voice / Video call

Supplementary service control, USSD

Packet data connection handling

Network Information (such as signal strength)/registration

SMS transport

SIM/USIM services such as PIN code checks and read/write/delete of SIM/USIM

resident data

SIM Application Toolkit mechanism(s)

Sound control

The details of implementating plugins are described in the next section.


As mentioned in the previous section, to provide customized the Telephony components, the

developer should implement appropriate plugins. All required modem service can be

implemented in either a single plugin or a combination of plugins. It is up to the vendor

developer. However, to help implementation, we provide template plugins, which are generally

categorized into four types according to their use:

Communicator plugin –

o Interface between applications and the Tizen Telephony stack

http://review.tizen.org/git/

Tizen Porting Guide


Page 121 of 143

o D-BUS communicator is provided by default.


framework/telephony/tel-plugin-dbus-tapi.git

Modem plug-in –

o Provides functionality for core Telephony operations such as Network,

Call, SS, SMS, GPRS, SIM, SAP, SIM Phonebook, and SAT.

Modem Interface plug-in –

o Interface between Application processor and Communication processor

o It depends on HW design (modem used) and vendor modem

implementation.

o It is called as HAL (HW Abstraction Layer) plugin.

Freestyle plug-in –

o Independently processes tasks based on certain triggers.

Therefore, for the vendor side, the main part of porting OAL interface will be to implement

Modem plugin and Modem interface plugin. Those plugins should allow any choice of hardware

architecture and protocol stack solution. Tizen Telephony can support one or more modems

(such as GSM, GPRS, EDGE, WCDMA/UMTS, HSDPA, CDMA95, CDMA2000 1xRTT, EVDO, etc) or

inter-processor communication methods to a modem (such as USB, UART, DPRAM, HSIC, etc.)

depending on the provider architecture. In case of SIM Application Toolkit commands, modem

plug-in shall support parsing of raw SAT APDU data received from SIM and provide the parsed

information to the communicator through Telephony server. Modem plugin encodes the

envelope commands (such asEvent Download, Menu Selection) and terminal responses

received from TS before sending to SIM.

Implementation of a plugin The start point of implementing a plugin is to follow the plugin descriptor structure. Then Telephony server would invoke these APIs for the following functionality:

Function Description

tcore_plugin_define_desc->load() To load the Plug-in into the correct folder where all Plug-ins are expected to be residing


Tizen Porting Guide


Page 122 of 143

tcore_plugin_define_desc->init() To initialize the loaded Plug-in to get into functional state of servicing the Requests requested by User applications (through TAPI).

tcore_plugin_define_desc->unload() To unload and de-initialize the Plug-induring Telephony Server shutdown.

Structure Description(0-success, -1 - failure)

struct tcore_plugin_define_desc {

gchar *name;

enum tcore_plugin_priority

priority;

int version;

gboolean (*load)();

gboolean (*init)(TcorePlugin *);

void (*unload)(TcorePlugin *);

};

This structure is referred by Telephony Server to load, initialize, and unload the Plug-in. This structure defines:

1. Name of the Plug-in

2. Priority of the Plug-in

3. init/entry/exit points: The load, init and unload APIs are the plug-in’s init/entry/exit points. Telephony server will invoke these APIs during different stages of its execution; load and init APIs would be invoked during Plug-in loading phase of Telephony Server start-up and unload would be invoke during shutdown procedure of Telephony Server

<Table 1. Plug-in Descriptor Structure>

Implementation of a Modem Plugin

As described in the initial point, to serve modem services which are exported to applications by Telephony APIs, modem plugins normally support these major functionalities:

1. Operation functions to provide functionality to serve user (TAPI) requests. 2. Receive callback function to receive data from modem side through HAL plugin. 3. Event handler functions to receive system and registered events

as well as AT unsolicited messages. Above functionalities are designed to work on the basis of CoreObject, which is defined for each modem services. It is helpful to look into header / source files, like below, because it is out of scope of this document to describe all feature and design architecture of our Libtcore library.

co_call.h, co_ps.h, co_context.h, co_modem.h, co_network.h,

co_phonebook.h, co_sap.h, co_sat.h, co_sim.h, co_sms.h, co_ss.h at.h

co_call.c, co_ps.c, co_context.c, co_modem.c, co_network.c,

Tizen Porting Guide


Page 123 of 143

co_phonebook.c, co_sap.c, co_sat.c, co_sim.c, co_sms.c, co_ss.c at.c


framework/telephony/libtcore.git/include and framework/telephony/libtcore.git/src

Control Message transmission flow between TAPI and modem side

If a user request is triggered through TAPI, appropriate operation functions will be invoked. Then each operation function conducts thesesteps.

1. Construct IPC message. 2. Make a new pending. (For easy understanding, let’s think pending as message carrier.) 3. Put IPC message into the pending. 4. Register response callback into the pending. 5. Send the pending through the HAL plugin.

The above steps are supported by these functions:

1) None

2) TcorePending *tcore_pending_new(CoreObject *co, unsigned int id);

3) TReturn tcore_pending_set_request_data(TcorePending *pending,

unsigned int data_len, void *data);

4) TReturn tcore_pending_set_response_callback(TcorePending *pending,

TcorePendingResponseCallback func, void *user_data);

5) TReturn tcore_hal_send_request(TcoreHal *hal, TcorePending *plugin);

In case of unsolicited messages from modem side, it is handled by registering event handler for designated unsolicited message initially.

TReturn tcore_object_add_callback(CoreObject *co, const char *event,

CoreObjectCallback callback, void *user_data);

Reference Implementation of Modem plugin

1. Init codes of plugin according to plugin descriptor strucuture. (e.g. …/src/desc.c)

static void on_hal_recv(TcoreHal *hal, unsigned int data_len, const

void *data, void *user_data)

{

TcorePlugin *p = user_data;


Tizen Porting Guide


Page 124 of 143

…

/* Dispatch the received data based on IPC message format.

* According to the type of IPC message, invoke appropriate

* function. Here, „id‟(pending id)is for matching request

* and response set, if neccessary.

*/

/* if notification data */

tcore_plugin_core_object_event_emit(p, “my_event”, data);

/* if response data */

tcore_hal_dispatch_response_data(hal, id, data_len, data);

}

static gboolean on_load()

{

// prepare plugin for init call

}

static gboolean on_init(TcorePlugin *plugin)

{

TcoreHal *h; /* Reference point of HAL plugin. */

/* Initialize plugin */

…

/* Find HAL plugin which is match up with currnet modem. */

h = tcore_server_find_hal(tcore_plugin_ref_server(p), cp_name);

…

/* Register callback function if neccessary.

* Callback will be invoked when HAL plugin receives

* data from modem.

*/

tcore_hal_add_recv_callback(h, on_hal_recv, plugin);

…

Tizen Porting Guide


Page 125 of 143

/* Initialize actual function components supported by modem. */

s_modem_init(p, h);

s_sim_init(p, h);

s_sat_init(p, h);

s_network_init(p, h);

s_sap_init(p, h);

s_ps_init(p, h);

s_call_init(p, h);

s_ss_init(p, h);

s_sms_init(p, h);

s_phonebook_init(p, h);

…

return TRUE;

}

static void on_unload(TcorePlugin *plugin)

{

/* Deinitialize plugin */

/* Free all resources allocated for the plugin. */

}

struct tcore_plugin_define_desc plugin_define_desc =

{

.name = "my_modem",

.priority = TCORE_PLUGIN_PRIORITY_MID,

.version = 1,

.load = on_load,

.init = on_init,

.unload = on_unload

};

2. An example of main codes for modem service, which is related to “co_modem.c”, to send, receive and

handle IPC messages. (such as …/src/modem.c)

Tizen Porting Guide


Page 126 of 143

static void on_my_event(CoreObject *o, const void *event_info, void

*user_data)

{

struct tnoti_xxx; /* refer type/notification.h, type/xxx.h */

/* check event_info */

tcore_server_send_notification(tcore_plugin_ref_server(tcore_object

_ref_plugin(o)), o, TNOTI_XXX, sizeof(struct tnoti_xxx), &xxx);

}

static void on_response_set_flight_mode(TcorePending *p, int data_len,

const void *data, void *user_data)

{

CoreObject *o = user_data;

UserRequest *ur;

struct tresp_modem_set_flightmode resp;

/* check data_len, data */

/* if success */

resp.result = TCORE_RETURN_SUCCESS;

tcore_modem_set_flight_mode_state(o, TRUE);

/* if fail */

Resp.result = TCORE_RETURN_3GPP_ERROR;

tcore_modem_set_flight_mode_state(o, FALSE);

ur = tcore_pending_ref_user_request(p);

tcore_user_request_send_response(ur, TRESP_MODEM_SET_FLIGHTMODE,

sizeof(struct tresp_modem_set_flightmode), &resp);

}

static TReturn set_flight_mode(CoreObject *o, UserRequest *ur)

{

const struct treq_modem_set_flightmode *req_data;

TcorePending *pending = NULL;

Tizen Porting Guide


Page 127 of 143

TcoreHal *hal = tcore_object_get_hal(o);

char *data; /* For IPC message */

req_data = tcore_user_request_ref_data(ur, NULL);

if (req_data->enable) {

/* Construct IPC message for enable case. */

data = …;

}

else {

/* Construct IPC message for disable case. */

data = …;

}

pending = tcore_pending_new(o, 1 /* ID */);

tcore_pending_set_request_data(pending, strlen(data), data);

tcore_pending_set_response_callback(pending, on_set_flight_mode,

o);

…

tcore_hal_send_request(hal, pending);

…

}

static struct tcore_modem_operations modem_ops =

{

/* Operations which are mapped with TAPI. */

.power_on = power_on,

.power_off = power_off,

.power_reset = power_reset,

.set_flight_mode = set_flight_mode,

.get_imei = get_imei,

.get_version = get_version,

…

};

gboolean s_modem_init(TcorePlugin *p, TcoreHal *hal)

{

Tizen Porting Guide


Page 128 of 143

CoreObject *o;

…

/* Construct CoreObject:

* “modem”: name of Core-Object

* modem_ops: Operations related to modem service.

* hal: HAL plugin reference point.

*/

o = tcore_modem_new(p, "modem", &modem_ops, hal);

…

/* Register event hanlder for designated event. */

tcore_object_add_callback(o, "my_event", on_my_event, NULL);

}

Implementation of a new Plug-in on HW interface

The HAL plugin requires following three mechanisms:

1. Power On mechanism Open and enable the physical channel between AP and CP. It is usually provided by hal_power() operation.

2. Rx Mechanism Initialize the Rx path and receive IPC data using GIOChannel by g_io_add_watch(). It is usually provided by either hal_power() operation or on_init() function.

3. Tx Mechanism Send IPC data directly to the modem through opened channel. It is usually provided by hal_send() operation.

Reference implementation of HAL plugin

(such as …/src/desc_halname.c)

/* Structures for Power on and Rx mechanism */

struct custom_data {

int fd;

guint watch_id;

gboolean on;

};

static gboolean on_init(TcorePlugin *plugin)

{

/* Allocate required resources. */

Tizen Porting Guide


Page 129 of 143

TcoreHal *h;

/* User data can be globally shared in HAL plugin. */

struct custom_data *data;

…

data = calloc(sizeof(struct custom_data), 1);

/* Create a new HAL instance. */

tcore_hal_new(plugin, "name", &hops, TCORE_HAL_MODE);

/* Link user data to HAL instatnce. */

tcore_hal_link_user_data(h, data);

return TRUE;

}

static gboolean on_recv_ipc_message (GIOChannel *channel, GIOCondition

condition, gpointer data)

{

TcoreHal *hal = data;

struct custom_data *custom;

…

custom = tcore_hal_ref_user_data(h);

/* read data from fd */

/* n = length, buf = read data */

n = read(custom->fd, (guchar *) buf, BUF_LEN_MAX);

/* Invoke receive callback function, if neccessary. */

tcore_hal_emit_recv_callback(hal, n, buf);

}

static TReturn hal_send(TcoreHal *hal, unsigned int data_len, void

*data)

{

int ret;

Tizen Porting Guide


Page 130 of 143

struct custom_data *user_data;

…

user_data = tcore_hal_ref_user_data(h);

…

/* write data to fd */

ret = write( user_data->fd, (guchar *) data, data_len );

…

}

static gboolean _channel_init( TcoreHal *h, struct custom_data *ch,

cb_func recv_message )

{

…

/* Open physical channel to modem. */

ch->fd = device_open();

…

/* Register Rx handler and watch events using GIOChannel. */

ch->watch_id = register_gio_watch(h, ch->fd, recv_message);

…

}

Static TReturn hal_power(TcoreHal *hal, gboolean flag)

{

struct custom_data *user_data = 0;

…

user_data = tcore_hal_ref_user_data(h);

…

/* Open physical channel and register Rx handler

* to receive IPC data.

*/

ret = _channel_init( h, &user_data, on_recv_ipc_message );

…

}

static struct tcore_hal_operations hops =

{

Tizen Porting Guide


Page 131 of 143

.power = hal_power,

.send = hal_send

}

Reference implementation of Modem plugin (AT Command)

Our telephony plugin interface supports AT command standards, such as sending AT requests, receiving and handling of AT responses, and unsolicited messages. Our core telephony library fully provides these AT related functionalities, including AT parser.


framework/telephony/libtcore.git/src/at.c The actual implementation of AT command based modem plugin is not much different with the description in the previous sections. Main differences are: 1. Constructing of HAL plugin in AT mode.

/* In Telephony, the parsing of AT response is provided by HAL.

* To support AT command, HAL should be initailzed as AT mode.

* Otherwise as another type or NULL.

*/

enum tcore_hal_mode {

TCORE_HAL_MODE_UNKNOWN,

TCORE_HAL_MODE_AT,

TCORE_HAL_MODE_CUSTOM

};

tcore_hal_new(plugin, "name", &hops, TCORE_HAL_MODE_AT);

2. Sending AT command request

/* AT Response Types:

* no intermediate response expected.

* a single intermediate response starting with a 0-9.

* a single intermediate response starting with a prefix.

* multiple line intermediate response starting with a prefix.

*/

enum tcore_at_command_type {


Tizen Porting Guide


Page 132 of 143

TCORE_AT_NO_RESULT,

TCORE_AT_NUMERIC,

TCORE_AT_SINGLELINE,

TCORE_AT_MULTILINE

};

TcorePending *tcore_at_pending_new(

CoreObject *co, const char *cmd,

const char *prefix,

enum tcore_at_command_type type,

TcorePendingResponseCallback func,

void *user_data

)

An example implementation of the trigger function for an AT request

static TReturn set_flight_mode(CoreObject *o, UserRequest *ur)

{

…

if (req_data->enable) {

dbg("Flight mode on/n");

cmd_str = g_strdup("AT+CFUN=4\r");

}

else {

dbg("Flight mode off/n");

cmd_str = g_strdup("AT+CFUN=1\r");

}

…

pending = tcore_at_pending_new(o, cmd, NULL, TCORE_AT_NO_RESULT,

on_set_flight_mode, NULL);

tcore_pending_link_user_request(pending, ur);

tcore_hal_send_request(hal, pending);

…

}

3. Utility functions to parse AT response

Tizen Porting Guide


Page 133 of 143

/* tcore_at_tok_new() API analyse AT reponse and divids it into

* string tokens. Tokens are categorized as four type as follow,

* 1) String: tokens surrounded with quotation marks. e.g.) “ABCD”

* 2) Range: tokens surrounded with brackets. e.g.) (5,10) or (“X”)

* 3) Empty token: skiped element as zero length string. e.g.) ,,

* 4) No type: Not belongs to above, saved as itself.

* e.g.) CRING: VOICE

*/

GSList *tcore_at_tok_new(const char *line);

char *tcore_at_tok_nth(GSList *tokens, unsigned int token_index);

An example implementation of the handler function for an AT reponse

static gboolean on_my_event(CoreObject *o, const void *event_info,

void *user_data)

{

GSList *lines = (GSList *)event_info;

GSList *tokens;

char* str; /* for string type response */

int var; /* for integer type response */

struct tnoti_xxx; /* refer type/notification.h, type/xxx.h */

…

tokens = tcore_at_tok_new(lines->data);

…

str = tcore_at_tok_nth(tokens, /* index */);

var = atoi(tcore_at_tok_nth(tokens, /* index */));

…

tcore_server_send_notification(tcore_plugin_ref_server(tcore_object_re

f_plugin(o)), o, TNOTI_XXX, sizeof(struct tnoti_xxx), &xxx);

return TRUE;

}


framework/telephony/tel-plugin-imc.git/src and


Tizen Porting Guide


Page 134 of 143

framework/telephony/tel-plugin-imcmodem.git/src

Configuration

All the Telephony server plugins need to be present in the below location (Library path):

Library Path: /usr/lib/telephony/plugins/

Any new Plugin to be added should follow the following naming convention and be added to

the above location:

Plugin name : your_plugin_name.so

The developer does not consider any configuration for running the SLP telephony server. Only

the name and location of the plugin library should be considered.

Tizen Porting Guide


Page 135 of 143

Appendix

Sensor Processor Plugin APIs

Prototype

Description Return Value

accel_processor() constructor, initialize all privite variables NA

virtual ~ accel_processor() destructor, deallocate variables NA

const char *name(void) return plugin's name return m_name (processor plugin name)

int id(void) return plugin's ID return m_id (processor plugin ID)

int version(void) return plugin's version return m_version (processor plugin version)

bool update_name(char *name) update sensor_name. param[in] char *name new processor plugin name

Success- True Failure-False

bool update_id(int id) update ID of plugin. param[in] int id new plugin ID


bool update_version(int version) update version of plugin. param[in] int version new plugin version


bool add_input(csensor_module * sensor)

Add sensor module in processor plugin. param[in] csensor_module *sensor sensor plugin's module


bool add_input(cfilter_module * filter)

Add filter module in processor plugin. param[in] cfilter_module *filter filter plugin's module


long value(int id) get sensor data by port id. param[in] desired port id

return sensor data by port id

long value(char *port) get sensor data by port name. param[in] desired port name

return sensor data by port name

cprocessor_module *create_new(void)

create list of processors and return processor module

Success- processor module instance

void destroy(cprocessor_module * module)

delete module in list of processors and delete module

Success- processor module instance

static void *working(void *inst) get sensor data and make event, set event to vconf. param[in] void *inst processor module

NA

static void *stopped(void *inst) stop loop. param[in] void *inst processor module

NA

virtual bool start(void) start processor plugin(set m_client for counting)


virtual bool stop(void) stop processor plugin(set m_client for Success- True

Tizen Porting Guide


Page 136 of 143

counting) Failure-False

bool add_callback_func(cmd_reg_t * param)

register callback event. param[in] cmd_reg_t *param event parameter


bool remove_callback_func(cmd_reg_t * param)

unregister callback event. param[in] cmd_reg_t *param event parameter


bool check_callback_event(cmd_reg_t * param)

check callback event. param[in] cmd_reg_t *param event parameter


long set_cmd(int type, int property, long input_value)

setting event or data in sensor and return result or output data. param[in] int type sensor type, int property property or command for sensor, input_value input data for property or command

return output data from property or command

int get_property(unsigned int property_level, void *property_data)

return sensor specification. param[in] unsigned int property_level desired specification param[out] vod *property_data specification data

Success- 0 Failure – Negative value [-1]

int get_struct_value(unsigned int struct_type, void *struct_values)

return menaingful sensor data. param[in] unsigned int struct_type desired data type param[out] vod *struct_values meaningful data structure including values

Success- 0 Failure – Negative value [-1]

cmodule *module_init(void *win, void *egl)

initial and create module. param[in] void *win, void *egl

if it succeeds, it returns the created module, otherwise return NULL

void module_exit(cmodule *inst) delete created module. param[in] cmodlue *inst

NA

Tizen Porting Guide


Page 137 of 143

NFC OAL API

Function Name Function

Description Argument

net_nfc_oem_controller_init init; init the nfc chip net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_deinit deinit; deinit nfc chip none

net_nfc_oem_controller_register_listener register_listener;

It registers callback function for tag event, se event, llcp event

target_detection_listener_cb target_detection_listener : The callback function for tag event. se_transaction_listener_cb se_transaction_listener : The callback function for se event. llcp_event_listener_cb llcp_event_listener : The callback function for llcp event net_nfc_error_e : When it fail, it returns error code.

net_nfc_oem_controller_unregister_listener unregister_listener;

It releases callback function for tag event, se event, llcp event.

none

net_nfc_oem_controller_check_firmware_version check_firmware_version;

It checks the firmware version of nfc chip.

net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_update_firmware update_firmeware;

It tries to update firmware of nfc chip.


net_nfc_oem_controller_get_stack_information get_stack_information;

It gets the list of support tag and current firmware version.

net_nfc_stack_information_s : It’s pointer value to get The information of support tag and current firmware version. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_configure_discovery configure_discovery;

It delivers the config information to discovery.

net_nfc_discovery_mode_e : The mode to start/stop. net_nfc_event_filter_e config : The information for tag filteing. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_get_secure_element_list get_secure_element_list;

It gets the information of current secure element.

net_nfc_secure_element_info_s: the pointer value to get secure element information. int : the pointer value to get the count of secure element. net_nfc_error_e : When it fails, it returns error code.

Tizen Porting Guide


Page 138 of 143

net_nfc_oem_controller_set_secure_element_mode set_secure_element_mode;

It sets the secure element to use.

net_nfc_secure_element_type_e : The information of secure element. net_nfc_secure_element_mode_e : The mode information to set. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_connect connect; It tries to connect the detected tag/target.

net_nfc_target_handle_s : The handle of tag/target for connecting. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_connect disconnect;

It tries to disconnect the connected tag/target.

net_nfc_target_handle_s : The handle of tag/target for disconnecting. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_check_ndef check_ndef; It checks the tag to support ndef or not.

net_nfc_target_handle_s : The handle of the tag want to check ndef. int : The max size supported in tag. int : The real data size saved in tag. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_check_target_presence check_presence;

It checks the tag is exist in RF range.

net_nfc_target_handle_s : The handle of tag to check presence. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_read_ndef read_ndef; It reads ndef data in tag.

net_nfc_target_handle_s : The handle of tag to read. data_s : The pointer value to save ndef data. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_write_ndef write_ndef; It writes the data to the tag.

net_nfc_target_handle_s: The handle of tag to write. data_s : The data to write. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_make_read_only_ndef make_read_only_ndef;

It makes the tag to read only tag.

net_nfc_target_handle_s: The handle of tag to make. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_transceive transceive; It sends/receives the low command to the Tag/target.

net_nfc_target_handle_s: The handle of tag/target to transceive. net_nfc_transceive_info_s: The pointer value included command/data to send and data to receive. data_s : The pointer value to send the information of context. net_nfc_error_e : When it fails, it returns error code.

Tizen Porting Guide


Page 139 of 143

net_nfc_oem_controller_format_ndef format_ndef; It formats the tag.

net_nfc_target_handle_s: The handle of the tag to format. data_s : The key value to send the tag for formatting. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_exception_handler exception_handler;

When nfc-manager faces the unwanted exception, It tries to deinit and init the stack. Then it tries to unregister and register callback function.

none

net_nfc_oem_controller_is_ready is_ready; It checks the status of the nfc stack.


net_nfc_oem_controller_llcp_config config_llcp; It sets the llcp configuration(miu, lto, wks, option).

net_nfc_target_handle_s: The handle of the target to check llcp. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_llcp_check_llcp check_llcp_status;

It sets the llcp configuration(miu, lto, wks, option).

net_nfc_target_handle_s: The handle of the target to check llcp. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_llcp_activate_llcp activate_llcp;

It activates to llcp function.

net_nfc_target_handle_s: The handle of the target to activate. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_llcp_create_socket create_llcp_socket;

It creates to llcp socket

net_nfc_llcp_socket_t: The pointer value to receive the socket’s information. net_nfc_socket_type_e socketType : The type of socket to create. uint16_t miu : The miu value. uint8_t rw : The rw value. net_nfc_error_e : When it fails, it returns error code. void: The value to control the context.(It’s possible to set null)

net_nfc_oem_controller_llcp_bind bind_llcp_socket; It binds the socket.

net_nfc_llcp_socket_t socket : The information about the socket to bind. uint8_t service_access_point : The information of access point to bind. net_nfc_error_e : When it fails, it returns error code.

Tizen Porting Guide


Page 140 of 143

net_nfc_oem_controller_llcp_listen listen_llcp_socket; It makes the socket to listen.

net_nfc_target_handle_s: The handle of the target. uint8_t : The service name to listen. net_nfc_llcp_socket_t socket : The information of socket. net_nfc_error_e : When it fails, it returns error code. void: The value to control the context.(It’s possible to set null)

net_nfc_oem_controller_llcp_accept accept_llcp_socket;

It accepts the connect request in listen status.

net_nfc_llcp_socket_t socket : Socket’s information to accept. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_llcp_connect_by_url connect_llcp_by_url;

It tries to connect the server with service name.

net_nfc_target_handle_s: The handle of the target to connect. net_nfc_llcp_socket_t socket : Socket information to connect. uint8_t : service name to connect. net_nfc_error_e : When it fails, it returns error code. void: The value to control the context. (It’s possible to set null)

net_nfc_oem_controller_llcp_connect connect_llcp;

It tries to connect to the server with access point(port number).

net_nfc_target_handle_s: The handle of target. net_nfc_llcp_socket_t socket : The information of socket. uint8_t service_access_point : access point number net_nfc_error_e : When it fails, it returns error code. void: The value to control the context.(It’s possible to set null)

net_nfc_oem_controller_llcp_disconnect disconnect_llcp;

It disconnect llcp link.

net_nfc_target_handle_s: Socket information to disconnectnet_nfc_llcp_socket_t socket : The information of socket to disconnect. net_nfc_error_e : When it fails, it returns error code. void: The value to control the context.(It’s possible to set null)

net_nfc_oem_controller_llcp_socket_close close_llcp_socket;

It closes the llcp socket.

net_nfc_llcp_socket_t socket : Socket information to close. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_llcp_recv recv_llcp; It receives the data using llcp link.

net_nfc_target_handle_s: The handle of target to receive. net_nfc_llcp_socket_t socket : Socket information to receive. data_s : The pointer value to receive the data.

Tizen Porting Guide


Page 141 of 143

net_nfc_error_e : When it fails, it returns error code. void: The value to control the context.(It’s possible to set null)

net_nfc_oem_controller_llcp_send send_llcp; It sends the data using llcp link.

net_nfc_target_handle_s: The handle of target to send. net_nfc_llcp_socket_t socket : The information of socket to send. data_s : The data to send. net_nfc_error_e : When it fails, it returns error code. void: The value to control the context. (It’s possible to set null)

net_nfc_oem_controller_llcp_recv_from recv_from_llcp;

It rejects the connect request from client socket.

net_nfc_target_handle_s: The handle of target to reject. net_nfc_llcp_socket_t socket : The information of socket to reject. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_llcp_send_to send_to_llcp; It sends the data using service access point.

net_nfc_target_handle_s: The handle of peer target. net_nfc_llcp_socket_t socket : The information of socket. data_s : The data to send. uint8_t service_access_point : service access point to send. net_nfc_error_e : When it fails, it returns error code. void: The value to control the context. (It’s possible to set null)

net_nfc_oem_controller_llcp_reject reject_llcp; It rejects the connect request from client socket.

net_nfc_target_handle_s: The handle of target to reject. net_nfc_llcp_socket_t socket : The information of socket to reject. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_llcp_get_remote_config get_remote_config;

It gets llcp socket config information of peer device’s.

net_nfc_target_handle_s: The handle of peer target. net_nfc_llcp_config_info_s: The pointer value to get config information of peer device's llcp socket. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_llcp_get_remote_socket_info get_remote_socket_info;

It gets llcp socket information of peer device’s.

net_nfc_target_handle_s: The handle of peer target. net_nfc_llcp_socket_t socket : The information of llcp socket. net_nfc_llcp_socket_option_s : The pointer value to save the

Tizen Porting Guide


Page 142 of 143

information of remote socket. net_nfc_error_e : When it fails, it returns error code.

net_nfc_oem_controller_sim_test sim_test; It tests SWP link with SIM and NFC chipset.


net_nfc_oem_controller_test_mode_on test_mode_on;

It changes The nfc chipto test mode. (test mode is exist only NXP case. If there are none, it doesn’t need to implemented.)


net_nfc_oem_controller_test_mode_off test_mode_off;

It changes the status of nfc chip from test mode to normal mode. ( Test mode is exist only NXP case. If there are none, It doesn’t need to implemented.)


net_nfc_oem_controller_support_nfc support_nfc It check each chip’s device file.

NET_NFC_NOT_SUPPORTED : If it can’t find the device file, it return NET_NFC_NOT_SUPPORTED

Tizen porting guide_2.0.beta_1025

Education

Transcript of Tizen porting guide_2.0.beta_1025