Hi, This is my analysis of speakup-r empty line lockup so far. The call chain that leads is: cursor on an empty line --> user hits speakup-r --> (everthing from here on will be in interrupt context) --> keyboard_notifier_call(code == 4 == KBD_KEYSYM) --> speakup_key() --> do_spkup() --> spkup_handler(value ==47==index of read_all_doc) --> read_all_doc --> kbd_fakekey2() Now, inside kbd_fakekey2(), speakup_fake_down_arrow() causes the lockup. And inside speakup_fake_down_arrow(), input_sync() causes the lockup. I'm pretty sure keyboard_notifier_call is not invoked again, after input_sync() when the lockup happens. So either lockup happens inside input_sync() or some callback that is invoked as a result of input_sync's execution. >From tests that John ran, we can say that speakup_fake_down_arrow itself is correct. It's only when it is called as a result of above call chain that the lockup happens. Also worth noting is the fact that above sequence is all inside interrupt context. Any ideas or suggestions about line of investigation will be helpful. Until then, I'll continue to explore this. Thanks, Okash _______________________________________________ Speakup mailing list Speakup@xxxxxxxxxxxxxxxxx http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
