X Core Protocol Scheme

[Michael Titke]

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.

The next round was about creating a circle: somehow I found out that 
another map request on the window was needed to see the respective 
errors due to simple mistakes during the preparation of the request and 
some misleading protocol encoding which states 3+3n for the request length.

Konsole output
(define X (X-connection))=> #<unspecified>
(define v (X-create-window X 50 50 300 400))=> #<unspecified>
v=> (44 #"254 255 255 3")
(X-map-window X (second v))=> 8
(define g (X-create-gc X (second v)))=> #<unspecified>
g=> (16 #"253 255 255 3")
(X-polifill-arc X (second v) (second g) 150 200 100 100 (* 170 64) (* 
180 64))=> 24
(X-map-window X (second v))=> 8
(X-control X)=> VSI SCA/X: unhandled error: Length#"0 16 4 0  253 255 
255 3  0 0 71 0  0
0 0 0  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0"
#<unspecified>

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? But as I have heard the X server doesn't even know about all 
registered extensions anymore - 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. The current state of X11 is a bit puzzling: it when works 
better than ever on the hardware I know of but it seems to become a pure 
C API without a valid wire protocol?

(repl-transcript
(define X (X-connection))
;X
(define v (X-create-window X 50 50 300 400))
v
; (X-get-keyboard-mapping X) DEFUNCT

(define g (X-create-gc X (second v)))
g
(X-polifill-arc X (second v) (second g) 150 200 100 100 (* 170 64) (* 
180 64))
(X-map-window X (second v)) ; We need this to see errors of the graphic 
request.
(X-control X)
)

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.

Thanks in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20151211/a4e6011e/attachment.html>