This tutorial explains how to create acomposite nodein a Fuchsia system for a composite driver.

Acomposite node specification is a mechanism usedto describe a composite node in a Fuchsia system. Acomposite node is a node that has multiple parent nodes.Acomposite driver is a driver that binds to acomposite node and uses resources managed by multiple parent nodes in thesystem.

To create a composite node for a composite driver, you need to perform thefollowing tasks:

• Create a composite node specification
• Write a composite driver's bind rules (to match the composite nodespecification)

The steps are:

1. Prepare parent specifications.
2. Create a composite node specification.
3. Define bind rules for the composite driver.

For troubleshooting issues, seeDebugging composite driver issues.

Understanding composite node concepts

Acomposite node is a node with multiple parents. A compositenode acts as a central point of contact for multiple parent nodes, enabling accessto the resources managed by these parent nodes. When a driver is bound toa composite node, the composite driver can access the combined resources providedby the parent drivers.

Figure 1. A composite node has access to multiple parent nodes and theirresources.

Before you begin, familiarize yourself with the development concepts below:

• Key background concepts
• What is a composite node specification?
• How does the driver framework create a composite node in a Fuchsia system?
• How does the driver framework match a composite driver to a composite node?
• How do bind rules work?

Key background concepts

This tutorial assumes familiarity with the following concepts related toFuchsia drivers:

• Driver binding: The process of matching drivers to nodeswithin a Fuchsia system.
• Composite nodes: A node with multiple parent nodes,enabling access to multiple resources in a Fuchsia system.
• Driver framework (DFv2): A new framework that manages driversand nodes in Fuchsia.

What is a composite node specification?

Acomposite node specification is a mechanism forcreating a composite node. It describes the nodes that can serve as parent nodesto the composite node and an appropriate composite driver that can bind to thecomposite node.

