<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> Documenting another XII lock picking approach: new padding "rules" for SCA/X (define (round-up num-bytes pad) (* (quotient (+ (- num-bytes 1) pad) pad) pad)) (define (round-up/lynx num-bytes pad) (byte-string->number (bit-and (number->byte-string-8 (+ num-bytes (- pad 1))) (bit-not (number->byte-string-8 (- pad 1)))))) (define (padded4 num-bytes) (byte-string->number (bit-shift-right (number->byte-string-8 (+ num-bytes 3)) 2))) (define (X-pad num-bytes) (make-byte-string (- (round-up num-bytes 4) num-bytes))) ... (let* (rl (+ (byte-string-length rb) (padded4 (byte-string-length pixel)))) (pad (X-pad rl))) ... No error, no window. Just another ... BTW VSI GIO SCA/X big requests: maximum request size 4194303 yes, that's four million not 16GB. That's our brand new 16MB limit ... maths!? ;-) <div class="moz-cite-prefix">On 03/08/2016 19:48, Michael Titke wrote: </div> <blockquote cite="mid:57A22E73.20003@o2online.de" type="cite"> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> After some "research" into the bad length issue I was finally able to shed some light on how to use the information from the connection setup. ;-) ;; ;; ;; Graphical Viper System Interface ;; ;; ;; ;; Input SCA/X ;; ;; ;; ;; ;; Output Viper Object System ;; ;; ;; ;; ;; Z Pixmap: the number of scanlines is the /height/ and the number of pixels ;; in each scanline is the width. ;; (Scanline bits-per-pixel ... (padding bits-per-pixel=1 (|+| width bitmap-scanline-pad))) ;; ;; scanline-pad, bits-per-pixel are found via the /format/ of the /depth/ ;; ;; (Maybe doesn't apply to z pixmap formats bitmap-scanline-unit from the Display) ;; where for an example of one black pixel /depth/ is 24, bits-per-pixel is 32. No matter how many bytes (tested from 1 to 12) are sent over the wire (with big requests or not) it always results in a length error. Additionally in the server sources dix/dispatch.c knows about the following: /* 64-bit server notes: the protocol restricts padding of images to * 8-, 16-, or 32-bits. We would like to have 64-bits for the server * to use internally. Removes need for internal alignment checking. * All of the PutImage functions could be changed individually, but * as currently written, they call other routines which require things * to be 64-bit padded on scanlines, so we changed things here. * If an image would be padded differently for 64- versus 32-, then * copy each scanline to a 64-bit padded scanline. * Also, we need to make sure that the image is aligned on a 64-bit * boundary, even if the scanlines are padded to our satisfaction. */ int ProcPutImage(ClientPtr client) { ... That much effort to keep that much effort of processing bits and bytes and historical reviews of bits and bytes. Wow! <div class="moz-cite-prefix">On 03/08/2016 13:52, Michael Titke wrote: </div> <blockquote cite="mid:57A1DB00.4020806@o2online.de" type="cite"> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> That bad match error was caused by a wrong depth argument (8 instead of the visual depth of 24). We have now advanced to the length error but maybe padding strictness is server side only. ;-) Have Fun! <div class="moz-cite-prefix">On 02/08/2016 13:02, Michael Titke wrote: </div> <blockquote cite="mid:57A07DBF.2050606@o2online.de" type="cite"> <meta http-equiv="content-type" content="text/html; charset=utf-8"> Hello! I'm currently developing a preliminary object orientated framework for Graphical Input Output (GIO) based on a concurrent native implementation of the X protocol in Scheme (SCA/X). The early pixmap support fails for the GetImage and PutImage requests: GetImage provokes and undefined error from the X server where PutImage always seems to result in a match error. My question to the experienced ones: what are the prerequisites especially for PutImage? Is it the X security extensions, the big request extension, the shared memory extension, the render extension or some other "magic" again? (Currently the only extension implemented is the X keyboard extension.) Maybe some extension provides better means to achieve the following task which serves as an example to guide development of GIO and SCA/X: 1) a matrix of exact color vectors is converted to a pixel array (should equal Zpixmap) and it should be displayed in a window. 2) X server / hardware drawing routines should be used on an image / pixmap which should then be retrieved to be further processed by the client's exact / double precision color routines or to be stored in a file or similar I hope there's an easy answer similar to the case of the keyboard mappings where the server just didn't respond to the core protocol request anymore. Since the implementation of the X keyboard extension those mappings work and the core protocol request isn't needed anymore. The current request arguments used are the following (depth and left-pad are hardcoded in the early prototype but do match the visual type and the protocol specifications): (xrp-put-image:set-format! rb (byte->byte-string 2)) ; 0 bitmap 1 xypixmap 2 zpixmap (xrp-put-image:set-depth! rb (byte->byte-string 8)) (xrp-put-image:set-left-pad! rb (byte->byte-string 0)) ; 0 for zpixmap pp.55 (xrp-put-image:set-drawable! rb drawable) (xrp-put-image:set-gc! rb gc) (xrp-put-image:set-dst-x! rb (number+sign->byte-string-2 dst-x)) (xrp-put-image:set-dst-y! rb (number+sign->byte-string-2 dst-y)) (xrp-put-image:set-width! rb (number->byte-string-2 width)) (xrp-put-image:set-height! rb (number->byte-string-2 height)) (xrp-put-image:set-request-length! rb (number->byte-string-2 (/ (+ rl (byte-string-length pad)) 4))) (X-request connection (byte-string-adjoin rb pixel pad) no-response) No matter how the window, the pixmap and the graphics context are associated this request currently always results in a match error event. Regards, Michael -- The Viper System Interface: some sort of pure Scheme byte strings, brass, name spaces, the Viper Object System <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://launchpad.net/viper-system-interface">https://launchpad.net/viper-system-interface</a> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:xorg@lists.x.org">xorg@lists.x.org</a>: X.Org support Archives: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a> Info: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.x.org/mailman/listinfo/xorg">https://lists.x.org/mailman/listinfo/xorg</a> Your subscription address: %(user_address)s</pre> </blockquote> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:xorg@lists.x.org">xorg@lists.x.org</a>: X.Org support Archives: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a> Info: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.x.org/mailman/listinfo/xorg">https://lists.x.org/mailman/listinfo/xorg</a> Your subscription address: %(user_address)s</pre> </blockquote> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ <a class="moz-txt-link-abbreviated" href="mailto:xorg@lists.x.org">xorg@lists.x.org</a>: X.Org support Archives: <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a> Info: <a class="moz-txt-link-freetext" href="https://lists.x.org/mailman/listinfo/xorg">https://lists.x.org/mailman/listinfo/xorg</a> Your subscription address: %(user_address)s</pre> </blockquote> </body> </html>