Problems Implementing GetImage / PutImage Requests (SCA/X)

Michael Titke michael.tiedtke at o2online.de
Thu Aug 4 08:20:09 UTC 2016 

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!? ;-)


On 03/08/2016 19:48, Michael Titke wrote:
> 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
>
>
>
> _______________________________________________
> 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/20160804/f4b8ddac/attachment-0001.html>

More information about the xorg mailing list