The keyboard interfaces and protocols in X

[Andrew Bainbridge]

I tried to do something similar and had the same experience. I still don't know how to convert keyboard events to something useful like UTF-8. (I was actually aiming for Latin-1 to start with).

My terrible code is here:
https://github.com/abainbridge/deadfrog-lib/blob/master/src/df_window_x11.cpp

The keycode conversions are done in x11KeycodeToDfKeycode() and dfKeycodeToAscii().

If someone would like to tell me (and John) how to do better, that'd be great, as long as it doesn't involve adding any dependencies to my code :-)

- Andy

On Sun, Feb 13, 2022, at 5:01 PM, John Found wrote:
> Hi. 
> 
> I am trying to create a X client that to communicate to X server by the
> raw protocol, not using any libraries, such as XLib or XCB.
> 
> While with the graphics part it was simple and straightforward task,
> solved by simply following the protocol (The documentation on X11 is
> pretty complete and well written) and extensions documentation is
> available (although the MIT-SHM documentation on the protocol does not
> exists at all), I have stuck with the keyboard part of
> the protocol.
> 
> The biggest problem is the conversion from the keycodes into the
> Unicode characters (of course where it is possible).
> 
> Do I need XKEYBOARD extension? On only XINPUT. Or both. The
> documentation is complex and poorly written. I have a feeling that part
> of it was written not to be useful, but simply because it had to be
> written.
> 
> So, the question: 
> 
> What is the simplest, canonical, expected way to handle the keyboard
> events in X protocol in order to obtain the Unicode codes of the
> pressed keys? In raw protocol therms. And supporting multiple
> languages, of course. 
> 
> I understand that some processing on the client side is required, but I
> am missing the whole picture of the process.
> 
> Best Regards.
> John Found
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20220214/2afc1c18/attachment.htm>