<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <font face="monospace">After some "research" into the bad length
      issue I was finally able to shed some light on how to use<br>
      the information from the connection setup. ;-)<br>
      <br>
         ;;   ;;   ;;     Graphical        Viper System Interface<br>
       ;;     ;; ;;  ;;   Input                    SCA/X<br>
       ;;  ;; ;; ;;  ;;   Output            Viper Object System<br>
         ;;   ;;   ;;                  <br>
      <br>
      ;;<br>
      ;; Z Pixmap: the number of scanlines is the /height/ and the
      number of pixels<br>
      ;;           in each scanline is the width.<br>
      ;; (Scanline bits-per-pixel ... (padding bits-per-pixel=1 (|+|
      width bitmap-scanline-pad)))<br>
      ;;<br>
      ;; scanline-pad, bits-per-pixel are found via the /format/ of the
      /depth/<br>
      ;;<br>
      ;; (Maybe doesn't apply to z pixmap formats bitmap-scanline-unit
      from the Display)<br>
      ;;<br>
      <br>
      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)<br>
      are sent over the wire (with big requests or not) it always
      results in a length error.<br>
      <br>
      Additionally in the server sources dix/dispatch.c knows about the
      following:<br>
      <br>
      /* 64-bit server notes: the protocol restricts padding of images
      to<br>
       * 8-, 16-, or 32-bits. We would like to have 64-bits for the
      server<br>
       * to use internally. Removes need for internal alignment
      checking.<br>
       * All of the PutImage functions could be changed individually,
      but<br>
       * as currently written, they call other routines which require
      things<br>
       * to be 64-bit padded on scanlines, so we changed things here.<br>
       * If an image would be padded differently for 64- versus 32-,
      then<br>
       * copy each scanline to a 64-bit padded scanline.<br>
       * Also, we need to make sure that the image is aligned on a
      64-bit<br>
       * boundary, even if the scanlines are padded to our satisfaction.<br>
       */<br>
      int<br>
      ProcPutImage(ClientPtr client)<br>
      {<br>
      ...<br>
      <br>
      That much effort to keep that much effort of processing bits and
      bytes and historical reviews of bits and bytes. Wow!<br>
      <br>
    </font><br>
    <br>
    <div class="moz-cite-prefix">On 03/08/2016 13:52, Michael Titke
      wrote:<br>
    </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<br>
      but maybe padding strictness is server side only. ;-) Have Fun!<br>
      <br>
      <div class="moz-cite-prefix">On 02/08/2016 13:02, Michael Titke
        wrote:<br>
      </div>
      <blockquote cite="mid:57A07DBF.2050606@o2online.de" type="cite">
        <meta http-equiv="content-type" content="text/html;
          charset=utf-8">
        Hello!<br>
        <br>
        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).<br>
        <br>
        The early pixmap support fails for the <i>GetImage</i> and <i>PutImage</i>
        requests: <i>GetImage</i> provokes and <i>undefined</i> error
        from the X server where <i>PutImage</i> always seems to result
        in a match error. My question to the experienced ones: what are
        the prerequisites especially for <i>PutImage</i>? 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.)<br>
        <br>
        Maybe some extension provides better means to achieve the
        following task which serves as an example to guide development
        of GIO and SCA/X:<br>
         1) a matrix of exact color vectors is converted to a pixel
        array (should equal Zpixmap) and it should be displayed in a
        window.<br>
         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<br>
        <br>
        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.<br>
        <br>
        The current request arguments used are the following (<i>depth</i>
        and<i> left-pad</i> are hardcoded in the early prototype but do
        match the visual type and the protocol specifications):<br>
        <font face="monospace">  (xrp-put-image:set-format!         rb
          (byte->byte-string 2)) ; 0 bitmap 1 xypixmap 2 zpixmap<br>
            (xrp-put-image:set-depth!          rb (byte->byte-string
          8))<br>
            (xrp-put-image:set-left-pad!       rb (byte->byte-string
          0)) ; 0 for zpixmap pp.55<br>
            (xrp-put-image:set-drawable!       rb drawable)<br>
            (xrp-put-image:set-gc!             rb gc)<br>
            (xrp-put-image:set-dst-x!          rb
          (number+sign->byte-string-2 dst-x))<br>
            (xrp-put-image:set-dst-y!          rb
          (number+sign->byte-string-2 dst-y))<br>
            (xrp-put-image:set-width!          rb
          (number->byte-string-2 width))<br>
            (xrp-put-image:set-height!         rb
          (number->byte-string-2 height))<br>
            (xrp-put-image:set-request-length! rb
          (number->byte-string-2 (/ (+ rl (byte-string-length pad))
          4)))<br>
            (X-request connection (byte-string-adjoin rb pixel pad)
          no-response)<br>
        </font><br>
        No matter how the window, the pixmap and the graphics context
        are associated this request currently always results in a match
        error event.<br>
        <br>
        Regards,<br>
        Michael<br>
        <br>
        --<br>
        The Viper System Interface: some sort of pure Scheme<br>
        <br>
        byte strings, brass, name spaces, the Viper Object System <br>
        <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><br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <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>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <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>
    <br>
  </body>
</html>