Unlike a component manifest (.cml) and bind rules (.bind), a composite nodespecification isnot a file. It is an object that needs to be constructedand added (using theCompositeNodeManager protocol) by a driver (to be exact,by the driver's source code) loaded in a Fuchsia system.

Figure 2. A composite node specification is a collection of parentspecifications.

A composite node specification comprises a set of parent specifications, eachrepresenting the criteria of a parent node of the composite node. A set ofparent specifications serve the following purposes:

• Describe nodes that are parent nodes of this composite node.
• Provide properties for identifying a composite driver.

Each parent specification in a composite node specification contains thefollowing:

• Bind rules: The bind rules used to match this parent specification to anode in the topology.
• Properties: A part of the key-value pairs applied in the composite node'smatching process for finding a composite driver. (They follow the same formatasnode properties.)

How does the driver framework create a composite node in a Fuchsia system?

When a composite node specification is introducedto the system, the following events take place:

1. A composite node specification is added to the driver framework by a driverloaded in a Fuchsia system, which is typically aboard driver.

   

2. Thedriver manager asks thedriver index tosearch for a matching composite driver based on the composite node specification.

   A composite driver whose bind rules can satisfy all theproperties of theparent specifications in this composite node specification is matched. (SeeHow does the driver framework match a composite driver to a composite node?)

   

3. Once a composite driver is found, the driver manager asks the driver index tosearch for nodes in the system based on the composite node specification.

   Nodes whose node properties can satisfy thebind rules provided by theparent specifications in the composite node specification are matched. Eachmatching node becomes a parent node of the newly created composite node instep 4.

   

4. After all parent specifications have a match, the driver manager creates acomposite node using the matched nodes as parents and finally binds thecomposite driver (matched in step 2) to the newly created composite node.(The composite node provides the primary node and node names.)

   

How does the driver framework match a composite driver to a composite node?

A composite driver's matching process is done by applying the composite driver'sbind rules to theproperties provided by the parent specifications ina composite node specification. (Notice that this is different from applying theparent specifications' bind rules to match nodes in the topology.)

For example, these bind rules are from a composite driver:

composite focaltech_touch;using fuchsia.gpio;using fuchsia.hardware.i2c;using fuchsia.i2c;primary node "i2c" {  fuchsia.hardware.i2c.Service == fuchsia.hardware.i2c.Service.ZirconTransport;  fuchsia.BIND_I2C_ADDRESS == fuchsia.i2c.BIND_I2C_ADDRESS.FOCALTECH_TOUCH;}node "gpio-int" {  fuchsia.BIND_PROTOCOL == fuchsia.gpio.BIND_PROTOCOL.DEVICE;  fuchsia.gpio.FUNCTION == fuchsia.gpio.FUNCTION.TOUCH_INTERRUPT;}

Using these bind rules, a matching composite node specification requires aparent specification with properties that matchi2c and another parentspecification with properties that matchgpio-int.

A match between a composite driver and a composite node (specification) issuccessful if the following conditions are met:

• All parent specifications must match with a node in the composite driver'sbind rules.

• Allnon-optional nodes in the composite driver's bind rules must matchwith a parent specification.

  For example, these bind rules from a composite driver includes an optional node:

  composite virtio_input;using fuchsia.acpi;using fuchsia.hardware.pci;using fuchsia.pci;primary node "pci" {    fuchsia.hardware.pci.Service == fuchsia.hardware.pci.Service.ZirconTransport;    fuchsia.BIND_PCI_VID == fuchsia.pci.BIND_PCI_VID.VIRTIO;    fuchsia.BIND_PCI_DID == fuchsia.pci.BIND_PCI_DID.VIRTIO_DEV_TYPE_INPUT;}optional node "acpi" {    fuchsia.BIND_PROTOCOL == fuchsia.acpi.BIND_PROTOCOL.DEVICE;}

  (Source:virtio_input.bind)

Nodes do not need to be matched in the order listed in the composite driver'sbind rules.

However, matching cannot be ambiguous, that is:

• Each parent specification must correspond with only one node in the compositedriver's bind rules.
• Each node in the composite bind rules must match with at most one parentspecification. (Optional nodes may not match with any parent specifications.)

If an ambiguous case occurs, the driver manager will print a warning message inthe logs. (Currently, the match still happens, but it will be disallowed in thefuture. Seethis related ticket.)

Figure 3. Each parent specification's bind rules are used to find a parentnode of the composite node.

Figure 4. A composite driver's bind rules are matched against a compositenode's properties, which are collectively provided by parent specifications in acomposite node specification.

How do bind rules work?

The bind rules in a parent specification provide a list ofaccepted andrejected property values. For a node to satisfy the bind rules, its nodeproperties must contain all the accepted node property values and none of therejected ones.

For example, a parent specification can contain the following bind rules:

• Acceptfuchsia.BIND_PROTOCOL values15 and17.
• Rejectfuchsia.BIND_PLATFORM_DEV_VID valuesIntel.

Using these bind rules, a node can be matched only if it contains a value of15 or17 for thefuchsia.BIND_PROTOCOL property and doesn't have theIntel value for thefuchsia.BIND_PLATFORM_DEV_VID property.

1. Prepare parent specifications

You first need to prepare the parent specifications that will make up acomposite node specification.

To prepare parent specifications, the steps are:

1. Define bind rules in parent specifications.
2. Define properties in parent specifications.

1. Define bind rules in parent specifications

Bind rules are used to find and match nodes in the topology according to parentspecifications. A node's properties are evaluated against the bind rules in aparent specification. If they match, the node becomes a parent of a compositenode.

Process of writing bind rules

The process for writing bind rules for a composite node's parent nodes issimilar to the process described in theBind rules tutorial. To determine the bind rules,you first need to identify the properties of each parent node that you wantto bind to.

To view the properties of every node in the node topology, you can use thefollowingffx command:

ffxdriverlist-devices-v

This command prints entries similar to the following:

Name     : i2c-1-56Topo Path: sys/platform/i2c-0/aml-i2c/i2c/i2c-1-56Driver   : fuchsia-boot:///#driver/i2c.soFlags    : MUST_ISOLATE | BOUNDProto    : ZX_PROTOCOL_I2C (24)3 Properties[ 1/  3] : Key fuchsia.BIND_I2C_BUS_ID        Value 0x000001[ 2/  3] : Key fuchsia.BIND_I2C_ADDRESS       Value 0x000038[ 3/  3] : Key "fuchsia.hardware.i2c.Service" Value "fuchsia.hardware.i2c.Service.ZirconTransport"

The example entry above shows the following node properties for thei2c-1-56node:

• fuchsia.I2C_BUS_ID =0x000001undefined
• fuchsia.I2C_ADDRESS =0x000038
• fuchsia.hardware.i2c.Service =fuchsia.hardware.i2c.Service.ZirconTransport

To see which property values are acceptable, you can look up the bind librariesin the Fuchsia codebase (for example, in thesrc/devices/binddirectory). In this example, since the node is an I2C node, the property valuesare found in thefuchsia.i2c bind library as shown below:

extend uint fuchsia.BIND_I2C_BUS_ID {  I2C_A0_0 = 0,  I2C_2 = 1,  I2C_3 = 2,};extend uint fuchsia.BIND_I2C_ADDRESS {  BACKLIGHT = 0x2C,  ETH = 0x18,  FOCALTECH_TOUCH = 0x38,  AMBIENTLIGHT = 0x39,  AUDIO_CODEC = 0x48,  GOODIX_TOUCH = 0x5d,  TI_INA231_MLB = 0x49,  TI_INA231_SPEAKERS = 0x40,  TI_INA231_MLB_PROTO = 0x46,};

In addition to the bind libraries in the Fuchsia codebase, you can also generatebind libraries from FIDL libraries. In the example above, this is where theproperty for thefuchsia.hardware.i2c.Service key and its valuefuchsia.hardware.i2c.Service.ZirconTransport come from. (For more information,seeGenerated bind libraries.)

Using the property values found in the bind library, you can remap the nodeproperties as shown below:

• fuchsia.BIND_I2C_BUS_ID =fuchsia.i2c.BIND_I2C_BUS_ID.I2C_2
• fuchsia.BIND_I2C_ADDRESS =fuchsia.i2c.BIND_I2C_ADDRESS.FOCALTECH_TOUCH
• fuchsia.hardware.i2c.Service =fuchsia.hardware.i2c.Service.ZirconTransport

You can access these bind library values in your driver source code through itsgenerated libraries. (For more information, see theBind libraries codegen tutorial.)

The bind rules that match these properties are defined as shown below:

accept fuchsia.hardware.i2c.Service { fuchsia.hardware.i2c.Service.ZirconTransport }accept BIND_I2C_BUS_ID { fuchsia.i2c.BIND_I2C_BUS_ID.I2C_2 }accept BIND_I2C_ADDRESS { fuchsia.i2c.BIND_I2C_ADDRESS.FOCALTECH_TOUCH }

Defining bind rules in DFv1

In DFv1, composite node specifications are written using the DDKTL(Device Driver Kit Template Library). The functions to write the bind rules areincomposite-node-spec.h.

With the DDK library and bind libraries codegen values, we can write thefollowing:

const ddk::BindRule kI2cBindRules[] = {    ddk::MakeAcceptBindRule(bind_fuchsia_hardware_i2c::SERVICE,                            bind_fuchsia_hardware_i2c::SERVICE_ZIRCONTRANSPORT),    ddk::MakeAcceptBindRule(bind_fuchsia::I2C_BUS_ID,                            bind_fuchsia_i2c::BIND_I2C_BUS_ID_I2C_2),    ddk::MakeAcceptBindRule(bind_fuchsia::I2C_ADDRESS,                            bind_fuchsia_focaltech_platform::BIND_I2C_ADDRESS_TOUCH),};

Defining bind rules in DFv2

In DFv2, composite node specifications are defined by theCompositeNodeSpecprotocol fromcomposite_node_spec.fidl in thefuchsia.driver.framework FIDL library. Thecomposite_node_spec.h library in thesdk/lib/driver/component/cpp directory can be used to simplify defining thebind rules.

Using theCompositeNodeSpec library and bind libraries codegen values, we canwrite the following:

auto i2c_bind_rules = std::vector {    MakeAcceptBindRule(bind_fuchsia_hardware_i2c::SERVICE,                       bind_fuchsia_hardware_i2c::SERVICE_ZIRCONTRANSPORT),    MakeAcceptBindRule(bind_fuchsia::I2C_BUS_ID,                       bind_fuchsia_i2c::BIND_I2C_BUS_ID_I2C_2),    MakeAcceptBindRule(bind_fuchsia::I2C_ADDRESS,                       bind_fuchsia_focaltech_platform::BIND_I2C_ADDRESS_TOUCH),};

2. Define properties in parent specifications

In addition to defining the bind rules for nodes, in parent specifications, youneed to define the properties that will be used in finding a composite driver.

These properties are key-value pairs that are used to match a parentspecification to a composite driver's bind rules. They are the same thing asnode properties, following the same format. The property key can beinteger-based or string-based while the property value can be an integer,boolean, string or enum type.

Defining properties in DFv1

In DFv1, composite node specifications are written usingDDKTL and thefunctions to write the bind rules are incomposite-node-spec.h. You candefine properties using the DDK library and bind libraries codegen values asshown below:

const device_bind_prop_t kI2cProperties[] = {    ddk::MakeProperty(bind_fuchsia_hardware_i2c::SERVICE,                      bind_fuchsia_hardware_i2c::SERVICE_ZIRCONTRANSPORT),    ddk::MakeProperty(bind_fuchsia::I2C_ADDRESS,                      bind_fuchsia_focaltech_platform::BIND_I2C_ADDRESS_TOUCH),};

Defining properties in DFv2

In DFv2, composite node specifications are written forcomposite_node_spec.fidl in thefuchsia.driver.framework FIDL library. Thenode_add_args.h library in//sdk/lib/driver/component/cppcan be used to simplify defining properties. You can define properties using theCompositeNodeSpec library and bind libraries codegen values as shown below:

auto i2c_properties[] = std::vector {    ddk::MakeProperty(bind_fuchsia::I2C_ADDRESS,                      bind_fuchsia_focaltech_platform::BIND_I2C_ADDRESS_TOUCH),};

2. Create a composite node specification

Creating a composite node specification involves defining and adding a set ofparent specifications to the driver manager.

A composite node specification is added to the driver framework by a driverloaded in a Fuchsia system, which is typically a board driver. (For moreinformation on this process, seeHow does the driver framework create a composite node in a Fuchsia system?)

Adding a composite node specification in DFv1

In DFv1, a driver can add composite node specifications throughDDKTLwith theDdkAddCompositeNodeSpec() function.

The driver must first define aCompositeNodeSpec object in thecomposite-node-spec.h library. Using the examplebind rules and properties in the previous section, you can defineaCompositeNodeSpec object with an I2C parent specification as following:

const ddk::BindRule kI2cBindRules[] = {    ddk::MakeAcceptBindRule(bind_fuchsia_hardware_i2c::SERVICE,                            bind_fuchsia_hardware_i2c::SERVICE_ZIRCONTRANSPORT),    ddk::MakeAcceptBindRule(bind_fuchsia::I2C_BUS_ID,                            bind_fuchsia_i2c::BIND_I2C_BUS_ID_I2C_2),    ddk::MakeAcceptBindRule(bind_fuchsia::I2C_ADDRESS,                            bind_fuchsia_focaltech_platform::BIND_I2C_ADDRESS_TOUCH),};const device_bind_prop_t kI2cProperties[] = {    ddk::MakeProperty(bind_fuchsia_hardware_i2c::SERVICE,                      bind_fuchsia_hardware_i2c::SERVICE_ZIRCONTRANSPORT),    ddk::MakeProperty(bind_fuchsia::I2C_ADDRESS,                      bind_fuchsia_focaltech_platform::BIND_I2C_ADDRESS_TOUCH),};auto spec = ddk::CompositeNodeSpec(kI2cBindRules, kI2cProperties);

Any additional nodes can be added with theAddParentSpec() function. Forinstance, if we want to add a parent specification for a GPIO interpret pin, wecan write the following:

const ddk::BindRule kGpioInterruptRules[] = {    ddk::MakeAcceptBindRule(bind_fuchsia::PROTOCOL,                            bind_fuchsia_gpio::BIND_PROTOCOL_DEVICE),    ddk::MakeAcceptBindRule(bind_fuchsia::GPIO_PIN,                bind_fuchsia_amlogic_platform_s905d2::GPIOZ_PIN_ID_PIN_4),};const device_bind_prop_t kGpioInterruptProperties[] = {    ddk::MakeProperty(bind_fuchsia::PROTOCOL,                      bind_fuchsia_gpio::BIND_PROTOCOL_DEVICE),    ddk::MakeProperty(bind_fuchsia_gpio::FUNCTION,                      bind_fuchsia_gpio::FUNCTION_TOUCH_INTERRUPT)};desc.AddParentSpec(kGpioInterruptRules, kGpioInterruptProperties);

Once theCompositeNodeSpec object is ready, you can add it withDdkAddCompositeNodeSpec(), wherespec is an object containing the compositenode specification, for example:

autostatus=DdkAddCompositeNodeSpec("ft3x27_touch",spec);

Since aCompositeNodeSpec object follows the builder pattern, this can besimplified to:

autostatus=DdkAddCompositeNodeSpec("ft3x27_touch",ddk::CompositeNodeSpec(kFocaltechI2cRules,kFocaltechI2cProperties).AddParentSpec(kGpioInterruptRules,kGpioInterruptProperties).set_metadata(metadata);

Adding a composite node specification in DFv2

In DFv2, we use theCompositeNodeManager protocol from thefuchsia.driver.framework FIDL API to add a composite node specification:

@discoverableprotocolCompositeNodeManager{/// Add the given spec to the driver manager.AddSpec(CompositeNodeSpec)->()errorCompositeNodeSpecError;};

Adding a composite node specification to the platform bus

If the composite node needs a parent from a node on the platform bus, then theboard driver can add the composite node specification through theplatform_bus.fidl API. This applies to both DFv1 and DFv2.

/// Adds a composite node specification to the bus. This will add a platform device specified/// by |node| and insert a node into the composite node specification that matches the device.AddCompositeNodeSpec(struct{nodeNode;specfuchsia.driver.framework.CompositeNodeSpec;})->()errorzx.Status;

The platform bus API uses the sameCompositeNodeSpec struct defined incomposite_node_spec.fidl.

For example, say we defined the following composite node specification:

std::vector<fuchsia_driver_framework::BindRule>bind_rules={fdf::MakeAcceptBindRule(bind_fuchsia_hardware_i2c::SERVICE,bind_fuchsia_hardware_i2c::SERVICE_ZIRCONTRANSPORT),fdf::MakeAcceptBindRule(bind_fuchsia::I2C_ADDRESS,bind_fuchsia_i2c::BIND_I2C_ADDRESS_BACKLIGHT),};std::vector<fuchsia_driver_frameowork::Node>properties={fdf::MakeProperty(bind_fuchsia_hardware_i2c::SERVICE,bind_fuchsia_hardware_i2c::SERVICE_ZIRCONTRANSPORT),fdf::MakeProperty(bind_fuchsia::I2C_ADDRESS,bind_fuchsia_i2c::BIND_I2C_ADDRESS_BACKLIGHT),};std::vector<fuchsia_driver_framework::ParentSpec>spec={{{bind_rules,properties}}};

(For more details on the library used in the example above, seeDefining properties in DFv2 andDefining bind rules in DFv2.)

Once the composite node specification is defined, the board driver can connectto the platform bus through thePlatformBus FIDL protocol and use the clientend to callAddCompositeNodeSpec().

TheAddCompositeNodeSpec() call inserts a parent specification for a platformdevice (created from the data in the node field) into the given composite nodespecification and adds this modified composite node specification into thedriver framework. It then creates and adds the platform device, for example:

fpbus::Nodedev;dev.name()="backlight";dev.vid()=PDEV_VID_TI;// 0x10dev.pid()=PDEV_PID_TI_LP8556;// 0x01dev.did()=PDEV_DID_TI_BACKLIGHT;// 0x01autoendpoints=fdf::CreateEndpoints<fuchsia_hardware_platform_bus::PlatformBus>();if(endpoints.is_error()){returnendpoints.error_value();}fdf::WireSyncClient<fuchsia_hardware_platform_bus::PlatformBus>pbus=endpoints->client;autoresult=pbus.buffer(arena)->AddCompositeNodeSpec(fidl::ToWire(fidl_arena,dev),fidl::ToWire(fidl_arena,spec),false);if(!result.ok()){FDF_LOG(ERROR,"AddCompositeNodeSpec request failed: %s",result.FormatDescription().data());returnresult.status();}

AfterAddCompositeNodeSpec() is called, the following composite nodespecification is added to the driver framework:

Name:backlightDriver:fuchsia-boot:///#meta/ti-lp8556.cmNodes:2Node0:None3BindRules[1/3]:Accept"fuchsia.BIND_PLATFORM_DEV_VID"{0x000010}[2/3]:Accept"fuchsia.BIND_PLATFORM_DEV_PID"{0x000001}[2/3]:Accept"fuchsia.BIND_PLATFORM_DEV_DID"{0x000001}3Properties[1/3]:Key"fuchsia.BIND_PLATFORM_DEV_VID"Value0x000010[2/3]:Key"fuchsia.BIND_PLATFORM_DEV_PID"Value0x000001[3/3]:Key"fuchsia.BIND_PLATFORM_DEV_DID"Value0x000001Node1:None2BindRules[1/2]:Accept"fuchsia.hardware.i2c.Service"{"fuchsia.hardware.i2c.Service.ZirconTransport"}[2/2]:Accept"fuchsia.BIND_I2C_ADDRESS"{0x00002C}2Properties[1/2]:Key"fuchsia.hardware.i2c.Service"Value"fuchsia.hardware.i2c.Service.ZirconTransport"[2/2]:Key"fuchsia.BIND_I2C_ADDRESS"Value0x00002C}

The first node (Node 0) shown in the composite node specification exampleabove matches the platform device created fromAddCompositeNodeSpec(). Thefirst parent specification is inserted byAddCompositeSpec() and is targetedfor matching the platform device, which contains bind rules and properties fromtheVID, PID, andDID provided infpbus::Node dev. The remaining parentspecifications are from the passed-in composite node specification.

3. Define bind rules for the composite driver

Once a composite node specification is defined, you can start writing bind rulesfor your composite driver, which will be matched to the composite node createdaccording to the composite node specification.

The process of writing bind rules for a composite driver is similar to writingbind rules for a driver.

The examples in the previous sections include the following properties in itsparent specifications:

i2cparentspecificationproperties{fuchsia.hardware.i2c.Service:fuchsia.hardware.i2c.Service.ZirconTransport,fuchsia.BIND_I2C_ADDRESS:fuchsia.focaltech.platform.BIND_I2C_ADDRESS_TOUCH,}gpio-interruptparentspecificationproperties{fuchsia.BIND_PROTOCOL:fuchsia.gpio.BIND_PROTOCOL_DEVICE,fuchsia.gpio.FUNCTION:fuchsia.gpio.FUNCTION.TOUCH_INTERRUPT,}

If you want to bind to a composite node specification with the properties above,you can write the following composite bind rules to match the target parentspecifications:

compositefocaltech_touch;usingfuchsia.gpio;usingfuchsia.hardware.i2c;usingfuchsia.i2c;primarynode"i2c"{fuchsia.hardware.i2c.Service==fuchsia.hardware.i2c.Service.ZirconTransport;fuchsia.BIND_I2C_ADDRESS==fuchsia.i2c.BIND_I2C_ADDRESS.FOCALTECH_TOUCH;}node"gpio-int"{fuchsia.BIND_PROTOCOL==fuchsia.gpio.BIND_PROTOCOL.DEVICE;fuchsia.gpio.FUNCTION==fuchsia.gpio.FUNCTION.TOUCH_INTERRUPT;}

Appendix

Debugging composite driver issues

To verify that a composite node is successfully created and is attempting tobind a composite driver, you can examine the logs and look for the statementsimilar to the following line:

Binding driver fuchsia-boot:///#meta/focaltech.cm

To verify that the composite node specification is added successfully andmatched to a composite driver, run the following command:

ffxdriverlist-composite-node-specs-v

This command prints output similar to the following:

Name:ft3x27_touchDriver:fuchsia-boot:///#meta/focaltech.cmNodes:2Node0:"i2c"(Primary)3BindRules[1/3]:Accept"fuchsia.hardware.i2c.Service"{"fuchsia.hardware.i2c.Service.ZirconTransport"}[2/3]:Accept"fuchsia.BIND_I2C_BUS_ID"{0x000001}[3/3]:Accept"fuchsia.BIND_I2C_ADDRESS"{0x000038}2Properties[1/2]:Key"fuchsia.hardware.i2c.Service"Value"fuchsia.hardware.i2c.Service.ZirconTransport"[2/2]:Key"fuchsia.BIND_I2C_ADDRESS"Value0x000038Node1:"gpio-int"2BindRules[1/2]:Accept"fuchsia.BIND_PROTOCOL"{0x000014}[2/2]:Accept"fuchsia.BIND_GPIO_PIN"{0x000004}2Properties[1/2]:Key"fuchsia.BIND_PROTOCOL"Value0x000014[2/2]:Key"fuchsia.gpio.FUNCTION"Value"fuchsia.gpio.FUNCTION.TOUCH_INTERRUPT"

If there is no matching composite driver for the composite node specification,the command will print output similar to the following:

Name:focaltech_touchDriver:NoneNodes:2Node0:None3BindRules[1/3]:Accept"fuchsia.hardware.i2c.Service"{"fuchsia.hardware.i2c.Service.ZirconTransport"}[2/3]:Accept"fuchsia.BIND_I2C_BUS_ID"{0x000001}[3/3]:Accept"fuchsia.BIND_I2C_ADDRESS"{0x000038}1Properties[1/2]:Key"fuchsia.hardware.i2c.Service"Value"fuchsia.hardware.i2c.Service.ZirconTransport"[2/2]:Key"fuchsia.BIND_I2C_ADDRESS"Value0x000038Node1:None2BindRules[1/2]:Accept"fuchsia.BIND_PROTOCOL"{0x000014}[2/2]:Accept"fuchsia.BIND_GPIO_PIN"{0x000004}2Properties[1/2]:Key"fuchsia.BIND_PROTOCOL"Value0x000014[2/2]:Key"fuchsia.gpio.FUNCTION"Value"fuchsia.gpio.FUNCTION.TOUCH_INTERRUPT

For more information on theffx driver command, seeView driver information.