340683 - Since cairo update, 16bpp does not work in Linux

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

since this bug doesn't have any details on how it doesn't work, I'm assuming that my 32-bit linux problem is the same.

The issue is that _cairo_format_from_pixman_format returns -1 for the 16bpp format given to it, leading to an assertion failure in:
#4  0x008eacbe in _cairo_content_from_format (format=4294967295)
    at /home/chb/mozilla/gfx/cairo/cairo/src/cairo-image-surface.c:402

The caller here is _cairo_xlib_surface_acquire_dest_image some frames down.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Looks like the same problem.
The stack trace from a 64bit Linux is in bug 340452.

Comment 3

[Boris Zbarsky [:bzbarsky]]

So is the upshot that we just crash on startup on 16bpp or 32bpp systems?

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

I don't know how the visuals for 32bpp look, but yeah, we do crash on startup on 16bpp ones.

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

We fixed this at one point, but some stuff got changed in the xlib cairo code; I'll fix it again tomorrow and make sure it gets into cairo mainline.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #5)
> We fixed this at one point, but some stuff got changed in the xlib cairo code;
> I'll fix it again tomorrow and make sure it gets into cairo mainline.

nm, this isn't the same bug.  So I can't reproduce this -- is there some specific configuration that I need to hit this?  I'm running trunk with cairo in a 16bpp visual inside Xvnc just fine, so there must be something more.  Can you provide xdpyinfo output?

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: my xpdyinfo output

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Ah, I'm guessing it's the combination of 16bpp + RENDER availability that's doing it.  Xvnc doesn't advertise RENDER.  Looking more..

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

I should note maybe... I'm using Xorg 6.8.2, render version is 0.9, this means that buggy_repeat is 1 (true).

Comment 10

[Stuart Parmenter]

is this still true?

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

I would test but I can't until oct 12 or so

Comment 12

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I can't reproduce this, using xorg 7.0.0 running in 16bpp mode direct on a display (pixmap formats supported range from 1 to 32, RENDER is present, and the screen #0 depths show up as 16,1,4,8,15,24,32.  So I think think that this is fixed.