[Xcb] X server bug on BIG-REQUESTS?

[Barton C Massey]

Oh, got it.  I was still confused about the bug---thanks for
clearing it up.  Bleah.

As you say, the original code was probably set up to never
trigger BIGREQUESTS for images, so these cases were never
tested.   Our util code could do the same, but it seems
right to use BIGREQUESTS on servers that claim to support
it; as you say, we divide by four, I guess, as a workaround.

We'll talk it all over upon my return.

	Bart

In message <20060611071555.GN4245 at id.minilop.net> you wrote:
> 
> --===============0907819407==
> Content-Type: multipart/signed; micalg=pgp-sha1;
> 	protocol="application/pgp-signature"; boundary="qjSZefE6w0iW6XmQ"
> Content-Disposition: inline
> 
> 
> --qjSZefE6w0iW6XmQ
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Sat, Jun 10, 2006 at 11:27:43PM -0700, Barton C Massey wrote:
> > In message <20060611003721.GL4245 at id.minilop.net> you wrote:
> > > I'm not sure exactly what you mean by this. We can have
> > > XCBGetMaximumRequestLength divide the value returned from
> > > BigRequestsEnable by four, which seems likely to work on all
> > > servers.
> >=20
> > I think XCBGetMaximumRequestLength should return 1MB on
> > servers without BIGREQUESTS, and its normal value otherwise?
> > When a request of eg 1.1MB is sent, it should be sent using
> > BIGREQUESTS, which is legal AFAIK.
> 
> If you replace "servers without BIGREQUESTS" with "servers *with*
> BIGREQUESTS", I think you've got the right idea. The sad thing is that
> it's the common case that's broken.
> 
> Without BIG-REQUESTS, the largest theoretically possible request is
> 256kB, and the server can advertise a limit smaller than that. That case
> may or may not be broken here, but in any case is not the one in
> question. (I think the fact that nobody has ever seen this problem
> before suggests that the non-big case is fine.)
> 
> With BIG-REQUESTS, a request could theoretically be as big as 16GB, but
> again the server can advertise a limit smaller than that, and in this
> case it advertises 16MB instead. The actual value reported is in 4-byte
> units, though, hence that ~4 million number we've been tossing around.
> What we're seeing is that we can't hit that 16MB limit because things
> fail at 4MB, which is suspicious.
> 
> > > There's a separate problem that callers, including
> > > the XCBImage library, need to split large data into smaller
> > > chunks.
> >=20
> > Won't they do this automatically if we do the above?
> 
> There's nothing to guarantee that they will. The XCBImage library may
> have the machinery for it ported from the original XImage
> implementation; I haven't checked. But I doubt it: the original
> implementation was coded to never trigger a BIG-REQUEST at all.
> 
> --Jamey
> 
> --qjSZefE6w0iW6XmQ
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: Digital signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> 
> iD8DBQFEi8Mrp1aplQ4I9mURAjeZAJ99snRPjsCR3sXBGAO9ERwaxKN3XwCfaNDQ
> 8QVF+u50D0AlTHbCLrDYUgE=
> =P/c2
> -----END PGP SIGNATURE-----
> 
> --qjSZefE6w0iW6XmQ--
> 
> --===============0907819407==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb
> --===============0907819407==--