X Core Protocol Scheme

[Michael Titke]

Now the arc drawing part works: it needed a little change of the 
"implemented protocol" or request sequence:
First map the window, second listen for events. Third draw the arc.

That was the third round after authentication and putting a window on 
the screen. It would be nice if these sequences were  documented as part 
of the protocol. For now it remembers me that I need to change the low 
level IO routines to then buffer the graphics operations in a drawing 
graph and connect it the repaint events and ...

(X-polifill-arc X (second v) (second g) 150 200 60 60 (* 10 64) (* 350 
64)) => 24  ; doesn't appear
(X-map-window X (second v)) => 8
(X-control X) => Window #"254 255 31 4" received a key event #"9" down.
escaping-X-control
VSI> (X-polifill-arc X (second v) (second g) 150 200 60 60 (* 10 64) (* 
350 64))  ; OK appears
(X-polifill-arc X (second v) (second g) 150 200 60 60 (* 10 64) (* 350 
64)) => 24
VSI> (X-control X)
...


VSI: 
https://code.launchpad.net/~michael-tiedtke-i/viper-system-interface/alfa



On 11/12/2015 22:02, 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.
>
> 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/20151212/c8ccb56c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2015-12-12 10:12:25.png
Type: image/png
Size: 2719 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20151212/c8ccb56c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VSI-logo.q64px.png
Type: image/png
Size: 4592 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20151212/c8ccb56c/attachment-0001.png>