<html> <head> <meta content="text/html; charset=koi8-r" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 12/12/2015 14:23, Ilya Anfimov wrote: </div> <blockquote cite="mid:20151212132309.GA9161@azor.tzirechnoy.ru" type="cite"> <pre wrap="">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. </pre> <blockquote type="cite"> <pre wrap=""> 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 </pre> </blockquote> <pre wrap=""> 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.</pre> </blockquote> Listening for expose events sounds like a good idea but the relation between graphics operation, their effect and expose events doesn't seem to be stated in the specifications. In the current experimental setup only keyboard events are in the event mask and it's a little bit surprising that the graphic operation has an effect only after a keyboard event has been received. <blockquote cite="mid:20151212132309.GA9161@azor.tzirechnoy.ru" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap=""> 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]<a class="moz-txt-link-freetext" href="https://code.launchpad.net/%7Emichael-tiedtke-i/viper-system-interface">https://code.launchpad.net/~michael-tiedtke-i/viper-system-interface</a> /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 </pre> </blockquote> <pre wrap=""> You have specs of MIT Magic Cookie? You lucky guy, I don't have this one.</pre> </blockquote> It just needed some script "playing" the server to find out about the correct padding which usually should coincide with the terminating C string null byte. <title>Konsole output</title> <div> (repl-transcript ;; ;; SCA/X Reverse Engineering Xauth ;; ;; xauth mcookie reverse engineering => leading padding for mcookie key ;; ;; (bind s AF_INET INADDR_ANY 6000) ;; (listen s 5) ;; (begin ;; (newline) (newline) ;; (display "Try to open an X client on display 127.0.0.1:0 to find out about the magic i n mit-magic-cookie-1 ...")) ;; (define p (accept s)) ;; (define sxau (read-bytes 1024 (port->fdes (car p)))) ;; (sys-load "VSI-core/byte-structures.scm") ;; (define X-conn-client-prefix-layout ; copied from X.scm ;; (byte-structure-description ;; šš(byte-order 1) ;; šš(padding ššš1) ;; šš(major-version 2) ;; šš(minor-version 2) ;; šš(nbytes-auth-proto š2) š; ??? STRING8 in the standard ;; šš(nbytes-auth-string 2) š; ??? STRING8 in the standard ;; šš(padding ššš2))) ;; (define-bs-accessors 'xconc X-conn-client-prefix-layout) ;; (xconc:byte-order sxau) ;; (xconc:major-version sxau) ;; (xconc:minor-version sxau) ;; (xconc:nbytes-auth-proto sxau) ;; (xconc:nbytes-auth-string sxau) ;; (define proto (byte-string-select sxau ;; ššššššššššššššš(bs-length X-conn-client-prefix-layout) 18)) ;; (c-string->deprecated-string proto) ;; (define audat (byte-string-select sxau ;; ššššššššššššššš(+ (bs-length X-conn-client-prefix-layout) 18 1) 16)) ;; audat ;; sxau ) </div> <meta http-equiv="Content-Type" content="text/html; charset=koi8-r"> <blockquote cite="mid:20151212132309.GA9161@azor.tzirechnoy.ru" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap=""> 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. </pre> </blockquote> <pre wrap=""> No, XKB is not strictly required. The next log supposes you fixed your issues and successfully receiving keyboard events.</pre> </blockquote> The keyboard events seem to be alright but as stated they only report the keycode: to map keys to the labels on the caps the keysyms are needed. But core protocol requests to receive those mappings for the current maps in effect are ignored by the server. <blockquote cite="mid:20151212132309.GA9161@azor.tzirechnoy.ru" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap=""> 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 </pre> </blockquote> <pre wrap=""> The fact that the newly created window is unmapped is pointed out in the first sentence of CreateWindow description.</pre> </blockquote> Yes. The second map request was a bogus request to receive the error notices. <blockquote cite="mid:20151212132309.GA9161@azor.tzirechnoy.ru" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap=""> errors due to simple mistakes during the preparation of the request and some misleading protocol encoding which states 3+3n for the request length. </pre> </blockquote> <pre wrap=""> 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.</pre> </blockquote> <blockquote cite="mid:20151212132309.GA9161@azor.tzirechnoy.ru" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap=""> (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 </pre> </blockquote> <pre wrap=""> I hope, yes.</pre> </blockquote> Well, thank you. <blockquote cite="mid:20151212132309.GA9161@azor.tzirechnoy.ru" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap=""> 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 </pre> </blockquote> <pre wrap=""> 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.</pre> </blockquote> The QueryExtension request isn't implemented in the experimental setup right now but as stated /xdpyinfo/ didn't report that operation code. <blockquote cite="mid:20151212132309.GA9161@azor.tzirechnoy.ru" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap=""> extension. The current state of X11 is a bit puzzling: it when works </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> The core protocol is trivial - just not well documented. ;-) The XKB extension doesn't make much sense (as an integral whole) and the problems described in its specifications only start to show up now for some clients where the Render extension seems to provide access to modern graphic operations (in a very fine grained way? ... Thanks for pointing out CLX. I'm definitely going to have a look at it but the CL model of frames and views (and the SBCL use of metaclasses) doesn't really fit the current development goal to create a controlling graphical input output path suited for Scheme. Simply transforming Lisp code wouldn't help much as the overhead of writing byte structure descriptions is small compared to the task of "updating" the Algorithm Notation Scheme to include Graphic (and sound) algorithms in the usual sleak way. At least the new memory manager doesn't need to interrupt the process every now and then but when we compare the implementation of the numerical tower with its support for four or five different number types in 6000 lines of C code with the expected amount of code to support half the graphic formats in use ... CU </body> </html>