[quoted lines by Samuel Thibault on 2020/12/21 at 00:05 +0100] >I don't think we want to embed the decoding knowlege in libbrlapi itself, but >keep it in the driver or key table. I.e. when decoding a key event, you'd >request the server to do the decoding. We can however try to cache the result >in libbrlapi, to avoid requesting it every time.
libbrlapi already supports plitting up a command keycodde (describe, expand)), and it already has the tools to get at the individual fields of a driver keycode. The only thing we're missing is group names. We already have BRLAPI_PARAM_DEFINED_DRIVER_KEYCODES. To get th set of groups, therefore, all we'd need is a function to go over a set of whole keycodes and return the set of discrete groups. Should that really be a new parameter and a request to the server given that the handling for this is totally generic? What we're missing is a parameter to get the name for a group, just like we already have parameters to get at the name and description for a whole keycode. This'd be a lot of work, unfortunately, since the key table doesn't define them. As for uint32_t for a key group, we currently use uint8_t for both the group and the number. Maybe I'm not thinking far enough ahead, of course, but that seems more than adequate for the set of keys that any braille device is likely to ever have. -- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: [email protected] | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | _______________________________________________ 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
