Bug 19528 - Cairo doesn't support 8-bit pseudocolor visuals
Summary: Cairo doesn't support 8-bit pseudocolor visuals
Status: RESOLVED MOVED
Alias: None
Product: cairo
Classification: Unclassified
Component: general (show other bugs)
Version: 1.0.2
Hardware: All All
: high critical
Assignee: Carl Worth
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on: Tiffany
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-12 23:15 UTC by Shailen
Modified: 2018-08-25 13:59 UTC (History)
47 users (show)

See Also:
i915 platform:
i915 features:


Attachments
fedora9-tightvnc-8bit-TrueColor (46.55 KB, image/jpeg)
2009-01-12 23:21 UTC, Shailen
Details
ubuntu8.04-tightvnc-8bit-TrueColor.png (16.15 KB, image/png)
2009-01-12 23:23 UTC, Shailen
Details

Description Shailen 2009-01-12 23:15:33 UTC
+++ This bug was initially created as a clone of Bug #4945 +++

When trying to run any gtk app (so it seems, due to the pangocairo, cairo
dependency) on my Tektronix Xterm, the app crashes as the window attempts to
map. This does not happen on Linux-Linux remote X11 (DISPLAY=host:0.0), just
Linux-Xterm (DISPLAY=xterm:0.0). Below is the stacktrace of running gcalctool,
but every other GTK app I run dies the same way. I first discovered this after
upgrading to dropline-gnome 2.12 and tried to login to the xterm via GDM.


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1226455360 (LWP 17605)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0xb75b435d in fbFetch (pict=0x81faaf8, x=0, y=0, width=10, buffer=0xbfd4fc08)
    at fbcompose.c:2673
#2  0xb75b65b3 in fbCompositeRect (data=0xbfd4fbc0, scanline_buffer=0xbfd4fbe0)
    at fbcompose.c:3565
#3  0xb75b6ba6 in pixman_compositeGeneral (op=PIXMAN_OPERATOR_OVER, 
    pSrc=0x81fabe0, pMask=0x81fa8d8, pDst=0x81faaf8, xSrc=10, ySrc=9, xMask=0, 
    yMask=0, xDst=0, yDst=0, width=10, height=64480) at fbcompose.c:3677
#4  0xb75a7022 in *_cairo_pixman_composite (op=PIXMAN_OPERATOR_OVER, 
    pSrc=0x81fabe0, pMask=0x81fa8d8, pDst=0x81faaf8, xSrc=10, ySrc=9, xMask=0, 
    yMask=0, xDst=0, yDst=0, width=10, height=10) at fbpict.c:1825
#5  0xb758c0d3 in _cairo_image_surface_composite (operator=CAIRO_OPERATOR_OVER, 
    src_pattern=0xbfd56210, mask_pattern=0xbfd55eb0, abstract_dst=0x81fab70, 
    src_x=10, src_y=9, mask_x=0, mask_y=0, dst_x=0, dst_y=0, width=10, height=10)
    at cairo-image-surface.c:605
#6  0xb75919ef in _fallback_composite (operator=CAIRO_OPERATOR_OVER, 
    src=0xbfd56210, mask=0xbfd55eb0, dst=0x81f9c48, src_x=10, src_y=9, mask_x=0, 
    mask_y=0, dst_x=0, dst_y=0, width=10, height=10) at cairo-surface.c:800
#7  0xb759b091 in _cairo_ft_scaled_font_show_glyphs (abstract_font=0x814ecf0, 
    operator=CAIRO_OPERATOR_OVER, pattern=0xbfd56210, surface=0x81f9c48, 
    source_x=10, source_y=9, dest_x=10, dest_y=9, width=10, height=10, 
    glyphs=0x81f9af0, num_glyphs=1) at cairo-ft-font.c:2047
