X Core Protocol Scheme

[Ilya Anfimov]

On Sat, Dec 12, 2015 at 10:17:56AM +0100, Michael Titke wrote:

 Good day!

 First, quoting looks like you had posted some letters before the
one I'm replying, but I didn't see it in my mailbox or x.org list
archives,  so I will answer just to text in the letter written at
2015-12-12 10:17:56 +0100.


>    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

 Generally,  the exact sequence isn't that important. If you want
a consistent picture, and don't want to redraw 50 times a second,
then  you  should  draw  every time you received Expose event, no
matter what you drawed before and even no matter of  your  knowl-
edge of the mapped state.

(Hmm,  sorry for my english and for my descriptive abilities: ev-
ery time doesn't mean  that after receiving 2 or 5 or  10  Expose
events  in a single packet you should redraw the same 10 times in
a raw. Just redraw once at least all the requested regions  imme-
diately after some Expose events received).

 This is described in Expose event paragraph in section 11 of the
protocol specification.

btw, this automatically means  that  you  should  receive  Expose
events  on  the  window you want to draw and therefore select Ex-
posure in the event mask at a window creation.

>    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:
>    [1]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

 You  have specs of MIT Magic Cookie? You lucky guy, I don't have
this one.

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

 No,  XKB  is  not  strictly  required. The next log supposes you
fixed your issues and successfully receiving keyboard events.

>    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

 The  fact  that  the newly created window is unmapped is pointed
out in the first sentence of CreateWindow description.

>    errors due to simple mistakes during the preparation of the request and
>    some misleading protocol encoding which states 3+3n for the request
>    length.

 Didn't  see  any  misleadings  here. Request length is specified
consistently across the entire Requests section, and this meaning
is the only possible if you understand paragraph "Request Format"
in Chapter 1.
 Moreover, it is self-evident when you try to calculate that  re-
quest length by hand against fields byte length values.

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

 I hope, yes.

>    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  opcodes  assigned  by server at QueryExtension reply,
you should get that bytestream and find the extension  name  from
there. The number 192 may mean anything.

>    extension. The current state of X11 is a bit puzzling: it when works

 Yes,  the  protocol is not trivial. But it is consistent and core is
well-documented.

 There are some features or extensions which lacks  proper  docu-
mentation  (MIT-MAGIC-COOKIE-1  authentication, RENDER extension,
NV-GLX extension) but in fact all of them is crap, and you should
probably get rid of it.

>    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!
> 
> Ссылки
> 
>    1. https://code.launchpad.net/~michael-tiedtke-i/viper-system-interface/alfa



> _______________________________________________
> xorg at lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s