X Core Protocol Scheme
Michael Titke
michael.tiedtke at o2online.de
Sat Dec 12 01:17:56 PST 2015
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>
More information about the xorg
mailing list