Dave Mielke <d...@mielke.cc> writes: > [quoted lines by Mario Lang on 2017/07/27 at 09:02 +0200] > >>Is there anything that I (with my limited understanding of the core) can >>do to help in this? > > The core - see brl_base:enqueueKeyEvent() - already calls > api_handleKeyEvent(). > The rest is up to that function, which should return true if it consumes it > and > false if it doesn't.
It looks like Programs/brlapi_server.c:api_handleKeyEvent() already does what we need. It packs the three individual values into a brlapi_keyCode_t: clientCode = ((brlapi_keyCode_t)group << 8) | number | ((brlapi_keyCode_t)press << 63); and passes it on to api__handleKeyEvent(). This is great! But why doesn't it work / what could I be missing? The symptom I am seeing is that brlapi__readKey() only works if I pass "" as driver string to brlapi__enterTtyMode(). If I pass "HandyTech", which is what I am using right now, a blocking brlapi__readKey never returns. In fact, I know the core doesn't pass the keypresses on because some of the keys result in BRLTTY playing a sound, as if it were trying to read a screen. Maybe the detection logic for brl_keyToCommand() is the problem? Or something else? -- CYa, ⡍⠁⠗⠊⠕ | Blog: <https://blind.guru/> GitHub: <https://github.com/mlang/> .''`. | Twitter: @blindbird23 FaceBook: disyled : :' : | SoundCloud: <soundcloud.com/mario-lang> `. `' | YouTube: <youtube.com/user/mlang23> `- _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty