Problems Implementing GetImage / PutImage Requests (SCA/X)

[Michael Titke]

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

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