The features described below were introduced in UPDD 7.1.220
In some cases it is desirable to have a single application span across multiple physical touch monitors. The monitors can be connected to the systems configured as one large virtual monitor, such as in a nvidia mosaic configuration, or multiple individual monitors. Touch processing multiple touch monitors as one virtual monitor can been handled via the UPDD touch driver using the segmentation setting.
However, in the tradition multi-monitor setup, unless the application is receiving touch data directly into the application, via some form of API (UPDD, TUIO, native touch OS API), touches can only be used on one monitor at a time due to the HID touch interface single user Windows limitation.
To overcome this limitation, you can enable certain features in the driver that allow simultaneous touches within an application that spans across multiple monitors as described below.
Single virtual monitor configurations - unified contact ids across controllers
merge_contact_ids is a global UPDD setting. When enabled, UPDD makes each touch contact's id unique across all connected controllers by remapping the existing contact id into one shared, 0-based id space. This remaps the contact id generated by the controller to ensure they are unique.
By default each controller numbers its own contacts independently, so two controllers can both report contact "0", "1", … at once; an application (or the virtual HID) that receives contacts from more than one controller then sees colliding ids. With merge_contact_ids on, every live contact gets a distinct id, no matter which controller produced it.
- 0-based and recycled: an id is allocated (lowest free) when a contact goes down and released when it lifts, so ids stay compact
- Applies to every consumer of the contact id — the virtual HID, the unified pointer-injection interface, and UPDD-API clients — with no API change.
You can enable this setting via the UPDD command line utility, upddutils or via a UPDD API call:
Command
upddutils global set merge_contact_ids 1 :: enable
upddutils global set merge_contact_ids 0 :: disable
API
TBApiSetSetting(0, "merge_contact_ids", "1", false);
The setting merge_contact_ids.max_contacts can optionally be used to define an upper limit on the number of simultaneous merged ids (ids 0..max-1); default 256.
Because ids are allocated lowest-free, you normally don't need to set this. In particular the virtual HID (whose contact-id field holds 0–31) works at the default: with up to 32 simultaneous contacts the merged ids stay in range, and more than 32 exceeds the VHID's own capacity anyway. Set max_contacts only for a consumer that needs a specific upper limit
The merge_contact_ids setting can be used in two cases:
- A single application — or the virtual HID — receiving touches from several controllers (video walls, multi-station tables) that tracks contacts by id.
- Any integration needing globally-unique contact ids across controllers
Note
While enabled, the contact id no longer reflects a controller's raw per-device contact number — it carries the merged, cross-controller value. A consumer that specifically needs the raw per-device number should leave merge_contact_ids off
Multiple physical monitors configuration - unified pointer injection (Windows)
use_input_injection is a global UPDD setting (Windows only). When enabled, UPDD delivers touch and pen from every connected controller through a single, shared Windows synthetic pointer interface (the OS InjectSyntheticPointerInput API), created and driven by the UPDD Daemon in the interactive user session.
This replaces the default delivery path (the per-monitor UPDD virtual-HID kernel devices) with one unified "unary" interface:
- One synthetic touch device shared by all controllers (up to 256 simultaneous contacts)
- One synthetic pen device.
- A unified contact-id space across controllers, so two controllers that each report contact/stylus "0" do not collide on the way to Windows. If a new contact arrives when every slot is in use it is dropped and logged.
Because injection happens from the user session, it integrates with Windows' modern pointer input stack and — when the Daemon has UI Access — can drive elevated (administrator) windows, which the normal medium-integrity delivery cannot.
For this feature to work...
Windows 10 version 1809 or later (InjectSyntheticPointerInput is not available on older Windows)
To reach elevated windows: UPDD Daemon.exe must be Authenticode signed and run from a secure location (C:\Program Files\UPDD\). Without it, injection still works for normal applications but cannot reach apps running as administrator.
You can enable this setting via the UPDD command line utility, upddutils or via a UPDD API call:
Pen vs Touch routing per controller comes from that controller's existing active_pointer_interface setting.
Command
upddutils global set use_input_injection 1 :: enable
upddutils global set use_input_injection 0 :: disable (revert to virtual-HID)
API
TBApiSetSetting(0, "use_input_injection", "1", false);
active_pointer_interface per controller while injection is on: auto → pen devices inject as pen, everything else as touch; touch → touch; pen → pen; mouse → not injected (stays on the legacy virtual-HID/mouse path).
Use cases
- Touch/pen on elevated (administrator) applications, which standard delivery cannot drive.
- Many controllers, one coherent touch stream — the unified contact-id space keeps multi-touch coherent across all of them.
- High contact counts — one interface supporting up to 256 contacts rather than spreading them across per-monitor virtual-HID devices.
- Apps that consume the modern Windows pointer/touch stack get real injected touch.
Notes & limitations
- Windows only
- A touch lands on the monitor the controller is associated with (monitor_number); if it appears on the wrong screen, fix the controller's monitor association using Identify
- mouse-mode controllers are never injected.
- Overflow (more simultaneous contacts than the interface supports) is dropped and recorded in the UPDD log.