I pushed some changes to make it always use mouse events, as apparently the tablet event fields can be set on mouse events as long as the subtype is one of the two tablet events. The dedicated tablet event types are intended to be used for non-mousing devices, so it was breaking things like CSP's Cmd+Opt brush size resizing, and Spacebar panning.

Some caveats worth mentioning:

• Only wacom devices support proximity event.
• There is idle report on some devices, i.e. Flush is called without SetPosition.
• There are devices without out of range report, i.e. Reset is not called.

There is idle report on some devices, i.e. Flush is called without SetPosition.

Since I based the behavior on the implementation of EvdevVirtualTablet, would this cause issues on Linux? I'm not sure you can push a mouse event without a position on macOS, so maybe it should fetch the current position if no SetPosition call has happened since the last flush.

I guess it could also be implemented without the synchronous pointer interface. Instead, sending mouse events for every change. It's not clear to me what the difference is for virtual devices implementing or not implementing it.

The behavior of Evdev is a bit different from macOS, when you call the Flush function, it flushes pending events set by SetPosition / SetPressure. Since SetPosition is not called for idle reports, no pointer events are sent to GUI.

The idle reports are sent periodically when the pen is out of range, so your implementation will make the cursor teleport periodically when the pen is out of range.

You could skip posting event if SetPosition is not called before Flush

There are some other issues:

• The SetProximity in otd is a bit misleading. It is called as long as the pen is in range and not too far away from the tablet., so your implementation makes most of CGEvents become proximity events for Wacom devices.

• In your implementation the Reset function set the proximity flag to true without setting it back later, so if the tablet supports out of range reports, every CGEvents becomes proximity events after pen is out of range.

• Proximity events should only be posted once when the pen is into range or out of range with kCGTabletProximityEventEnterProximity set to 1 or 0 correspondingly.

• Not all drawing apps recognize subtype kCGEventMouseSubtypeTabletProximity.
  Wacom driver`s behavior is to post one more kCGEventTabletProximity CGEvent before posting MouseMoved CGEvent with subtype kCGEventMouseSubtypeTabletProximity, other events are posted with subtype kCGEventMouseSubtypeTabletPoint.

This needs rebased to work with the new DI rewrite.

As mentioned, this needs a rebase to the latest codebase to be able to be merged. We are very interested in merging this PR.

Has there been any progress on this? I badly need this.

Very likely superseded by the #2894, as this pull is still not rebased to the latest version.

If you need it bad enough you can compile it yourself as use it, both pull requests should be good enough to use.

Closing in favor of #2894 as that PR now has further progress. Thanks for getting the ball rolling!