Problems Implementing GetImage / PutImage Requests (SCA/X)

[Michael Titke]

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!



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
>> https://launchpad.net/viper-system-interface
>>
>>
>> _______________________________________________
>> xorg at lists.x.org: X.Org support
>> Archives:http://lists.freedesktop.org/archives/xorg
>> Info:https://lists.x.org/mailman/listinfo/xorg
>> Your subscription address: %(user_address)s
>
>
>
> _______________________________________________
> xorg at lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20160803/e8ccb8aa/attachment.html>