Input Framework

Touchscreen display appears to the system as two separate devices (display over HDMI/etc. interface, and touch controller over USB interface). Teams devices setup can have more than one display connected to FoR device. In the case of baseline AOSP, correct mapping may not always be established.

_{Runtime Touch Display Association}

The current design in Android 12/13 has limited support for dynamic association of touch controllers with displays. Android documentation states that dynamic associations are not yet enabled. It supports static mapping via 2 approaches:

• Specifying input ports for USB and displays in /vendor/etc/input-port-associations.xml file (e.g. port display="0" input="usb-xhci-hcd.0.auto-1.1/input0").
• Specifying display ID in input device configuration files (*.dc) that are located by USB vendor, product (and optionally version) ID or by input device name in a few locations. IDC files map input device to a display unique ID (64-bit value constructed from display EDID in higher 32-bits and port information in lower 32-bits).

MDEP introduces RIDA (Runtime I/O Device Association) design intended to solve this problem for Teams devices. The design is centered around a Microsoft TouchMapper privileged application that monitors boot time configuration, arrival/removal of displays and touch controllers, creates UI to get user input, and interfaces with InputFlinger/Surface Flinger via Android Framework. It uses gesture mapping and associates certain distinct gestures with each display.

_{MDEP Input Stack Software Architecture}

Implementation of this design in MDEP introduces modifications in the InputDevice public API and InputFlinger service.

When RIDA decides that there are enough cables plugged in to make the HDMI-USB mapping non-trivial, it will launch a UI popup that will come to the forefront of the device and ask the user to interact with it:

This is RIDA asking for the user to create the HDMI-USB mapping by double tapping on the current display. While this element is active, the second monitor will be grayed out. Additionally, it is possible that the current display does not support touch. In this case, the user would wait 30 seconds for the popup to switch to the secondary display which will be touch-enabled. After 30 more seconds, the popup will be dismissed entirely and a random mapping will be chosen for the system.

After RIDA completes the mapping process (either by user double-tap, or dismissal), RIDA will leave a system message that instructs the user on how to manually remap the devices. Leaving a message like this will help the user recover after mistakenly mapping the devices incorrectly:

There are two ways that RIDA triggers: automatic and manual.

Manual RIDA Trigger

There is an option in settings to manually trigger the remapping process. Currently, this option sits under Settings -> System -> Multi-Display Touch. Accessing this setting requires Admin privileges.

Automatic RIDA Trigger

When properly included in the build, RIDA is set up to trigger automatically when there are two monitors and at least one of those monitors is touch-enabled. RIDA can trigger when this condition is met on bootup or when a device is connected to the system. Once user completes the mapping process, RIDA will cache current mappings and will not prompt to remap unless devices change (new device attached, or display/touch controller is reconnected to a different HDMI/USB port)