(In reply to John Chadwick from comment #109) > Hey all, I hope you are doing well. It has been a while. It appears the > first time I touched this issue was all the way back in 2015. > > I am currently in the process of trying to get Painttool SAI 2 to work > properly under mainline Wine. One patch is already in > (https://source.winehq.org/patches/data/173932), the next is in flight > (https://source.winehq.org/patches/data/174062), and I have a third change > that should make everything work correctly that I will submit once the > second fix is squared away. After that, SAI 2 should work properly in Wine > without any need to mess with configurations. > > This got me thinking back to SAI 1, and I think I finally fully understand > the problem. With a little bit of tracing, I noticed that SAI 1 does some > interesting Wintab magic. It creates a top-level, hidden window with the > sfl_wintab_window class, and no geometry to speak of. > > What's going on here? It appears SAI 1 uses this magic window to receive > Wintab32 events. The thing is, Wintab32 events are not like mouse events. It > seems that Wintab32 actually handles the contexts as a stack, and hidden > top-level windows appear to be treated as covering the entire screen. > Painttool SAI 1 uses the WTOverlap function to move its context to the top > of the stack when the window is focused, and to the bottom of the stack when > the window is unfocused. > > Here's where things get tricky: In the Xinput code, XSelectExtensionEvent is > called on the X11 window of hOwner (using X11DRV_get_whole_window.) This > works in the case where the context == the window where you will be using > the tablet. It does *NOT* work in the case of using top level hidden windows > to receive Wintab32 events and manually shuffling them using WTOverlap. Even > if we patch it to XSelectExtensionEvent on the root window, it won't be able > to figure out what context it should send the events to. > > The Wintab code should probably register for events in > X11DRV_LoadTabletInfo, and it should do so on the X11 root window. > X11DRV_AttachEventQueueToTablet should just map the hWnd to a context. But > crucially, the way the event handlers work needs to change. Instead of > sending the message directly to the hWnd that the event is matched with, the > hWnd should be ignored, and we should iterate through a stack of windows, > finding the first one that overlaps with the event coordinates. Then, > WTOverlap should be implemented to manipulate this stack. > > I suspect all of the information we need to determine if a context overlaps > is the HWND. So, we already have most of the necessary information. However, > we do need a way to propagate the WTOverlap calls back to winex11.drv, which > will probably need to come in the form of new graphics driver functions. In > the meantime, it's probably not a big deal to ignore WTOverlap since it > probably only has an impact when working between different applications. > > It's probably going to be valuable to also investigate the behaviors and > interactions between various techniques in Windows. For example, what > happens when you drag the tablet outside the window? It may not be > sufficient to simply route events based on what the top most context > matching the geometry is; some additional heuristics may be needed to ensure > the events between two button_events from a single cursor are always routed > to the same context even if they leave the bounds of the context. > > Regardless, I hope we can resolve this issue soon. It's been a long time > coming.
That sounds awesome, really great to see someone looking into this. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/151448 Title: Wacom pressure sensitivity lacking under Wine applications. To manage notifications about this bug go to: https://bugs.launchpad.net/wine/+bug/151448/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
