[cairo] build now works

[James Cloos]

>>>>> "US" == Uli Schlachter <psychon at znc.in> writes:

First, after re-compiling cairo master with --disable-xlib-xcb
(instead of --enable) everything works fine.

>> ABORT: RenderChangePicture: BadValue (integer parameter out of range
>> for operation); 2838 requests ago: file nsX11ErrorHandler.cpp, line
>> 203

US> This is weird. RenderChangePicture doesn't get an operator as an
US> argument.  I guess this means that the missing operator causes a
US> fallback which avoids the "evil" code path.

US> Could you tell us a little more about your setup? Which versions of
US> things are you using? What exactly do you make gecko do to cause
US> these problems?

Everything FDO is master.  All recompiled again this week on both the
server and client boxen.  That is when the RenderChangePicture errors
and/or server lockups started.  I've used --enable-xlib-xcb for quite
a few months.

The geckos are SM-2.1, FF-3.6, FF-4.0 and FF-5.0 betas.  All compiled
to use the system cairo.

The X server is 32-bit x86; card is a Radeon Mobility M7 LW (r100 class).
The client box is amd64.  Everything is X over tcp, not ssh tunneling.
(The two have a p-t-p ethernet, separate from the main lan.)

US> Could you tell us the results of the following commands?

US> $ xdpyinfo -ext RENDER | grep 'RENDER version'
US> (This should be 0.11)

It is.

US> $ grep VERSION /usr/include/xcb/render.h
US> (I'd expect 0.10 here, xcb-proto was only updated 5 days ago for render 0.11)

0 11 0

Disabling cairo's xlib-xcb also fixed three other anomalies which the
geckos triggered more than any other apps.

The first was that, with SM-2.1 and FF-4.0 or later, elements of the UI
whose css specified 'transparent' rather than 'transparent !important'
rendered black-on-black instead of black on whatever was layered below.

The transparency gets lost somewhere along the way.

The second was that, as VRAM filled (the card only has 64M) some
rectangles of text would scramble.  The rects were one line tall
and usually about 16 or so EMs wide.  Call it about 25×400 px, ±.
Often the scramble was a chunk of text from somewhere else on the
screen, but severely sheared.

(Those last two bugs had been there for the last few months.)

The third is that, with enable-xlib-xcb, adobe's flash plugin will
crash FF 4+.  But it runs OK w/ disable-xlib-xcb.  (That is the 64
bit version with the binary s/memcpy/memmove/ patch.)

It is possible that the 2nd bug was fixed by changes elsewhere (pixman,
xserver, ati driver, dri2, kms?) but I cannot test because of the
RenderChangePicture errors and server lockups....


Everything above said, running with --disable-xlib-xcb, SM just crashed
with a pair of:

 ABORT: Request 146.135: BadRequest (invalid request code or no such
     operation); 3523 requests ago: file nsX11ErrorHandler.cpp, line 203

If 146 is the extension opcode, then that maps to:

    XC-MISC  (opcode: 146)

If it is the base error, then to:

    DOUBLE-BUFFER  (opcode: 135, base error: 146)

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6