Problems Implementing GetImage / PutImage Requests (SCA/X)

Michael Titke michael.tiedtke at
Wed Aug 3 17:48:35 UTC 2016

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 
;;           in each scanline is the width.
;; (Scanline bits-per-pixel ... (padding bits-per-pixel=1 (|+| width 
;; 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.
ProcPutImage(ClientPtr client)

That much effort to keep that much effort of processing bits and bytes 
and historical reviews of bits and bytes. Wow!

On 03/08/2016 13:52, Michael Titke wrote:
> 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!
> On 02/08/2016 13:02, Michael Titke wrote:
>> 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
>> _______________________________________________
>> xorg at X.Org support
>> Archives:
>> Info:
>> Your subscription address: %(user_address)s
> _______________________________________________
> xorg at X.Org support
> Archives:
> Info:
> Your subscription address: %(user_address)s

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the xorg mailing list