[Xcb] Re: [Xlibs] XCL works for mozilla + acroread/flash plugins, xine, xlsatoms

[Jim Gettys]

Jamey,

You have every right to be excited.  I'm excited too!

My recent work to make connection disconnect recoverable
has taken me into the bowels of the Xlib I wrote
so long ago.  It has *not* been improved in the almost 
15 or so years since it left my hands.  It is *really* ugly.

A viable replacement is high on my list of wants, given my 
inspection of the last few days, which has taken me through 
the bowels of XlibInt.c (which, for example,
is more than 6% #ifdef/#ifndef/#endif lines).

When the time comes, Stuart Kreitman at Sun has offered to put
it through their internal testing cycle, which would be good too.

Keep up the great work!
                          - Jim



On Thu, 2003-11-06 at 01:06, Jamey Sharp wrote:
> Two small fixes and one big one make important stuff work. I've tested
> xine, xlsatoms, and Mozilla with the acroread and Flash plugins, and
> they work. Yay!
> 
> I feel a little silly for getting excited about having an environment
> that everyone else takes for granted. Anyway, new version of my Xlib
> patch at http://freedesktop.org/~jamey/X11-xcb-2.patch . Make sure your
> XCB sources are up to date too.
> 
> First, I fixed parsing of DISPLAY to not clobber its input. This bug
> caused a second connection open in Xine to fail because DISPLAY became
> "". It may have been part of Mozilla's problem too, but I think the
> second bug was the one I was seeing.
> 
> I fixed error handling in _XReply in XCL. XCB will hand back either an
> error or a reply for a given sequence number as long as you give it
> someplace to stick the error. I just had to add a couple of lines to
> make _XReply take advantage of that and call _XError as appropriate.
> Apparently mozilla was making some request that returned an error, but
> it was an error that Xlib ignored. Then I got this fix wrong twice, but
> now that it returns 0 if _XError (or _XIOError, just in case) returns, I
> think it's right. This affected xlsatoms too, which works now.
> 
> Finally, the big fix. XCB uses writev where appropriate now. Previously
> it just gave up if you tried to write any single request bigger than its
> output buffer, which I'd set at 256kB so it would be as big as any
> single request. I had debugging code to make XCB abort() if this
> assumption was violated, 'cause I knew I'd have to fix it eventually.
> Then along comes Xlib with its support for BIG-REQUESTS... :-) So I did
> some testing with a 256 byte output buffer, and things look good.
> 
> Net result: I just updated the XCBToDo topic at fd.o using a Mozilla
> running on top of XCB and re-read my Freenix XCL slides in .pdf format,
> and earlier today I enjoyed a few Strongbad E-mail flash cartoons in the
> same manner.
-- 
Jim Gettys <Jim.Gettys@hp.com>
HP Labs, Cambridge Research Laboratory