The UPDD driver generally only needs to handle pen devices/data if a single composite HID device (USB Vid and Pid) delivers both touch and pen data. Otherwise, it's best to allow the OS to natively support a pen device with specialist pen drivers or common active stylus protocols, such as USI, APC, etc
See https://www.howtogeek.com/835769/active-vs-passive-styluses-all-the-standards-explained/
If the driver is handling a pen device under macOS, Commander passes pen device inputs into the system as tablet events. These include proximity, left click (via nib), right click, barrel button, pressure, tilt and eraser features. The lower barrel button is mapped to Right-Click. Currently, there is no support for the pen upper side switch (as seen on Wacom pen type devices).
Pen nib and co-ordinate information bypasses the gesture engine, i.e. is not processed for gesture consideration, Commander simply posts the data on the tablet/pen interface.
Given that pen data is simply passed into the OS on the relevant pen interface, then under Windows, Commander does not receive pen data, and it is posted by the driver on the driver's Virtual HID pen interface.
When a pen device is detected, you can calibrate the pressure range of the device in the settings dialog. If the pressure range is not calibrated UPDD Commander calculates the maximum theoretical range based on the pressure definition of the device as configured in the driver (either manually or extracted from the HID descriptor).
Under macOS, for non-pen type devices, such as touchscreen that support pressure, there is a Commander global setting to post data as tablet events if so desired, and could be useful if interfacing with an application that responds to tablet input differently than mouse input. Under Windows, you can simply direct the touch data to be posted to the pen interface.
When working as expected the pen applications, including our own test program, will reflect the pressure in the line thickness as in this screenshot:
Process pen as mouse device
It was discovered that due to a bug in Chrome when using pen devices and passing data into the OS on the Tablet interface, that Chrome would cease to work correctly with the pen device, such that drawing in a whiteboard browser application would intermittently stop.
Other Browsers were unaffected, and testing with other table devices and drivers also failed, so we concluded it was not a UPDD Commander bug.
To cater for this issue, we introduced a global setting in UPDD Commander 1.5.2 for macOS builds that specifies which applications should receive mouse input instead of tablet input when using pen devices. This is intended to address the issue in Google Chrome where pen input wasn't working properly as described above.
The setting is "upddcommander.applicationsettings.tablet_posts_mouse_events_app_ids".
It should be set to a value that's a comma or space separated list of application bundle IDs. It needs to be bundle IDs instead of the app name because bundle IDs uniquely identify a specific app and remain consistent regardless of the system language.
Therefore, to have Google Chrome (and Chromium), receive mouse input instead of tablet input set the setting to the following value:
com.google.Chrome,org.chromium.Chromium
i.e. upddutils global set upddcommander.applicationsettings.tablet_posts_mouse_events_app_ids com.google.Chrome,org.chromium.Chromium
Please contact us if you need to use this feature for another applications, as we can get that app's bundle ID on a case-by-case basis.