[Xcb] Xlib/XCB test results

[Barton C Massey]

Wow.  This is too cool.

Let's schedule a PDX X hacking session soon to help you fix
these bugs, if you like.

	Bart

In message <1126124291.14894.87.camel at localhost> you wrote:
> 
> --===============1467502715==
> Content-Type: multipart/signed; micalg=pgp-sha1;
> 	protocol="application/pgp-signature";
> 	boundary="=-jBVLx6LBLJ1jnd2Z+ZMv"
> 
> 
> --=-jBVLx6LBLJ1jnd2Z+ZMv
> Content-Type: multipart/mixed; boundary="=-j1RqbzQjOoQRE1rzQARp"
> 
> 
> --=-j1RqbzQjOoQRE1rzQARp
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
> 
> Hey all!
> 
> Thanks to Carl and Jeremy for fixing the list. The timing is perfect: I
> have something to say today. :-)
> 
> I have results from running the new X Test Suite against both stock Xlib
> and against Xlib/XCB. Some of you have heard early results, on the order
> of 60 FAILs or so against both versions of Xlib: I'm pleased to report
> that fixing a bunch of issues with my installation of the test suite
> fonts fixed most of those problems.
> 
> My test setup is as follows.
>       * I'm running the kdrive Xfake server, from May 4th CVS.
>       * The reference Xlib is the Debian version from X.org 6.8.2.
>       * Xlib/XCB is from CVS as of May 15th.
>       * XCB is from CVS as of July 21st.
>       * The X Test Suite is from X.org's XTS5 CVS as of July 19th.
> 
> After fixing the tet_fork test suite bug Keith and I looked at a few
> weeks ago[1], Xlib/XCB no longer has any assertion failures under the
> test suite, and several cascading FAILs are gone.
> 
> Now the test results are identical with these exceptions:
>       * 6 FAILs in Xlib/XCB are not present in Xlib;
>       * 2 FAILs in Xlib are not present in Xlib/XCB;
>       * 1 PASS under Xlib is UNTESTED under Xlib/XCB, namely XFlush test
>         purpose #1 in section Xlib12.
> 
> 4 of the FAILs unique to XCB look like identical bugs in X error
> handling. I'm not sure yet whether the fault is in Xlib or in XCB.
> 
> The UNTESTED and one of the FAILs look like they might be caused by the
> test suite trying to muck around in the Display's output queue directly.
> It tries to queue a request, then remove the request from the queue. I
> don't think these tests are ever going to pass under XCB, because if
> they succeeded at removing the queued requests then the sequence numbers
> would be wrong and the usual assertions would fail. The fact that one of
> the tests in this category reports FAIL in this case is probably a test
> suite bug, as it makes assumptions about the implementation of Xlib that
> are not supported by the specification.
> 
> That leaves one FAIL that I don't understand. The output says:
> 	REPORT: XCloseDisplay() did not ungrab the server.
> This could be a bug in the test suite, Xlib, *or* XCB, and I don't know
> which. I doubt it's XCB's fault, though.
> 
> The two FAILs that XCB "fixes" are funny. I can't explain them, which
> worries me a little. Of course, I'm not going to complain... :-)
> 
> I've attached the differences between the reference Xlib test results
> and the Xlib/XCB test results, cleaned up slightly to make them easier
> to read.
> 
> So there we go. Looks like I have to fix two Xlib/XCB bugs and a test
> suite bug, and then Xlib/XCB will be ready to go. (I'm still not ready
> to release XCB itself though, and both have to be ready before this work
> can be considered for a future release of X.org.)
> 
> --Jamey
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=3D4387
> 
> --=-j1RqbzQjOoQRE1rzQARp
> Content-Description: differences between X Test Suite results for Xlib and
> 	Xlib/XCB
> Content-Disposition: attachment; filename=xcb.diff
> Content-Type: text/x-patch; charset=UTF-8
> Content-Transfer-Encoding: base64
> 
> LS0tIHJlc3VsdHMveGxpYi9ycHQJMjAwNS0wOS0wNyAwOTozNDoyNC4wMDAwMDAwMDAgLTA3MDAN
> CisrKyByZXN1bHRzL3hjYi9ycHQJMjAwNS0wOS0wNyAxMTo0ODo1MS4wMDAwMDAwMDAgLTA3MDAN
> CkBAIC0zLDYgKzMsMjggQEANCiANCiBTRUNUSU9OOiBYbGliMw0KIA0KK1RFU1QgQ0FTRTogWENs
> b3NlRGlzcGxheQ0KKw0KK1RFU1QgUFVSUE9TRSAjNg0KK0Fzc2VydGlvbiBYQ2xvc2VEaXNwbGF5
> LTYuKEEpDQorV2hlbiB0aGUgY2xpZW50IGhhcyBncmFiYmVkIHRoZSBzZXJ2ZXIsIHRoZW4gYSBj
> YWxsIHRvDQorWENsb3NlRGlzcGxheSBwZXJmb3JtcyBhIFhVbmdyYWJTZXJ2ZXIuDQorTUVUSDog
> Q3JlYXRlIGEgY29ubmVjdGlvbiBmb3IgY2xpZW50MSB1c2luZyBYT3BlbkRpc3BsYXkuDQorTUVU
> SDogQ3JlYXRlIGEgY29ubmVjdGlvbiBmb3IgY2xpZW50MiB1c2luZyBYT3BlbkRpc3BsYXkuDQor
> TUVUSDogQ3JlYXRlIGEgY29ubmVjdGlvbiBmb3IgY2xpZW50MyB1c2luZyBYT3BlbkRpc3BsYXku
> DQorTUVUSDogQ3JlYXRlIGEgd2luZG93IHVzaW5nIFhDcmVhdGVXaW5kb3cuDQorTUVUSDogR3Jh
> YiB0aGUgc2VydmVyIGZvciB0aGUgZGVmYXVsdCBkaXNwbGF5IHVzaW5nIFhHcmFiU2VydmVyLg0K
> K01FVEg6IENyZWF0ZSBhIHByb2Nlc3MgdXNpbmcgdGV0X2ZvcmsuDQorTUVUSDogSW4gY2hpbGQg
> cHJvY2VzczoNCitNRVRIOiAgICBHZW5lcmF0ZSBhIENoYW5nZVByb3BlcnR5IHJlcXVlc3QgYXMg
> Y2xpZW50MyB1c2luZyBYQ2hhbmdlUHJvcGVydHkuDQorTUVUSDogV2FpdCBzdWZmaWNpZW50IHRp
> bWUgZm9yIHRoZSBDaGFuZ2VQcm9wZXJ0eSByZXF1ZXN0IHRvIGJlIHByb2Nlc3NlZC4NCitNRVRI
> OiBWZXJpZnkgYXMgY2xpZW50MSB0aGF0IG5vIFByb3BlcnR5Q2hhbmdlIGV2ZW50IGhhcyBiZWVu
> IGdlbmVyYXRlZCBieSBjbGllbnQzIHVzaW5nIFhDaGVja1dpbmRvd0V2ZW50Lg0KK01FVEg6IENs
> b3NlIHRoZSBjbGllbnQxIGNvbm5lY3Rpb24gdXNpbmcgWENsb3NlRGlzcGxheS4NCitNRVRIOiBX
> YWl0IHN1ZmZpZW50IHRpbWUgZm9yIHRoZSBDaGFuZ2VQcm9wZXJ0eSByZXF1ZXN0IHRvIGJlIHBy
> b2Nlc3NlZC4NCitNRVRIOiBWZXJpZnkgYXMgY2xpZW50MiB0aGF0IGEgQ2hhbmdlUHJvcGVydHkg
> cmVxdWVzdCB3YXMgZ2VuZXJhdGVkIGJ5IGNsaWVudDMuDQorUkVQT1JUOiBYQ2xvc2VEaXNwbGF5
> KCkgZGlkIG5vdCB1bmdyYWIgdGhlIHNlcnZlci4NCis2IEZBSUwNCisNCiBURVNUIENBU0U6IFhN
> aW5DbWFwc09mU2NyZWVuDQogDQogVEVTVCBQVVJQT1NFICMxDQpAQCAtMzksMjYgKzYxLDYgQEAN
> CiBSRVBPUlQ6IEdDIHJlc291cmNlIHdhcyBub3QgZGVzdHJveWVkDQogMSBGQUlMDQogDQotVEVT