[Xcb] X server bug on BIG-REQUESTS?

[Ian Osgood]

In the meantime, has this been written up in bugzilla?

There is already an old bug proposing BIGREQUESTS
be used in XPutImage:

   https://bugs.freedesktop.org/show_bug.cgi?id=554

Ian

On Jun 11, 2006, at 1:00 AM, Barton C Massey wrote:

> 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==--
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb
>