--- a/Symbian3/PDK/Source/GUID-667C0481-2DEF-4618-9AA5-8DF528082061.dita Fri Jul 02 12:51:36 2010 +0100
+++ b/Symbian3/PDK/Source/GUID-667C0481-2DEF-4618-9AA5-8DF528082061.dita Fri Jul 16 17:23:46 2010 +0100
@@ -9,108 +9,115 @@
-->
<!DOCTYPE concept
PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept id="GUID-667C0481-2DEF-4618-9AA5-8DF528082061" xml:lang="en"><title>Accessory
-Services Overview</title><shortdesc>Accessory Services abstract accessory-related services for platform
-and SDK clients and provides accessory-related APIs for adaptation (audio
-and display) and accessory plug-ins.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
-<section id="GUID-6C29F2CD-6FBE-4805-957A-CB08163DFC00"><title>Purpose</title><p>Accessory Services is a group of components
-that support APIs for platform clients to retrieve accessory connection status
-information, and device and services type information. It also provides adaptation
+<concept id="GUID-667C0481-2DEF-4618-9AA5-8DF528082061" xml:lang="en"><title>Accessory Services Overview</title><shortdesc>Accessory Services abstract accessory-related services
+for platform and SDK clients and provides accessory-related APIs for
+adaptation (audio and display) and accessory plug-ins.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<section id="GUID-6C29F2CD-6FBE-4805-957A-CB08163DFC00"><title>Purpose</title><p>Accessory Services is a group of components that support APIs
+for platform clients to retrieve accessory connection status information,
+and device and services type information. It also provides adaptation
APIs for the addition of new Accessory Services plug-in components. </p></section>
-<section id="GUID-9236506F-077D-4AB1-AE4C-9CE391F42F98"><title>Architecture</title><p>The architecture of Accessory Services
-revolves around the Accessory and the Remote Control Framework. Accessory
-Framework provides platform clients with access to the accessory functionality
-on the device, while abstracting away accessory, hardware, bearer and protocol-specific
-details from the software layers. Accessory Framework also provides accessory
-policy and adaptation APIs for the addition of new Accessory Framework plug-in
-components (if required). The Remote Control Framework provides APIs required
-to send and receive remote control commands to/from an accessory connected
-to a phone.</p><p>The core of the Accessory Framework is the Accessory Server.
-Accessory Server has a central role in accessory-related connection/disconnection
-handling on the Symbian platform. The Accessory Framework depends on the concepts,
-such as Generic ID, Accessory Policy, Accessory Handlers and Accessory Mode.
-These concepts are described in the following section.</p><p>Remote Control
-Framework exposes the Remote Control Server using the Remote Control Core
-APIs. The remote control commands are understood by the Key Event Converter
-and passed on to the Target Selector Plug-in (TSP) Controller by the Remote
-Control Framework. Then TSP decides which application must handle this request
-and passes that information to the Remote Control Server. Finally, the request
-is handled by that application. For more information about Remote Control
-concepts, see the <b>Remote Control Framework</b> section.</p><p>The following
-figure illustrates the architecture of Accessory Services:</p><fig id="GUID-EF39A7CD-BA15-4F2D-96C6-C54672226E98">
+<section id="GUID-9236506F-077D-4AB1-AE4C-9CE391F42F98"><title>Architecture</title><p>The architecture of Accessory Services revolves around the Accessory
+and the Remote Control Framework. Accessory Framework provides platform
+clients with access to the accessory functionality on the device,
+while abstracting away accessory, hardware, bearer and protocol-specific
+details from the software layers. Accessory Framework also provides
+accessory policy and adaptation APIs for the addition of new Accessory
+Framework plug-in components (if required). The Remote Control Framework
+provides APIs required to send and receive remote control commands
+to/from an accessory connected to a phone.</p><p>The core of the Accessory
+Framework is the Accessory Server. Accessory Server has a central
+role in accessory-related connection/disconnection handling on the
+Symbian platform. The Accessory Framework depends on the concepts,
+such as Generic ID, Accessory Policy, Accessory Handlers and Accessory
+Mode. These concepts are described in the following section.</p><p>Remote Control Framework exposes the Remote Control Server using
+the Remote Control Core APIs. The remote control commands are understood
+by the Key Event Converter and passed on to the Target Selector Plug-in
+(TSP) Controller by the Remote Control Framework. Then TSP decides
+which application must handle this request and passes that information
+to the Remote Control Server. Finally, the request is handled by that
+application. For more information about Remote Control concepts, see
+the <b>Remote Control Framework</b> section.</p><p>The following figure
+illustrates the architecture of Accessory Services:</p><fig id="GUID-EF39A7CD-BA15-4F2D-96C6-C54672226E98">
<title>Accessory Services Architecture</title>
-<image href="GUID-5AE741A2-68C5-4219-8F2A-ECE0A819FCAA_d0e153742_href.jpg" scale="150" placement="inline"/>
+<image href="GUID-5AE741A2-68C5-4219-8F2A-ECE0A819FCAA_d0e159843_href.jpg" scale="150" placement="inline">
+</image>
</fig></section>
-<section id="GUID-7AB78BEA-315A-4CC0-B5B6-A7A28568F2B2"><title>Description</title><p>This section describes the key concepts
-associated with Accessory Services.</p><ul>
-<li><p><b>Generic ID</b>: Generic ID provides the means to describe, detect,
-connect, and control an enhancement without a need to use hardware or provider-specific
-definitions. Thus Generic ID must be a native concept for any accessory-related
-platform software. For the platform purposes, Generic ID must be defined so
-that it covers all the enhancement device types, bearers, protocols, and accessory
-feature profiles that the platform supports and for which information is needed.</p> </li>
-<li><p><b>Accessory Policy:</b> Accessory Policy provides the Generic ID data
-type for identifying an accessory on the basis of its features, instead of
-an accessory-specific ID. Accessory Server uses Accessory Policy through the
-Accessory Policy API to get information about the connected accessories. A
-connected accessory is identified using an assigned Generic ID, which is a
-data structure that describes the relevant physical and logical features of
-the accessory.</p> </li>
-<li><p><b>Accessory Mode:</b> Accessory Mode describes the accessory connection
-status of the devices connected to a phone and indicates whether the audio
-is routed into the accessory or not. Accessory Mode typically affects the
-vibra state, lights state, texts, some UI icons and menu items. </p><p><b>Note:</b> Accessory
-Mode is a single-valued state, unlike the accessory connection status. Some
-supported Accessory Modes include hand portable, wired headset, wireless headset,
-wired car kit, wireless car kit, headphones, text device, music stand and
+<section id="GUID-7AB78BEA-315A-4CC0-B5B6-A7A28568F2B2"><title>Description</title><p>This section describes the key concepts associated with Accessory
+Services.</p><ul>
+<li><p><b>Generic ID</b>: Generic ID provides the means to describe,
+detect, connect, and control an enhancement without a need to use
+hardware or provider-specific definitions. Thus Generic ID must be
+a native concept for any accessory-related platform software. For
+the platform purposes, Generic ID must be defined so that it covers
+all the enhancement device types, bearers, protocols, and accessory
+feature profiles that the platform supports and for which information
+is needed.</p> </li>
+<li><p><b>Accessory Policy:</b> Accessory Policy provides the Generic
+ID data type for identifying an accessory on the basis of its features,
+instead of an accessory-specific ID. Accessory Server uses Accessory
+Policy through the Accessory Policy API to get information about the
+connected accessories. A connected accessory is identified using an
+assigned Generic ID, which is a data structure that describes the
+relevant physical and logical features of the accessory.</p> </li>
+<li><p><b>Accessory Mode:</b> Accessory Mode describes the accessory
+connection status of the devices connected to a phone and indicates
+whether the audio is routed into the accessory or not. Accessory Mode
+typically affects the vibra state, lights state, texts, some UI icons
+and menu items. </p><p><b>Note:</b> Accessory Mode is a single-valued
+state, unlike the accessory connection status. Some supported Accessory
+Modes include hand portable, wired headset, wireless headset, wired
+car kit, wireless car kit, headphones, text device, music stand and
TV-out.</p> </li>
-<li><p><b>Accessory Handlers:</b> Accessory Handlers (ASYs) form the Accessory
-Framework adaptation layer. Accessory Server hosts multiple ASYs. For example,
-wired ASY, bluetooth ASY, plugged display ASY and so on. ASYs can be understood
-as an accessory adaptation layer between the Accessory Framework and any other
-Symbian platform or hardware-related software on the phone. Typical
-task of an ASY is accessory detection (registering for hardware indications)
-and providing the capabilities of the accessories to the Accessory framework.</p> </li>
-<li><p><b>Controller:</b> Controller is a device that sends a control message
-or command to a target device and is ready to capture responses.</p> </li>
-<li><p><b>Target:</b> Target is a device that accepts the control message
-or command from the controller, invokes necessary procedures and sends out
-responses to controller. </p> </li>
-<li><p><b>Bearer:</b> The bearer is a carrier that acts like a vehicle of
-transmission for remote control messages. The bearer here is an ECom plug-in
-to the Remote Control Server.</p> </li>
+<li><p><b>Accessory Handlers:</b> Accessory Handlers (ASYs) form the
+Accessory Framework adaptation layer. Accessory Server hosts multiple
+ASYs. For example, wired ASY, bluetooth ASY, plugged display ASY and
+so on. ASYs can be understood as an accessory adaptation layer between
+the Accessory Framework and any other Symbian platform or hardware-related
+software on the phone. Typical task of an ASY is accessory detection
+(registering for hardware indications) and providing the capabilities
+of the accessories to the Accessory framework.</p> </li>
+<li><p><b>Controller:</b> Controller is a device that sends a control
+message or command to a target device and is ready to capture responses.</p> </li>
+<li><p><b>Target:</b> Target is a device that accepts the control
+message or command from the controller, invokes necessary procedures
+and sends out responses to controller. </p> </li>
+<li><p><b>Bearer:</b> The bearer is a carrier that acts like a vehicle
+of transmission for remote control messages. The bearer here is an
+ECom plug-in to the Remote Control Server.</p> </li>
</ul><p/></section>
-<section id="GUID-93D60E05-F086-46F4-A0A6-2B8227BBABED"><title>Components</title><p>Accessory Services consists of the following
-components: </p><ul>
-<li><p><b>Accessory Monitor:</b> Provides APIs to retrieve information about
-the connected accessories, such as a headset and car kit. </p></li>
-<li><p><b>Accessory Remote Control:</b> Provides APIs for clients to communicate
-with remote targets in a terminal and remote targets outside a terminal.</p> </li>
-<li><p><b>Accessory Server:</b> This is a core component that exposes accessory-related
-client and adaptation APIs through the Accessory Framework. The Accessory
-Framework provides APIs to query accessory-related information, adjust accessory-related
-user settings and to request control for accessory-related functions. </p> </li>
-<li><p><b>Headset Status API:</b> Provides APIs for checking the headset status.
-For example, headset status change notifications.</p> </li>
-<li><p><b>Target Selector Plug-in (TSP) Client Mapper:</b> Provides APIs to
-create mappings between remote control clients.</p> </li>
-<li><p><b>Plugged Display:</b> Plugged Display component is an ASY that enables
-High-Definition Multimedia Interface (HDMI) and TV-out support. For more information
-about HDMI, see <xref href="http://en.wikipedia.org/wiki/HDMI.dita">Wikipedia</xref>.</p> </li>
-<li><p><b>Remote Control Framework:</b> Provides APIs needed to send and receive
-remote control commands to/from a Bluetooth enabled device.</p> </li>
+<section id="GUID-93D60E05-F086-46F4-A0A6-2B8227BBABED"><title>Components</title><p>Accessory Services consists of the following components: </p><ul>
+<li><p><b>Accessory Monitor:</b> Provides APIs to retrieve information
+about the connected accessories, such as a headset and car kit. </p></li>
+<li><p><b>Accessory Remote Control:</b> Provides APIs for clients
+to communicate with remote targets in a terminal and remote targets
+outside a terminal.</p> </li>
+<li><p><b>Accessory Server:</b> This is a core component that exposes
+accessory-related client and adaptation APIs through the Accessory
+Framework. The Accessory Framework provides APIs to query accessory-related
+information, adjust accessory-related user settings and to request
+control for accessory-related functions. </p> </li>
+<li><p><b>Headset Status API:</b> Provides APIs for checking the headset
+status. For example, headset status change notifications.</p> </li>
+<li><p><b>Target Selector Plug-in (TSP) Client Mapper:</b> Provides
+APIs to create mappings between remote control clients.</p> </li>
+<li><p><b>Plugged Display:</b> Plugged Display component is an ASY
+that enables High-Definition Multimedia Interface (HDMI) and TV-out
+support. For more information about HDMI, see <xref href="http://en.wikipedia.org/wiki/HDMI" scope="external">Wikipedia</xref>.</p> </li>
+<li><p><b>Remote Control Framework:</b> Provides APIs needed to send
+and receive remote control commands to/from a Bluetooth enabled device.</p> </li>
</ul></section>
-<section id="GUID-18563CE6-A880-48E4-96BA-3B50CA8A373F"><title>Using Accessory Services</title><p>You can use features provided
-by Accessory Services to perform the following tasks:</p><ul>
-<li><p>Retrieve accessory mode, connection status, accessory device and service
-type information.</p></li>
+<section id="GUID-18563CE6-A880-48E4-96BA-3B50CA8A373F"><title>Using
+Accessory Services</title><p>You can use features provided by Accessory
+Services to perform the following tasks:</p><ul>
+<li><p>Retrieve accessory mode, connection status, accessory device
+and service type information.</p></li>
<li><p>Retrieve accessory control and connection-related functionality.</p></li>
-<li><p>Request for a protocol-specific connection handle for accessory audio
-control.</p></li>
+<li><p>Request for a protocol-specific connection handle for accessory
+audio control.</p></li>
<li><p>Handle accessory-related key events.</p></li>
<li><p>Monitor accessories connected to a phone.</p></li>
-<li><p>Identify accessories connected based on its features, using Generic
-IDs.</p></li>
+<li><p>Identify accessories connected based on its features, using
+Generic IDs.</p></li>
<li><p>Configure accessory-related settings.</p></li>
<li><p> Retrieve headset connection status.</p></li>
<li><p>Create mappings between remote control clients.</p></li>