Find a file
Jaya Tiwari a3da4e8c60 Replace valueparam with switch-bitcase in Xproto
Hi Chris, Vincent,

Thankyou for the comments.
I have rearranged the pad position in the patch below.

CreateWindow
ChangeWindowAttributes
ConfigureWindow
CreateGC
ChangeGC
ChangeKeyboardControl

The changes of valueparam to switch has been made as per the specs for
the extension for the possible values of value-mask and value-list

CreateWindow:
http://cgit.freedesktop.org/xorg/proto/xproto/tree/specs/encoding.xml#n979

ChangeWindowAttributes:
http://cgit.freedesktop.org/xorg/proto/xproto/tree/specs/encoding.xml#n1006

ConfigureWindow:
http://cgit.freedesktop.org/xorg/proto/xproto/tree/specs/encoding.xml#n1105

CreateGC:
http://cgit.freedesktop.org/xorg/proto/xproto/tree/specs/encoding.xml#n1815

ChangeGC:
http://cgit.freedesktop.org/xorg/proto/xproto/tree/specs/encoding.xml#n1909

ChangeKeyboardControl:
http://cgit.freedesktop.org/xorg/proto/xproto/tree/specs/encoding.xml#n2547

Casted KEYCODE32 as a CARD32 and added BOOL32 here instead of glx due
common to usage in other extensions.

Signed-off-by: Jaya Tiwari <tiwari.jaya18@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
Tested-by: Jaya Tiwari <tiwari.jaya18@gmail.com>
Tested-by: Christian Linhart <chris@demorecorder.com>

Comments by the reviewer Christian Linhart:

This will be API and ABI compatible for the same reasons as
your patch for the Render-extension.

I have checked this against the spec and implementation
and have not found any bugs.

Here are some explanations on how to overcome some difficulties
on reading the spec and the implementation.

The protocol specification is in some way misleading
and self-contradicting, but this can be resolved by
looking at the implementation.

Here are some problems with the spec:
The size of the whole value list is correctly described in
    http://cgit.freedesktop.org/xorg/proto/xproto/tree/specs/encoding.xml?id=xproto-7.0.26
as
    4n     LISTofVALUE                    value-list
i.e. 4 bytes per value, where n is the number of bits set in the mask.

But some of the values themselves are describe incorrectly,
e.g. BITGRAVITY is described as 1 byte value.
This is not correct for two reasons:
* it contradicts LISTofVALUE ( except if implicit padding to 4 byte boundary after each value is assumed )
* even if implicit 4-byte padding is assumed, this contradicts the Xlib implementation in
    http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/Window.c?id=libX11-1.6.2#n55
    where bit_gravity is assigned to an value of type "unsigned long", which is a 32-bit value
    that's then sent verbatim to the server.
    Depending on byte-order this is not the same as a 1-byte BOOL and a 3 byte padding.

 * The server also treats BITGRAVITY as a 32-bit value.
   There, all values from the value list are treated as values of type XID,
    which is also 32 bit.
    The protocol data is cast to an array of XID.
    http://cgit.freedesktop.org/xorg/xserver/tree/dix/dispatch.c?id=xorg-server-1.16.3#n648

    Later, a XID* is first dereferenced and then cast to an 8-bit type ( CARD8 ).
    http://cgit.freedesktop.org/xorg/xserver/tree/dix/window.c?id=xorg-server-1.16.3#n1195
    Please not that it is first dereferenced. Therefore a 32-bit value is retrieved from the given data.
    Only after that it is cast to 8-bit, so that the least-significant 8 bits are taken.
    That's not the same a 1 byte value plus 3 byte padding depending on byteorder.

Maybe the spec should be changed, so that all values of the valuelist are
described as 4 byte?

***

Thank you for writing this testcase.

I have checked this with respect to ABI and API compatibility and the result was the same for me, too.

I.e. this confirms that your patches for xproto are ABI and API compatible. ( as far as a testcase can show correctness of course... )

So, we can add Tested-by: headers with your and my name to your changes for "xproto", when merging them upstream.
Your changes for "render" were tested by Asalle and me, so we can add appropriate Tested-by: headers there, too.
The other changes follow the same pattern and are reviewed, so we probably do not need to test them separately.

Thank you for the testcase and your patches.
2015-02-22 08:46:16 +01:00
doc xcb-doc: add paramref 2014-11-03 11:23:23 +01:00
src Replace valueparam with switch-bitcase in Xproto 2015-02-22 08:46:16 +01:00
xcbgen xcbgen: support paramref in the parser 2014-11-03 11:23:23 +01:00
.gitignore Add py-compile to .gitignore 2009-09-22 16:08:11 -04:00
autogen.sh autogen.sh: Implement GNOME Build API 2013-01-16 13:20:49 -05:00
configure.ac Release xcb-proto 1.11 2014-08-01 15:43:15 +02:00
COPYING Fix the year in the other COPYING. 2006-04-27 17:58:37 -07:00
HACKING Add note on pretty patches and src/.gitattributes 2013-11-14 20:23:24 +09:00
INSTALL Remove xcl and CVSROOT. 2006-02-18 16:49:41 -08:00
Makefile.am Add autogen.sh to EXTRA_DIST. 2012-02-10 17:44:33 +09:00
NEWS Release xcb-proto 1.11 2014-08-01 15:43:15 +02:00
README Add Python parser language-independent parts. 2008-04-19 04:30:21 -04:00
TODO Add test program for XFree86-DRI extension to xcb-demo. Mark XFree86-DRI extension as tested and working. 2006-04-27 14:14:54 -07:00
xcb-proto.pc.in add libdir/exec_prefix to xcb-xproto.pc 2011-11-10 15:36:54 +01:00

About xcb-proto
===============

xcb-proto provides the XML-XCB protocol descriptions that libxcb uses to
generate the majority of its code and API. We provide them separately
from libxcb to allow reuse by other projects, such as additional
language bindings, protocol dissectors, or documentation generators.

This separation between the XCB transport layer and the
automatically-generated protocol layer also makes it far easier to write
new extensions. With the Xlib infrastructure, client-side support for
new extensions requires significant duplication of effort. With XCB and
the XML-XCB protocol descriptions, client-side support for a new
extension requires only an XML description of the extension, and not a
single line of code.

Python libraries: xcb-proto also contains language-independent Python
libraries that are used to parse an XML description and create objects
used by Python code generators in individual language bindings.  These
libraries are installed into $(prefix)/lib/pythonX.X/site-packages.  If
this location is not on your system's Python path, scripts that import
them will fail with import errors.  In this case you must add the
install location to your Python path by creating a file with a `.pth'
extension in a directory that _is_ on the Python path, and put the
path to the install location in that file.  For example, on my system
there is a file named 'local.pth' in /usr/lib/python2.5/site-packages,
which contains '/usr/local/lib/python2.5/site-packages'.  Note that 
this is only necessary on machines where XCB is being built. 

Please report any issues you find to the freedesktop.org bug tracker,
at:

	<https://bugs.freedesktop.org/enter_bug.cgi?product=XCB>

Discussion about XCB occurs on the XCB mailing list:

        <mailto:xcb at lists.freedesktop.org>
        <http://lists.freedesktop.org/mailman/listinfo/xcb>

You can obtain the latest development versions of XCB using GIT.
For anonymous checkouts, use:

        git clone git://anongit.freedesktop.org/git/xcb/proto

For developers, use:

        git clone git+ssh://git.freedesktop.org/git/xcb/proto