X Core Protocol Scheme

[Alan Coopersmith]

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.

> 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

> 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.


-- 
	-Alan Coopersmith-              alan.coopersmith at oracle.com
	 Oracle Solaris Engineering - http://blogs.oracle.com/alanc