#8  0xb75872dc in _cairo_scaled_font_show_glyphs (scaled_font=0x814ecf0, 
    operator=CAIRO_OPERATOR_OVER, pattern=0xbfd56210, surface=0x81f9c48, 
    source_x=10, source_y=9, dest_x=10, dest_y=9, width=10, height=10, 
    glyphs=0x81f9af0, num_glyphs=1) at cairo-font.c:940
#9  0xb758a8f2 in _cairo_gstate_show_glyphs_draw_func (closure=0xbfd561f0, 
    operator=CAIRO_OPERATOR_OVER, src=0xbfd56210, dst=0x81f9c48, dst_x=0, 
    dst_y=0, extents=0xbfd561e8) at cairo-gstate.c:2053
#10 0xb75893cc in _cairo_gstate_clip_and_composite (clip=0x81fa694, 
    operator=CAIRO_OPERATOR_OVER, src=0xbfd56210, 
    draw_func=0xb758a830 <_cairo_gstate_show_glyphs_draw_func>, 
    draw_closure=0xbfd561f0, dst=0x81f9c48, extents=0xbfd561e8)
    at cairo-gstate.c:1094
#11 0xb758ab0e in _cairo_gstate_show_glyphs (gstate=0x81fa610, 
    glyphs=0xbfd562f0, num_glyphs=1) at cairo-gstate.c:2131
#12 0xb75840ec in cairo_show_glyphs (cr=0x81f9ab8, glyphs=0x0, 
    num_glyphs=136292848) at cairo.c:2158
#13 0xb75bf2bd in pango_cairo_renderer_draw_glyphs (renderer=0x81fa450, 
    font=0x8146b70, glyphs=0x81606e8, x=0, y=0) at pangocairo-render.c:110
#14 0xb748ba18 in pango_renderer_draw_glyphs (renderer=0x81fa450, 
    font=0x8146b70, glyphs=0x81606e8, x=0, y=0) at pango-renderer.c:597
#15 0xb75bf7f4 in pango_cairo_show_glyph_string (cr=0x81f9ab8, font=0x8146b70, 
    glyphs=0x81606e8) at pangocairo-render.c:314
#16 0xb7ae5df9 in gdk_pango_context_get_for_screen ()
   from /usr/lib/libgdk-x11-2.0.so.0
#17 0x081f9ab8 in ?? ()
#18 0x08146b70 in ?? ()
#19 0x081606e8 in ?? ()
#20 0x00000000 in ?? ()
#21 0x40330000 in ?? ()
#22 0xb74720d2 in ?? () from /usr/lib/libpango-1.0.so.0
#23 0xbfd56710 in ?? ()
#24 0xbfd56700 in ?? ()
#25 0xb746ef38 in ?? () from /usr/lib/libpango-1.0.so.0
#26 0xb757ba58 in ?? ()
#27 0x081672f8 in ?? ()
#28 0xb74a2fb0 in ?? () from /usr/lib/libpango-1.0.so.0
#29 0x00000000 in ?? ()
#30 0x081f9e70 in ?? ()
#31 0xbfd56718 in ?? ()
#32 0x081f9ab8 in ?? ()
#33 0x00000014 in ?? ()
#34 0x00000003 in ?? ()
#35 0x00000000 in ?? ()
#36 0xb7a66794 in g_type_check_instance_is_a () from /usr/lib/libgobject-2.0.so.0 
#37 0xb7ac9f00 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#38 0xb7b533a8 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#39 0xb7f5bfd8 in ?? () from /lib/ld-linux.so.2
#40 0x00000001 in ?? ()
#41 0xb757ba58 in ?? ()
#42 0x00000001 in ?? ()
#43 0x08163638 in ?? ()
#44 0xb74a2fb0 in ?? () from /usr/lib/libpango-1.0.so.0
#45 0x081f9e70 in ?? ()
#46 0x081f9e70 in ?? ()
#47 0xbfd56738 in ?? ()
#48 0xb74a2fb0 in ?? () from /usr/lib/libpango-1.0.so.0
#49 0x081f9e70 in ?? ()
#50 0x081f9e70 in ?? ()
#51 0xbfd56758 in ?? ()
#52 0xb748ba18 in pango_renderer_draw_glyphs (renderer=0x81606e8, 
    font=0x8128b68, glyphs=0x811ff68, x=135520048, y=0) at pango-renderer.c:597
