How to convert ZPixMap to BGRA reliably?

Sai Prasanna sai.r.prasanna at gmail.com
Fri Aug 25 12:55:41 UTC 2017


I want to get the same values as got by using XGetImage for red_mask,
blue_mask and green_mask in xcb.

Here is m C-go lang code.

I am iterating on the screen got from xcb_setup_roots_iterator .

for depthIter := C.xcb_screen_allowed_depths_iterator(cx.screen);
depthIter.rem != 0; C.xcb_depth_next(&depthIter) {
        d := depthIter.data
        for visual_iter := C.xcb_depth_visuals_iterator(d); visual_iter.rem
!= 0; C.xcb_visualtype_next(&visual_iter) {
            v := visual_iter.data
            fmt.Printf("MASKS %x, %x, %x", v.red_mask, v.green_mask,
v.blue_mask)
        }
    }

Which Depth and Visual Id should I select for getting correct masks ?

On Wed, Aug 23, 2017 at 6:47 PM, Ilya Anfimov <ilan at tzirechnoy.com> wrote:

> On Tue, Aug 22, 2017 at 11:39:26AM +0530, Sai Prasanna wrote:
> >    I thought Zpixmap mapped directly to BGRA. But my assumption didn't
> turn
> >    out to be correct in some older X versions.
> >
> >    I am using xcb_get_image and xcb_shm_get_image to grab screen pixels.
> I
> >    used Zpixmap option for image format. In new-ish Xorg versions it
> works
> >    perfectly.
> >
> >    But in some machines with older Xorg (1.15 and below) , I get
> discolored,
> >    overlapped data, and it is less than 4 * width * height bytes. If I
> try to
> >    read with bytes per pixel as 4 , overflow occurs.
> >
> >    Could  this be some environment issue , or is there any other
> "proper" way
> >    to convert Zpixmap to bgra/rgb formats?
>
>  1) The best source of knowledge about core X11 functionality
> is the "X Window System Protocol" book, available e.g. here:
>
>   https://www.x.org/docs/XProtocol/proto.pdf
>
>  2) The general pixel storage of the Z pixmap format is described
> there in section 8 (Connection Setup), "Server  information"  and
> pixel contents -- in "Visual information".
>
>  It  does not need to be 4 bytes per pixel, or even integer bytes
> per pixel. Number of bits per pixel is specified in FORMAT: field
> of  server  connection  setup  response  (and  may  be  taken via
> xcb_get_setup in xcb library).
>  Many X servers round pixel size up to integer number  of  bytes,
> as  it  allows  some shortcuts and speedups in server implementa-
> tion, but not all do that.
>
>  Pixels does not need to be in {pad,r,g,b} format. The masks  for
> red,  green and blue are specified in VISUALTYPE: field of server
> connection setup response. Fortunately, that masks  are  contigu-
> ous,  but  they  don't  need to lay on a byte boundary.  However,
> modern processors don't care much about bit shift  size,  and  it
> does not matter -- shift by 8 bits or 11.
>
>
>  Also,  pixels  will  be in different byte orders as specified by
> image-byte-order: field in server response. You should prepare to
> access  individual  bytes, not integers (or find some other solu-
> tion).
>
>  It  would be good to build you program for something like Debian
> mips architecture (not mips-el!) and check  all  combinations  of
> your program and X server in something like qemu-system-mips.
>
>
>  PS  And  yes,  probably  the most recommended ways to read image
> from X11 is to use some image manipulation library,  like  libgdk
> or imagemagick.
>  The  required  transformations are fairly simple, though, and if
> you are messing with xcb, that it  should  be  really  simple  to
> write a conversion code in like 30-50 lines.
>
>
>
>
> _______________________________________________
> 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/20170825/e2337cf1/attachment.html>


More information about the xorg mailing list