@Brecht Van Lommel (brecht) A logical extension to this fix would be correctly tearing down/setting up Wintab correctly after initialization (I'll work on this). With this fix but not Wintab setup/teardown you could expect weird behavior when creating new windows (e.g. new windows using the currently set tablet API while older windows use the previously set API). This is possibly related to other bug reports of tablet pressure being lost in secondary windows like T53553 but I'm not entirely sure.

My gut said the user set Tablet API this should be checked in Ghost's System constructor but iiuc that's not possible given Ghost has no knowledge of blender internals. I'm guessing this is otherwise the correct fix to make sure things start correctly, e.g. after the Ghost System has been created but before the primary Ghost Window is constructed?

I also wonder if this should be inside the if (!G.background) block similar to ndof initialization.

Just tested this patch, only secondary windows see the correct user set API during initialization, so this doesn't seem to occur early enough to preempt initializing the first window. This patch is still necessary for the GhostSystem to get the correct user set value eventually but it won't fix the most apparent user facing issue in that Wintab will still be used exclusively for the first window when available.