Open upstroke-version opened 2 years ago
Just so I know where to narrow my investigation, do you have "Avoid private framework" checked in the settings tab of the prefs window?
Just so I know where to narrow my investigation, do you have "Avoid private framework" checked in the settings tab of the prefs window?
Avoid private frame work is checked. I will test if the issue persists when i uncheck it.
When I uncheck it, the issue seems to get worse.
I wasn't able to reproduce this. Maybe if I explain how things work Multitouch side, we can get closer to figuring out what's going on here, without having to roll a debug build with more logging.
Multitouch doesn't detect pressure and determine whether or not a click occurs, it gets the click events straight from macOS. This means that macOS is telling Multitouch that a click is occurring. For haptic feedback to occur, a touch must be on the trackpad. A potential scenario is that there is some lag with the event stream, and there's some difference between when things are occurring (a click is indeed fired, but by the time the OS would respond with haptic feedback, your touch is gone). Since you noticed a difference between the public/private frameworks, this seems likely the scenario. From my experience, there are a number of things that can contribute to some lag in the touch event stream. One of them is using an external trackpad and having multiple bluetooth devices. I plug in my external trackpads since even without Multitouch running I can get some input lag. Another is simply using apps like Multitouch, and potentially having high resource usage at the same time. There are a lot of factors at play and these types of things can be difficult to narrow down.
It might help us to know if Multitouch is directly causing this, and if reducing Multitouch's event stream processing can lead to any different results. Without Multitouch running, try the same rapid tapping and see if any of it is a click. If it helps, you can use this website to test clicks: https://unixpapa.com/js/testmouse.html If this is just with Multitouch running, then it would be good to know if having specific gestures removed affects the performance at all (if you don't mind, since I realize that can be kind of annoying to test).
I wasn't able to reproduce this. Maybe if I explain how things work Multitouch side, we can get closer to figuring out what's going on here, without having to roll a debug build with more logging.
Multitouch doesn't detect pressure and determine whether or not a click occurs, it gets the click events straight from macOS. This means that macOS is telling Multitouch that a click is occurring. For haptic feedback to occur, a touch must be on the trackpad. A potential scenario is that there is some lag with the event stream, and there's some difference between when things are occurring (a click is indeed fired, but by the time the OS would respond with haptic feedback, your touch is gone). Since you noticed a difference between the public/private frameworks, this seems likely the scenario. From my experience, there are a number of things that can contribute to some lag in the touch event stream. One of them is using an external trackpad and having multiple bluetooth devices. I plug in my external trackpads since even without Multitouch running I can get some input lag. Another is simply using apps like Multitouch, and potentially having high resource usage at the same time. There are a lot of factors at play and these types of things can be difficult to narrow down.
It might help us to know if Multitouch is directly causing this, and if reducing Multitouch's event stream processing can lead to any different results. Without Multitouch running, try the same rapid tapping and see if any of it is a click. If it helps, you can use this website to test clicks: https://unixpapa.com/js/testmouse.html If this is just with Multitouch running, then it would be good to know if having specific gestures removed affects the performance at all (if you don't mind, since I realize that can be kind of annoying to test).
I appreciate your detailed explanation. I did few test with changing one variable at a time. tunring off Multitouch, disabling blutooth and using internal trackpad, or doing both, which didn't help when I test with https://unixpapa.com/js/testmouse.html.
But, I found a solution, turning off tap to click on macOS system settings solves the issue. Which I think it's kinda weird because just taping doesn't trigger click on https://unixpapa.com/js/testmouse.html. even when I enable tap to click, but taping very lightly with some gesture(rest three tap one) does??. But, in the end, it seems like it's macOS's bug, not Multitouch's, since result is same whether the app is turned on or off.
TLDR: Turn off tap to click on macOS settings
This could simply come down to the way that Multitouch handles tap to click. It's been a long time since I've touched Multitouch's tap to click handling, and I've been thinking of looking at it from a different angle. If I can get something working, then I'll go ahead and push out a beta that will have updated tap to click handling along with that fix for your other issue. If I can't get something working, then I'll probably just shoot for pushing a regular release out the door sooner, depending on if I come across any other items that I want to add in.
Multitouch app gets a false-positive click when I rapidly touch with a bit of force. MultiTouch app confuses touch and click for 5 to 50% of a time. This is a log when I "touch" corner rapidly.
The trackpad itself does not provided haptic feedback when this happens, so trackpad hardware itself also thinks I only touched too , but multitouch app thinks I clicked it. This might be a root cause of this issue I previously wrote. https://github.com/rxhanson/Multitouch-Community/issues/127