Comment 1 Shailen 2009-01-12 23:18:52 UTC
Tried creating a 8 bit TruelColor VNC session on a Fedora 9 machine
( cairo-1.6.4-1) and Ubuntu 8.04 machine ( libcairo2 -
1.6.0-0ubuntu2), however I couldn't create as even specifying class
TrueColor in command line ( vncserver -depth 8 -pixelformat BGR233 -cc
4) goes ahead and create 8 bit PseudoColor session. Removing vncserver
4.1.2 and installing tightvncserver enabled me to create a 8 bit
TrueColor session. However everything went pink as can be seen in
attachments.

The build used is Cairo 1.6.4
Comment 2 Shailen 2009-01-12 23:21:56 UTC
Created attachment 21923 [details]
fedora9-tightvnc-8bit-TrueColor
Comment 3 Shailen 2009-01-12 23:23:24 UTC
Created attachment 21924 [details]
ubuntu8.04-tightvnc-8bit-TrueColor.png
Comment 4 Shailen 2009-01-12 23:26:55 UTC
Also the similar behavior is observed while running Mozilla Firefox on AIX platform.
Comment 5 Chris Wilson 2009-01-24 10:15:16 UTC
Hmm, the stack trace indicates an extremely old stack, pixman has not looked like that for a very long time...

I can't reproduce the strange behaviour running under low bit-depths. The only suspicion I have there is that magenta is often used to indicate some failure along some of the compositing paths.

Can you try updating both cairo and pixman to see if the bug is still present in the current stable releases?
Comment 6 Shailen 2009-04-06 22:31:17 UTC
Hi Chris Wilson,

    I have upgraded the cairo to 1.8.6 and pixman to 0.12.0-1 on my AIX
machine.

    I have attached the screen shot of the browser window in my previous
email and it is coming very pinkish if it is 8 bit vnc.


   Can you please let me know why this might be happening ?

Thanks,
Shailendra

On Mon, Apr 6, 2009 at 6:33 PM, Shailendra Jain <shailen.n.jain@gmail.com>wrote:

> Hi Chris Wilson,
>
>     I have upgraded the cairo to 1.8.6 and pixman to 0.12.0-1 on my AIX
> machine.
>
>     Please find attached the screen shot of the browser window and it is
> coming very pinkish if it is 8 bit vnc.
>
>
>    Can you please let me know why this might be happening ?
>
> regards,
> Shailendra
>
>
>
>
>
> On Sat, Jan 24, 2009 at 11:45 PM, <bugzilla-daemon@freedesktop.org> wrote:
>
>> http://bugs.freedesktop.org/show_bug.cgi?id=19528
>>
>>
>> Chris Wilson <chris@chris-wilson.co.uk> changed:
>>
>>           What    |Removed                     |Added
>>
>> ----------------------------------------------------------------------------
>>           Keywords|patch                       |
>>
>>
>>
>>
>> --- Comment #5 from Chris Wilson <chris@chris-wilson.co.uk>  2009-01-24
>> 10:15:16 PST ---
>> Hmm, the stack trace indicates an extremely old stack, pixman has not
>> looked
>> like that for a very long time...
>>
>> I can't reproduce the strange behaviour running under low bit-depths. The
>> only
>> suspicion I have there is that magenta is often used to indicate some
>> failure
>> along some of the compositing paths.
>>
>> Can you try updating both cairo and pixman to see if the bug is still
>> present
>> in the current stable releases?
>>
>>
>> --
>> Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
>> ------- You are receiving this mail because: -------
>> You reported the bug.
>>
>
>
Comment 7 GitLab Migration User 2018-08-25 13:59:38 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/303.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.