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!
_______________________________________________
[email protected]: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
