mirror of
https://gitlab.freedesktop.org/xorg/proto/xcbproto.git
synced 2026-05-05 21:38:02 +02:00
read-only mirror of https://gitlab.freedesktop.org/xorg/proto/xcbproto
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. |
||
|---|---|---|
| doc | ||
| src | ||
| xcbgen | ||
| .gitignore | ||
| autogen.sh | ||
| configure.ac | ||
| COPYING | ||
| HACKING | ||
| INSTALL | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
| TODO | ||
| xcb-proto.pc.in | ||
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