X Core Protocol Scheme

[Michael Titke]

On 14/12/2015 07:52, Alan Coopersmith wrote:
> On 12/11/15 01:02 PM, Michael Titke wrote:
>> Hello!
>>
>> As part of a first incursion into the possibility to implementing 
>> native support
>> for X starting from the wire protocol (w/o any Xlib/XCB support) I 
>> ran into a
>> couple of situations where documentation didn't match implementation.
>>
>> The first surprise was the "magic" of the MIT Magic Cookie which 
>> needs that
>> little deviation from the protocol encoding where you have to put the 
>> padding
>> bytes at the end. Now I really made it to open a window and receive 
>> key codes
>> destined for it but no keysyms as the request for the keyboard 
>> mappings is
>> silently ignored. The XKB extension as far as I understand it 
>> essentially
>> replaced that? But there is no addendum to core protocol specifications.
>
> All the extensions, such as XKB, should be documented as well on
> http://www.x.org/releases/X11R7.7/doc/index.html
>
> XKB is "X Keyboard Extension" there.
>
>> My question is: will this continue like this? Are there any plans to 
>> finally
>> deliver the protocol specifications where these kinds of interactions 
>> are layed
>> out? Or some up to date updates on the core protocol?
>
> The core protocol hasn't changed in years, there shouldn't be much to 
> update.

Why update? It's about the parts where one shouldn't (or can't) use the 
core protocol anymore. At some point they decided to support 
"implementors" of toolkits directly (instead of delivering shiny 
standard documents)? The reason to update would be: when someone needs 
low level functionality one usually starts from the core protocol. But 
the core protocol hasn't been updated to mention the need to support for 
example the X keyboard extension. Each and every extension seems to be 
documented but the only way to find out about current best practices and 
else is to "scan" every documenting file of every extension and the 
source code of a reference library plus trial and error prototyping? And 
if I don't receive the key code to key symbol mappings by means of the 
core protocol even though the current prototype implementation adheres 
to its description then maybe the core protocol has been changed? That 
bad start where the position of the padding bytes of some authentication 
data (called magic cookie) contraddicts the described protocol encoding 
seems to repeat: even that is a "documentable", I'd say.

>
>> But as I have heard the server doesn't even know about all registered 
>> extensions anymore
>
> The X server knows about all the extensions currently supported and 
> enabled for it.  It's not required to support all extensions and never 
> has been.
>
>> - at least on
>> Ubuntu with Unity one of the first events to be received was an 
>> impossible
>> operation code of 192 which wasn't reported by /xdpyinfo/ to belong 
>> to any
>> registered extension.
>
> As documented in the Core Protocol spec, the 8th bit of the event code 
> is used
> to mark if the event came from the server or a client - strip that bit 
> off to
> get the code mapped to those reported by xdpyinfo.
>
> http://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#event_format 
>

Thank you! Then it's the operation code 64 and belongs to a registered 
extension then.


>
>> It's easy to make mistakes when implementing things on a bit and byte 
>> level but
>> if anyone knows the "one true sequence" to draw a real circle that 
>> would be
>> helpful. The FAQ mentions the Xlib flush/sync mechanism but I wasn't 
>> able to
>> find any correspondence in the wire protocol and it seems to affect 
>> the xlib
>> client buffers only.
>
> Flush is simply writing the contents of the Xlib buffer from memory to 
> the socket.
>
> Sync is doing a flush followed by sending a GetInputFocus request, 
> waiting
> for the response, and then discarding it.
>
>

Thank you! That confirms my suspicion that I'll have to use "bogus" 
events from time to time to flush or sync graphics and state reflections 
(which isn't any problem when known). But my original intention to 
contact X.org stems from the fact that these kinds of interactions 
between clients and servers aren't well documented but could be as part 
of the protocol.