[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-xorg
Subject: Re: Problems Implementing GetImage / PutImage Requests (SCA/X)
From: Michael Titke <michael.tiedtke () o2online ! de>
Date: 2016-08-04 8:20:09
Message-ID: 57A2FAB9.10101 () o2online ! de
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@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@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
[Attachment #5 (text/html)]
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Documenting another XII lock picking approach: new padding "rules"
for SCA/X<br>
<br>
<font face="monospace">(define (round-up num-bytes pad)<br>
(* (quotient (+ (- num-bytes 1) pad) pad) pad))<br>
<br>
(define (round-up/lynx num-bytes pad)<br>
(byte-string->number<br>
(bit-and (number->byte-string-8 (+ num-bytes (- pad 1)))<br>
(bit-not (number->byte-string-8 (- pad 1))))))<br>
<br>
(define (padded4 num-bytes) (byte-string->number<br>
(bit-shift-right (number->byte-string-8 (+ num-bytes 3)) 2)))<br>
<br>
(define (X-pad num-bytes) (make-byte-string (- (round-up num-bytes
4) num-bytes)))<br>
<br>
...<br>
(let*<br>
(rl (+ (byte-string-length rb) (padded4
(byte-string-length pixel))))<br>
(pad (X-pad rl))) ...<br>
<br>
</font><br>
No error, no window. Just another ...<br>
<br>
BTW <br>
VSI GIO SCA/X big requests: maximum request size 4194303<br>
<br>
yes, that's four million not 16GB. That's our brand new 16MB limit
... maths!? ;-)<br>
<br>
<br>
<div class="moz-cite-prefix">On 03/08/2016 19:48, Michael Titke
wrote:<br>
</div>
<blockquote cite="mid:57A22E73.20003@o2online.de" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<font face="monospace">After some "research" into the bad length
issue I was finally able to shed some light on how to use<br>
the information from the connection setup. ;-)<br>
<br>
;; ;; ;; Graphical Viper System Interface<br>
;; ;; ;; ;; Input SCA/X<br>
;; ;; ;; ;; ;; Output Viper Object System<br>
;; ;; ;; <br>
<br>
;;<br>
;; Z Pixmap: the number of scanlines is the /height/ and the
number of pixels<br>
;; in each scanline is the width.<br>
;; (Scanline bits-per-pixel ... (padding bits-per-pixel=1 (|+|
width bitmap-scanline-pad)))<br>
;;<br>
;; scanline-pad, bits-per-pixel are found via the /format/ of
the /depth/<br>
;;<br>
;; (Maybe doesn't apply to z pixmap formats bitmap-scanline-unit
from the Display)<br>
;;<br>
<br>
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)<br>
are sent over the wire (with big requests or not) it always
results in a length error.<br>
<br>
Additionally in the server sources dix/dispatch.c knows about
the following:<br>
<br>
/* 64-bit server notes: the protocol restricts padding of images
to<br>
* 8-, 16-, or 32-bits. We would like to have 64-bits for the
server<br>
* to use internally. Removes need for internal alignment
checking.<br>
* All of the PutImage functions could be changed individually,
but<br>
* as currently written, they call other routines which require
things<br>
* to be 64-bit padded on scanlines, so we changed things here.<br>
* If an image would be padded differently for 64- versus 32-,
then<br>
* copy each scanline to a 64-bit padded scanline.<br>
* Also, we need to make sure that the image is aligned on a
64-bit<br>
* boundary, even if the scanlines are padded to our
satisfaction.<br>
*/<br>
int<br>
ProcPutImage(ClientPtr client)<br>
{<br>
...<br>
<br>
That much effort to keep that much effort of processing bits and
bytes and historical reviews of bits and bytes. Wow!<br>
<br>
</font><br>
<br>
<div class="moz-cite-prefix">On 03/08/2016 13:52, Michael Titke
wrote:<br>
</div>
<blockquote cite="mid:57A1DB00.4020806@o2online.de" type="cite">
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
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<br>
but maybe padding strictness is server side only. ;-) Have Fun!<br>
<br>
<div class="moz-cite-prefix">On 02/08/2016 13:02, Michael Titke
wrote:<br>
</div>
<blockquote cite="mid:57A07DBF.2050606@o2online.de" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
Hello!<br>
<br>
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).<br>
<br>
The early pixmap support fails for the <i>GetImage</i> and <i>PutImage</i>
requests: <i>GetImage</i> provokes and <i>undefined</i>
error from the X server where <i>PutImage</i> always seems to
result in a match error. My question to the experienced ones:
what are the prerequisites especially for <i>PutImage</i>? 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.)<br>
<br>
Maybe some extension provides better means to achieve the
following task which serves as an example to guide development
of GIO and SCA/X:<br>
1) a matrix of exact color vectors is converted to a pixel
array (should equal Zpixmap) and it should be displayed in a
window.<br>
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<br>
<br>
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.<br>
<br>
The current request arguments used are the following (<i>depth</i>
and<i> left-pad</i> are hardcoded in the early prototype but
do match the visual type and the protocol specifications):<br>
<font face="monospace"> (xrp-put-image:set-format! rb
(byte->byte-string 2)) ; 0 bitmap 1 xypixmap 2 zpixmap<br>
(xrp-put-image:set-depth! rb
(byte->byte-string 8))<br>
(xrp-put-image:set-left-pad! rb
(byte->byte-string 0)) ; 0 for zpixmap pp.55<br>
(xrp-put-image:set-drawable! rb drawable)<br>
(xrp-put-image:set-gc! rb gc)<br>
(xrp-put-image:set-dst-x! rb
(number+sign->byte-string-2 dst-x))<br>
(xrp-put-image:set-dst-y! rb
(number+sign->byte-string-2 dst-y))<br>
(xrp-put-image:set-width! rb
(number->byte-string-2 width))<br>
(xrp-put-image:set-height! rb
(number->byte-string-2 height))<br>
(xrp-put-image:set-request-length! rb
(number->byte-string-2 (/ (+ rl (byte-string-length pad))
4)))<br>
(X-request connection (byte-string-adjoin rb pixel pad)
no-response)<br>
</font><br>
No matter how the window, the pixmap and the graphics context
are associated this request currently always results in a
match error event.<br>
<br>
Regards,<br>
Michael<br>
<br>
--<br>
The Viper System Interface: some sort of pure Scheme<br>
<br>
byte strings, brass, name spaces, the Viper Object System <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://launchpad.net/viper-system-interface">https://launchpad.net/viper-system-interface</a><br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" \
href="mailto:xorg@lists.x.org">xorg@lists.x.org</a>: X.Org support
Archives: <a moz-do-not-send="true" class="moz-txt-link-freetext" \
href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a>
Info: <a moz-do-not-send="true" class="moz-txt-link-freetext" \
href="https://lists.x.org/mailman/listinfo/xorg">https://lists.x.org/mailman/listinfo/xorg</a>
Your subscription address: %(user_address)s</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" \
href="mailto:xorg@lists.x.org">xorg@lists.x.org</a>: X.Org support
Archives: <a moz-do-not-send="true" class="moz-txt-link-freetext" \
href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a>
Info: <a moz-do-not-send="true" class="moz-txt-link-freetext" \
href="https://lists.x.org/mailman/listinfo/xorg">https://lists.x.org/mailman/listinfo/xorg</a>
Your subscription address: %(user_address)s</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" \
href="mailto:xorg@lists.x.org">xorg@lists.x.org</a>: X.Org support
Archives: <a class="moz-txt-link-freetext" \
href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a>
Info: <a class="moz-txt-link-freetext" \
href="https://lists.x.org/mailman/listinfo/xorg">https://lists.x.org/mailman/listinfo/xorg</a>
Your subscription address: %(user_address)s</pre>
</blockquote>
<br>
</body>
</html>
[Attachment #6 (text/plain)]
_______________________________________________
xorg@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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic