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
_______________________________________________
[email protected]: X.Org support
Archives:http://lists.freedesktop.org/archives/xorg
Info:https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
_______________________________________________
[email protected]: X.Org support
Archives:http://lists.freedesktop.org/archives/xorg
Info:https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
_______________________________________________
[email protected]: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
_______________________________________________
[email protected]: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
