Closed teddywing closed 1 year ago
Thanks for the detailed debug info. I can confirm 567205b works on Monterey (support for older versions might be a bit flaky). My guess is that this is an accessibility issue. Were you prompted to add your terminal to the accessibility settings when you first ran the binary?
Your accessibility settings should look something like this:
I’m not prompted to allow Accessibility access when I run the binary normally, but I was prompted when running it through lldb
. This appeared to be acknowledged:
(lldb) c
Process 24399 resuming
Starting warpd vv1.3.4-osx (built from: 567205b) ()
Waiting for accessibility permissions
Accessibility permission granted, proceeding
Both my terminal (iTerm) and the warpd
binary are listed and checked in System Preferences > Security & Privacy > Privacy > Accessibility. I can confirm this in the TCC database:
$ sudo cp /Library/Application\ Support/com.apple.TCC/TCC.db /tmp/
$ sudo sqlite3 /tmp/TCC.db
...
sqlite> SELECT service, client, allowed FROM access WHERE service = 'kTCCServiceAccessibility' AND allowed = 1 AND (client LIKE '%warpd%' OR client LIKE '%iterm2');
service client allowed
------------------------- ---------------------------------- -------
kTCCServiceAccessibility <path/to>/rvaiya--warpd/bin/warpd 1
kTCCServiceAccessibility com.googlecode.iterm2 1
Even with Accessibility access allowed, however, I still seem to be getting the abort. Thanks for the clue, though. I’ll try to continue investigating.
Using a more stock macOS 10.12 system, I was able to successfully build and run the program. I think it has something to do with my configuration rather than the OS version.
For now, I’ve determined that the TISCopyCurrentKeyboardInputSource()
call at https://github.com/rvaiya/warpd/blob/567205bcc67718b5c5e75f32564dcfceffa51f43/src/platform/macos/input.m#L208 seems to be causing problems for me, but I’m not sure if that’s because I have multiple input sources that I switch between, or because I have a custom input source in my list (https://github.com/teddywing/QWAZERTY/), or some other reason.
The calls used for extracting layout data aren't well documented (I believe I found them by studying source I found online, so they may well be internal). Your exotic input setup is indeed likely the culprit. I'm not on my macbook right now, but I'll experiment when I get some time.
Can you see if the latest patch fixes it?
Thanks very much for the quick response!
Unfortunately, your latest https://github.com/rvaiya/warpd/commit/714d97747cc15370e47eb6eded879425fa5d8609 patch doesn't seem to fix my abort problem. I also tried removing my custom layout from my sources list, leaving only one stock input source, but that didn’t change the result.
I tried on a macOS 12 system, and it does work there, even with my custom input source.
I’ll see if I can gather any more information.
There might be an issue with running TISCopyCurrentKeyboardLayoutInputSource()
in a thread. If I move the call to osx_run
in src/platform/macos/macos.m
, I don’t get the abort.
I also noticed this comment in MacOSX10.15.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/TextInputSources.h
:
Mac OS X threading: TextInputSources API is not thread safe. If you are a UI application, you must call TextInputSources API on the main thread. If you are a non-UI application (such as a cmd-line tool or a launchagent that does not run an event loop), you must not call TextInputSources API from multiple threads concurrently.
Thanks. I probably should have been more scrupulous in checking which APIs are thread safe. The macos port was written in haste and I spent most of my time learning Objective C (which you can probably tell is not my mother tongue :P). Odd that this issue has never bitten me (I still can't reproduce it, even using your custom input sources).
Can you test the latest commit?
I tested 5971cfbf and it works! I no longer get an abort and the program launches successfully. Thank you so much!
I’ll close this as fixed.
I probably should have been more scrupulous in checking which APIs are thread safe. The macos port was written in haste and I spent most of my time learning Objective C (which you can probably tell is not my mother tongue :P). Odd that this issue has never bitten me (I still can't reproduce it, even using your custom input sources).
No worries :) I had the problem on one machine & OS version but not another, so it seems tricky to reproduce.
Thanks a bunch for writing Warpd. I’ve been dreaming about a keyboard-controlled mouse like this for a long time, and am so glad to be able to use it.
I’m getting the following error when attempting to run Warpd:
The same happens when installing and running via Launchd:
Do you have any guidance for how to debug the problem?
I’m running macOS 10.15:
This happens both on the latest master and on v1.3.4:
The binary seems to build correctly: