The keyboard interfaces and protocols in X

[John Found]

> If you want to avoid libx11/xcb, you should use libxkbcommon.

Well, what is the difference? I want to avoid as many external libraries
as possible. And (what is maybe more important) to understand how the 
whole system works under the library cover.

OK, let try asking specific questions:

1. The reply of XkbGetMap: 

What is the meaning of the fields in the following structure, in the
XkbGetMap reply:

KB_KEYSYMMAP     8+4n
4     LISTofCARD8    ktIndex      ; What is this?
1     CARD8          groupInfo    ; What is this?    
1     CARD8          width        ; Width of what?
2     n              nSyms        ; more or less clear
4n    LISTofKEYSYM          syms  ; clear as well.


For example the following record:

01  14  00  00  = ktIndex   - what this means?
02              = groupInfo - what info?
04              = width     - of what?
08  00          = 8 keysyms follow
34  00  00  00  = "4"
24  00  00  00  = "$"
00  00  00  00  = NULL
00  00  00  00  = NULL
34  00  00  00  = "4"
24  00  00  00  = "$"
AC  20  00  00  = "€" (euro sign)
AC  20  00  00  = "€" (euro sign)

It is not explained in the documentation. Well, or I missed to find it.

2. The events generated:

When selected events with xkbUseCoreKbd the application receives 
multiply XkbMapNotify events (10 or more) - one per every deviceID.

What are all these devices for? I have actually only two keyboards on
the computer, but more than 10 devices.

How to make to get only one event per map change?


These two for now.

Cheers!
John Found


On Tue, 15 Feb 2022 10:35:58 +1000
Peter Hutterer <peter.hutterer at who-t.net> wrote:

> On Sun, Feb 13, 2022 at 07:01:04PM +0200, 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.  
> 
> Slightly more than "some" but yes, you need to process this. Think of
> the keyboard as a 105-key mouse. Now you get a button event for
> button 72 - what unicode code is that? The correct answer is: "this
> is the wrong question".
> 
> X works with keycodes which are _hardware_ codes. [1] You *need* a
> keymap, which tells you that hardware code N maps to unicode point M.
> You can deal with the core keymap only, or you can accept that
> everyone has been using XKB for decades now. The server gives you
> that core keymap but that still means you need to do the state
> handling for modifiers etc yourself.
> 
> If you want to avoid libx11/xcb, you should use libxkbcommon.
> Handling all this yourself means you'll spend the majority figure all
> this out. I doubt that's the goal. There's still some extra work
> needed since you don't get the component names from the core protocol
> but you can hack around that. At least you won't have to implement
> all of XKB client-side with libxkbcommon.
> 
> Cheers,
>   Peter
> 
> [1] They are now mostly normalized on Linux to evdev codes (+ offset
> 8) but that's a relatively recent addition given the age of X.