Typed keys

[kwhat]

Typed keys

[kwhat]

Looks like there are some serious issues with input events on OS X. I am not receiving events mouse events and experiencing deadlocks. You don't happen to know what commit started this behavior do you?

[munsuri]

Using the latest master commit on this Macbook Pro 10.9.4 I don't have the issues you mention as long as I don't use CFRunLoopGetCurrent() instead of CFRunLoopGetMain() on the callback.

[kwhat]

I found the source of the deadlock I am experiencing, but I am not sure it is cause of the problem you are describing.

First, the dead lock is on the hook_control_mutex and is caused by a race condition between hook_callback.c#L248 and
hook_thread.c#L51. You can probably get away with commenting out hook_thread.c#L51 for the time being. I will audit the program flow tonight and see if I can work out something better.

Now as far as the CFRunLoopGetCurrent() vs CFRunLoopGetMain() go, I am not sure what you are doing but maybe if I describe how the library works you can tell me how/why it is causing an issue. The library requires two runloops, one for the callback thread and the other is a Main RunLoop. The callback RunLoop (CFRunLoopGetCurrent) is pretty strait forward and is used to block the hooks pthread. The Main RunLoop (CFRunLoopGetMain) is required for the TIS functions in input_helper.c#L154 to prevent random thread safety issues like "TSMProcessRawKeyCode failed (-192)." Normally this wouldn't be a huge deal if we could use the LLVM blocks extension, but that is not available to this project for a number of reasons. So instead, I add my own observer to the main runlop in hook_callback.c#L177 and then signal and wait in hook_callback.c#L350 when a key typed event is required. The signal is picked back up in the hook_callback.c#L126 for processing and then a conditional is used to resume the hook thread. Do you have main RunLoop active? Did you stop the Main RunLoop started by the library?

[munsuri]

Thanks for the clarifications.
I'll take that deadlock into account but as for now my test example doesn't reach hook_callback.c#L248 nor hook_thread.c#L51 (observer not notifying for a kCFRunLoopExit yet)

As for the other issue, it happens to me even with fresh check out of the master branch (didn't stop the main runloop, so it should be up and running). However, every time I type I get:

hook_event_proc [328]: Key 0X1E pressed. (0)
id=4,when=1413108888368,mask=0x0,keycode=30,rawcode=0x0
hook_event_proc [382]: Failed to signal RunLoop main!
hook_event_proc [403]: Key 0X1E released. (0)
id=5,when=1413108888376,mask=0x0,keycode=30,rawcode=0x0
hook_event_proc [328]: Key 0X1E pressed. (0)
id=4,when=1413108888776,mask=0x0,keycode=30,rawcode=0x0
hook_event_proc [382]: Failed to signal RunLoop main!
hook_event_proc [403]: Key 0X1E released. (0)
id=5,when=1413108888808,mask=0x0,keycode=30,rawcode=0x0
...
hook_event_proc [382]: Failed to signal RunLoop main!

So I checked that and I saw hook_callback.c#L335 returning NULL which according to the CFRunLoopCopyCurrentMode doc, indicates a not running loop and therefore never enters the key typed case. Then I played a bit by exchanging it for a CFRunLoopGetCurrent() but then it blocks there. I'll try to trace the main loop and see what happened to it.

[kwhat]

Deadlocks are fixed in the trunk for Darwin and X11. Based on what you described, it sounds like you forgot to explicitly call CFRunLoopRun() from main. I'll play around with a little more and see if I can duplicate the issue.

[munsuri]

Oh, yeah, perfect. Completely right. Porting the demo to only pthread's made me overlook that call. I will still try to move it to the darwin implementation. Thank you for pointing that out, for the deadlocks fix and this wonderful library.

[kwhat]

Awesome! Thanks for the bug report and I am glad you are finding the library useful. I added a small note to the demo to avoid confusion.