Hello, On 2025-05-13 at 01:34 +0200, Samuel Thibault <[email protected]> wrote: > Aura Kelloniemi, le lun. 12 mai 2025 12:58:32 +0300, a ecrit: > > We would need to export BRLTTY's key table management data structures to > > client applications, and there would need to be a brlapi call for > > transferring > > key tables from the client to the server and the other way around.
> But what form would that be? a binary format? a text format to be parsed > by brltty? Security questions raise quite quickly... Depends on what BrlAPI already is, but don't ask me, I have never designed a network protocol from a security viewpoint. > > But if the client does the translation, all the same problems need to be > > solved. > Except that all the interface questions are not cast in stone into > the protocol (which is way more problematic to upgrade than a library > interface). And security questions do not raise. Hmm, are we talking about the same thing? If the key event handling is done on the client side in a way that I see it, BRLTTY needs to send its current key tables to the client through BrlAPI. The client may then us ethem to provide basic key bindings and as basis for more complete display model specific key bindings. This requires that we have a protocol for sending the bindings data. Of course BRLTTY can just send both raw keycodes and the commands it interpreted from them, and refrain from sending the whole key binding tables, but then the client application cannot reliably extend the command set provided by BRLTTY, because it cannot know which key bindings are already taken. It also cannot tell the user which key combination (on their specific display) triggers a particular command (like BRLTTY's help screen does). > > the client might need to run another thread to do the translation. > The current key event does not provide timing information but that would > be easy to add, avoiding the client to have to use threads etc. only to > get the event timing. Then the server would need to send key repeat events as well, because long key presses can trigger actions based on timeouts (compare to BRLTTY's own command repetition handling). But yes, this is quite simple. > > > And application will already be able to use > > > BRLAPI_PARAM_DEFINED_DRIVER_KEYCODES and > > BRLAPI_PARAM_DRIVER_KEYCODE_NAME > > > to get the set of raw keycodes and their names. > > > > BRLAPI_PARAM_DRIVER_KEYCODE_NAME cannot tell anything more about the key > > than > > its name. > What would you expect more than that? Routing key index would be a very useful piece of information. It would also be great to know if the pressed key is such that the display has a big number of them (like routing keys, touch sensors, etc.). > > if I remember correctly, it does not work for routing keys at all – > > for the first routing key it says the name is is "routing key" or > > similar, and for all the rest it gives no name. > That'd just be a bug to be fixed. Kind of, but BRLTTY does not itself have a separate name for different routing keys. They are all called simply a "RoutingKey" or "NavrowKey". These names are used in key binding tables. THe problem is that BRLTTY is able to detect which of the routing keys was pressed, but the applications cannot do this without specializing to a particular display model. -- Aura _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.app/mailman/listinfo/brltty
