| Summary: | Cairo doesn't support 8-bit pseudocolor visuals | ||
|---|---|---|---|
| Product: | cairo | Reporter: | Nate Byrnes <nate.byrnes> |
| Component: | general | Assignee: | Carl Worth <cworth> |
| Status: | RESOLVED FIXED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
| Severity: | critical | ||
| Priority: | high | CC: | anirkko, arbab, ariggs, ashishyadav26, bofh42, borisv, brian.cameron, bugs, cavergines, chris.wang, claude.bonnard, cpalmer, dave, david.meleedy, dmcmahill, don.lawrence, dumitru.sipos, edgar.hoch, eth0, fboiteux, govindarao, hba, jes, joevandyk, jsarlo, kurt, langel, marek.rouchal, mboguski, pesco, philip.groves, pwalsall, rajkumar.david, robert.buick, R.Vickers, sebastien, steve, tcs27, thayes77, tim.w.connors, tk, tom.nelson, ubieto, wcwince, zaphodb, zds |
| Version: | 1.0.2 | Keywords: | patch |
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | ALL | i915 features: | |
| Bug Depends on: | |||
| Bug Blocks: | 5846, 19528 | ||
| Attachments: |
Simple program to demonstrate bug
fix for the 8bit issue + 16 bit. update of Eric Faurot's patch for 1.2.4 Fix of patch #6762 for true color (for cairo-1.2.4) updated patch for cairo 1.4.6 Revise the patch to support 8bit truecolor also screenshot of firefox on 256 color (depth 8) display Patch which worked on AIX 52 Capture of part of my screen, with 'gkrellm' from new Cairo on the top and from an old no-Cairo version on the bottom screen capture of Firefox 2.0.0.17 with cairo-1.8.6 on 256 color X11 on Solaris 10 x86 attachment-1164-0.html attachment-10479-0.html |
||
I am seeing someting very similar on NCD and IBM X terminals. On SuSE 10.0 firefox 1.0.7 crashes with a segmentation fault as soon as you start it. I have gtk2-2.8.3-4 cairo-1.0.0-7.2 Here is my traceback: #0 0x00000000 in ?? () #1 0xb3658842 in _cairo_pixman_composite_tri_fan () from /usr/lib/libcairo.so.2 #2 0xb365b906 in _cairo_pixman_composite_tri_fan () from /usr/lib/libcairo.so.2 #3 0xb364bc69 in _cairo_pixman_region_intersect () from /usr/lib/libcairo.so.2 #4 0xb362d4a9 in cairo_image_surface_get_height () from /usr/lib/libcairo.so.2 #5 0xb3632d89 in cairo_surface_create_similar () from /usr/lib/libcairo.so.2 #6 0xb362a573 in cairo_font_options_get_hint_metrics () from /usr/lib/libcairo.so.2 #7 0xb3629cb6 in cairo_font_options_get_hint_metrics () from /usr/lib/libcairo.so.2 #8 0xb362a97b in cairo_font_options_get_hint_metrics () from /usr/lib/libcairo.so.2 #9 0xb362ab87 in cairo_font_options_get_hint_metrics () from /usr/lib/libcairo.so.2 #10 0xb362ac6a in cairo_font_options_get_hint_metrics () from /usr/lib/libcairo.so.2 #11 0xb3624609 in cairo_stroke_preserve () from /usr/lib/libcairo.so.2 #12 0xb3624632 in cairo_stroke () from /usr/lib/libcairo.so.2 #13 0xb38e656e in gtk_style_apply_default_background () from /opt/gnome/lib/libgtk-x11-2.0.so.0 #14 0xb38ed0c0 in gtk_paint_check () from /opt/gnome/lib/libgtk-x11-2.0.so.0 #15 0x081c1aca in nsCharPtrHashKey::nsCharPtrHashKey () #16 0x081c0768 in nsCharPtrHashKey::nsCharPtrHashKey () #17 0x0823d4ff in nsCOMTypeInfo<nsITimerInternal>::GetIID () #18 0x0823df08 in nsCOMTypeInfo<nsITimerInternal>::GetIID () #19 0x08204c63 in nsIBidirectionalEnumerator::nsIBidirectionalEnumerator () #20 0x0825b55d in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #21 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #22 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #23 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #24 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #25 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #26 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #27 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #28 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #29 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #30 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #31 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #32 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #33 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #34 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #35 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #36 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #37 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #38 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID () #39 0x083e37bc in nsCOMPtr<nsIObjectInputStream>::nsCOMPtr () #40 0x083e2e42 in nsCOMPtr<nsIObjectInputStream>::nsCOMPtr () #41 0x083e2624 in nsCOMPtr<nsIObjectInputStream>::nsCOMPtr () #42 0x08215570 in nsCOMPtr<nsIBidirectionalEnumerator>::nsCOMPtr () #43 0x08368f61 in nsCOMTypeInfo<nsICollection>::GetIID () #44 0x0836b89e in nsCOMTypeInfo<nsICollection>::GetIID () #45 0x0836eedf in nsCOMTypeInfo<nsICollection>::GetIID () #46 0x0836f8b5 in nsCOMTypeInfo<nsICollection>::GetIID () #47 0x0836fc5f in nsCOMTypeInfo<nsICollection>::GetIID () #48 0x08369002 in nsCOMTypeInfo<nsICollection>::GetIID () #49 0x081fe29b in nsCOMPtr<nsISupports>::nsCOMPtr () #50 0x081fa4a8 in nsCOMPtr<nsISupports>::nsCOMPtr () #51 0x081fa4e3 in nsCOMPtr<nsISupports>::nsCOMPtr () #52 0xb388ae60 in gtk_marshal_VOID__UINT_STRING () from /opt/gnome/lib/libgtk-x11-2.0.so.0 #53 0xb35ebd19 in g_closure_invoke () from /opt/gnome/lib/libgobject-2.0.so.0 #54 0xb35fb816 in g_signal_stop_emission () from /opt/gnome/lib/libgobject-2.0.so.0 #55 0xb35fcbee in g_signal_emit_valist () from /opt/gnome/lib/libgobject-2.0.so.0 #56 0xb35fd1f5 in g_signal_emit () from /opt/gnome/lib/libgobject-2.0.so.0 #57 0xb397d3b4 in gtk_widget_activate () from /opt/gnome/lib/libgtk-x11-2.0.so.0 #58 0xb3889845 in gtk_main_do_event () from /opt/gnome/lib/libgtk-x11-2.0.so.0 #59 0xb37073fd in gdk_window_clear_area_e () from /opt/gnome/lib/libgdk-x11-2.0.so.0 #60 0xb37074df in gdk_window_process_all_updates () from /opt/gnome/lib/libgdk-x11-2.0.so.0 #61 0xb3707565 in gdk_window_process_all_updates () from /opt/gnome/lib/libgdk-x11-2.0.so.0 #62 0xb3581941 in g_child_watch_add () from /opt/gnome/lib/libglib-2.0.so.0 #63 0xb357f35c in g_main_context_dispatch () from /opt/gnome/lib/libglib-2.0.so.0 #64 0xb35827cb in g_main_context_check () from /opt/gnome/lib/libglib-2.0.so.0 #65 0xb3582ce7 in g_main_context_iteration () from /opt/gnome/lib/libglib-2.0.so.0 #66 0x081fdae0 in nsCOMPtr<nsISupports>::nsCOMPtr () #67 0x0857d697 in nsCOMPtr<nsIEventQueue>::nsCOMPtr () #68 0x084d2411 in nsCOMTypeInfo<nsIProcess>::GetIID () #69 0x084d114b in nsCOMTypeInfo<nsIProcess>::GetIID () #70 0x086edd56 in nsCOMTypeInfo<nsIBinaryInputStream>::GetIID () #71 0x086ef526 in nsCOMTypeInfo<nsIBinaryInputStream>::GetIID () #72 0x080810db in ?? () #73 0x00000001 in ?? () #74 0xbfd446a4 in ?? () #75 0x086f88d0 in _IO_stdin_used () #76 0xbfd44678 in ?? () #77 0xb2f44ea0 in __libc_start_main () from /lib/tls/libc.so.6 #78 0xb2f44ea0 in __libc_start_main () from /lib/tls/libc.so.6 #79 0x08081031 in ?? () Hope this can be fixed, it is a complete showstopper for SuSE 10 at this site. Bob More news on this: a colleague reports that if you reconfigure the terminal to use 16-bit colour instead of 8-bit then the problem goes away. However this is an unhelpful solution for us: we switched the terminals to 8-bit because firefox frequently crashed when visiting graphics-intensive sites. Bob I've updated the summary to note the limitation of this bug to the cased of X servers running in 8-bit pseudocolor mode. Regarding the recommendation to switch to 16-bit color... I cannot. The tektronix is 8-bit only, as are many of the older X-Term products I have used (NCD, IBM-Netstation). I really would love to go 16-bit if I could. *** Bug 5196 has been marked as a duplicate of this bug. *** I believe I'm seeing the same problem. I have a Tektronix XP117C X terminal, which is 8 bit only, so changing the configuration to 16 bit or more is not possible. I'm using GTK 2.8.6-0ubuntu2.1. All sorts of old style X apps work fine if started on the display (i.e. xterm, xeyes, xclock etc.), but gdm and such like don't work. If this problem gets fixed, I'd be very pleased to hear about it. David. I can imagine this bug could well be problematic for the developers because they may not have access to old equipment. Is there anything those of us with 8-bit X terminals can do to speed things up? It would cost this department about $25000 to replace all our 8-bit terminals, so I'm willing to invest some effort in providing good debugging information, or testing out new versions of software. Created attachment 4872 [details]
Simple program to demonstrate bug
I downloaded a very simple Cairo demo from the Gnome Journal and this also
triggers the bug. The attachment includes:
(1) program source
(2) Makefile
(3) Debugging traceback (in cairo.log)
To compile the program type
make clock3
More information: this bug is a close relation of https://bugs.freedesktop.org/show_bug.cgi?id=5846 and possibly the same. A colleague of mine built libcairo with the workround suggested there and found that firefox and other applications now ran without crashing on 8-bit terminals. However, there were some issues with text displaying strangely, so there is still work to be done. Bob Retitling to hopefully make it clear that this isn't some problem that needs diagnosis. If someone is interested in doing the work (probably a week or so's worth of work), that could be discussed on the cairo mailing list. Of course, making it stop crashing is easier than making but of pretty limited value... *** Bug 6379 has been marked as a duplicate of this bug. *** (In reply to comment #7) > I can imagine this bug could well be problematic for the developers because they > may not have access to old equipment. couldn't we argue that cairo and gtk/gdk/pango developers could have at least tested 8-bit pseudo color and bgr/rgb true-color visuals on Xvnc or Xnest? (In reply to comment #12) > couldn't we argue that cairo and gtk/gdk/pango developers could have at least > tested 8-bit pseudo color and bgr/rgb true-color visuals on Xvnc or Xnest? Certainly, getting access to an X server with an 8-bit pseudo-color visual is not the problem. So, you're correct that an offer of hardware won't help get the problem fixed. The reason this situation exists is not due to some careless lack of testing. For cairo at least, there was a conscious acknowledgment from the developers that have been working on cairo so far that the 8-bit pseudo-color case is uninteresting. Obviously, (from the traffic here), there are users that are interested in this case. So what falls to the users is finding a capable developer that is motivated (or that could be made motivated) to fix this. *** Bug 5205 has been marked as a duplicate of this bug. *** (In reply to comment #13) > > The reason this situation exists is not due to some careless lack of testing. > For cairo at least, there was a conscious acknowledgment from the developers > that have been working on cairo so far that the 8-bit pseudo-color case is > uninteresting. > Sadly there is a bit of a clash of expectations here. The Cairo developers are busy working on what they find interesting, while in another part of the free software ecosystem distributors like SuSE are including this partially functional software in their products and selling it to the general public. (In reply to comment #15) > > Sadly there is a bit of a clash of expectations here. The Cairo developers are > busy working on what they find interesting, while in another part of the free > software ecosystem distributors like SuSE are including this partially > functional software in their products and selling it to the general public. If a software distributor wants to sell you a product that doesn't meet your needs, then don't buy it. There really are connections between what paying customers care about and what developers will find interesting to work on. (In reply to comment #16) (well, not really) Hi, I add this note to the tracker (after a suggestion by Bob) to let people not following the cairo devel list know that I have written a patch for that isue: http://ekyo.nerim.net/software/patch-src_cairo-xlib-surface_c I have personally tested it on OpenBSD/macppc in various combinations of ati/wscons drivers and ssh-X/-Y. I also have postive feedback from Bob (thank you). If you find this useful let me know, also read http://ekyo.nerim.net/software/index.html Eric. For what it is worth I've had to workaround cairo color issues as a developer of a comercial product built on top of wxwidgets, by using gtk+2.6.10 the last gtk version before the adoption of cairo. My research indicates that QT on top of cairo gtk also had similar issues. To our surprise our first comercial customers wanted to use our product on X-Win32 and Solaris and encounted some of these issues. I very much look forward to the incorporation of this bug fix into a future cairo release and suggest that perhaps bugs 5212, 5681, and 5846 may be related. I have a news group corespondence on gmane.comp.lib.wxwindows.general (search for "Apparent RGB") that may be of interest. Thanks -- Tom FYI this bug has now wasted a week's worth of my time in trying to upgrade packages that previously worked A-OK in my environments on NetBSD (i386, alpha, and sparc). Confusion with weird pthread problems on SMP machines, along with the fact that this bugzilla database doesn't seem to be indexed very well by google didn't help of course. :-) It's now a complete show-stopper for me for any and all applications needing gtk2+. gtk-demo is a great canonical example program that crashes on all platforms I've tested. Note that prior to these upgrades all the applications I'm attempting to upgrade worked OK even on monochrome displays (albiet with some invisible features whenever too many colours are used in proximity with each other by the application). Note of course that the bug is still present in 1.0.4 as well. I'll be testing out the patch suggested in a recent comment. Created attachment 5796 [details] [review] fix for the 8bit issue + 16 bit. Hi all, There was a bug in my previous fix. Color channels were mixed up on some archs. This should be much better now. It should also be faster. I have also added a workaround for 16bits displays with the RENDER extension disabled. Also updated there: http://ekyo.nerim.net/software/patch-src_cairo-xlib-surface_c Eric. *** Bug 4505 has been marked as a duplicate of this bug. *** This patch seems to work against cairo 1.0, not 1.2. Is there an updated patch for the new release of cairo, or can this patch be integrated into cairo? (In reply to comment #22) > This patch seems to work against cairo 1.0, not 1.2. Is there an updated patch > for the new release of cairo, or can this patch be integrated into cairo? Hi, I have just ported my patch to cairo-1.2.0. http://ekyo.nerim.net/software/patch-1.2.0-src_cairo-xlib-surface_c Eric. *** Bug 8073 has been marked as a duplicate of this bug. *** any chance of a patch against 1.2.4? I just checked 1.2.4 and it still has this problem. Unfortunately the 1.2.0 patch didn't apply cleanly and I don't understand it enough to work it into the 1.2.4 code. Surely this must affect quite a number of users. For now I will just not move past gtk-2.6. Just to append to this, I'm using a Sun ultra/10 with the default graphics card. In this case that means I'm running 8-bit psuedocolor. Thats the best you get with 1280 x 1024. To go to something like 24-bit color you have to drop down to 1024 x 768 which is just not enough. Granted this is not a cutting edge machine but I'll bet there are a lot of them deployed. I'd be happy to test out any patches. Created attachment 6762 [details] [review] update of Eric Faurot's patch for 1.2.4 I managed to get Eric's patch for 1.2.0 to apply to 1.2.4 with some manual help. I can't claim to understand his changes (or any of cairo's internals), but with this patch I can display gtk apps on my sun ultra/10 again. Are there any plans of integrating this into the main sources? Thanks -Dan Created attachment 6819 [details] [review] Fix of patch #6762 for true color (for cairo-1.2.4) The patch #6762 works indeed for 8-bit Pseudo-Color with SUN-X-Servers, but breaks 24-Bit-True Color Visual compatibility there. The new attchment contains a patch derived from #6762 wich works also with True Color. Additionally, code parts aparrantly obsoleted (?) by pango-1.2 (WORKAROUND_8BIT_GRAYLEVEL, WORKAROUND_R5G6B5) have been removed. By now it's tested only briefly with SUN-X-Server on 8-bit Pseudo-Color and 24-Bit-True Color Visuals. *** Bug 8416 has been marked as a duplicate of this bug. *** This is just a note that attachement #6819 seems to work for me. I'm using an 8-bit psuedocolor display (Sun ultra/10, solaris-2.9, Xsun). What are the chances of this patch making its way back to the main sources? Thanks -Dan I would prefer a patch that has all the workarounds (WORKAROUND_8BIT_GRAYLEVEL and WORKAROUND_R5G6B5 included) and doesn't break 24-Bit-True Color Visual compatibility. I think the workarounds are useful (or could potentially be useful) for more than just pango. I'm experiencing the same "crash-all-gtk-apps" symptom on my remote setup. Of
note is that the display in question is 16bit, the problem also appears at
24bit. My segfault, when running 'gtk-demo' happens in
_cairo_xlib_surface_show_glyphs:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1218046288 (LWP 16941)]
0xb78f8039 in _cairo_xlib_surface_show_glyphs () from /usr/lib/libcairo.so.2
The client machine is Linux/Intel whereas the X server is running on Linux/
PowerPC.
(In reply to comment #31) Right, these are Cairo 1.2.4 and GTK 2.10.6... *** Bug 8382 has been marked as a duplicate of this bug. *** *** Bug 8530 has been marked as a duplicate of this bug. *** *** Bug 8764 has been marked as a duplicate of this bug. *** Seems like I have a similar problem, only now cairo spills some error messages about not supporting 8-bit visuals. Hi,
I also hit this behaviour in a RHEL5 + Sun Secure Global Desktop scenario.
Error: Cairo does not yet support the requested image format:
Depth: 8
Alpha mask: 0x00000000
Red mask: 0x00000000
Blue mask: 0x00000000
Green mask: 0x00000000
Please file an enhacement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
gnome_segv: cairo-image-surface.c:144: _cairo_format_from_pixman_format: Asserti
on `NOT_REACHED' failed.
[root@localhost ~]# rpm -aq | grep -i pango
pango-1.13.4-2
pycairo-1.2.0-1.1
cairo-1.2.0-2
I read through all the related info here now, and I think someone from the dev's
should test the patches submitted here AND drop a line to Redhat. They might
want to patch up their version.
FYI, i think I can switch my colordepth setting somewhere, but when I hit the
error I ended up getting about 200 windows created till I could kill it - *not*
pleasant :))
*** Bug 9115 has been marked as a duplicate of this bug. *** *** Bug 9283 has been marked as a duplicate of this bug. *** On OpenBSD 4.0-current (Wed Dec 6 03:34:00 MST 2006), X.org 6.9.0 depth 16bit
with cairo-1.2.6 gtk+2-2.10.6 pango-1.14.7 and patch id=6819 form this bug
id=4945 nautilus 2.16.3 crashes like:
Breakpoint 1, cairo_xlib_surface_create_for_bitmap (dpy=0x7c24c000,
bitmap=4194436, screen=0x7d2a8b80, width=139, height=78)
at cairo-xlib-surface.c:2154
2154 return _cairo_xlib_surface_create_internal (dpy, bitmap, screen,
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0x0919e97d in _cairo_xlib_surface_create_internal (dpy=0x7c24c000,
drawable=4194436, screen=0x7d2a8b80, visual=0x0, xrender_format=0x0,
width=139, height=78, depth=1) at cairo-xlib-surface.c:2065
2065 if (xrender_format == NULL &&
(gdb) bt
#0 0x0919e97d in _cairo_xlib_surface_create_internal (dpy=0x7c24c000,
drawable=4194436, screen=0x7d2a8b80, visual=0x0, xrender_format=0x0,
width=139, height=78, depth=1) at cairo-xlib-surface.c:2065
#1 0x0919eb15 in cairo_xlib_surface_create_for_bitmap (dpy=0x7c24c000,
bitmap=4194436, screen=0x7d2a8b80, width=139, height=78)
at cairo-xlib-surface.c:2154
#2 0x0adcd87a in gdk_x11_ref_cairo_surface (drawable=0x885f9640)
at gdkdrawable-x11.c:1474
#3 0x0ad9cd7e in _gdk_drawable_ref_cairo_surface (drawable=0x885f9640)
at gdkdraw.c:1263
#4 0x0ada9110 in gdk_pixmap_ref_cairo_surface (drawable=0x808914d0)
at gdkpixmap.c:515
#5 0x0ad9cd7e in _gdk_drawable_ref_cairo_surface (drawable=0x808914d0)
at gdkdraw.c:1263
#6 0x0ad98a69 in gdk_cairo_create (drawable=0x808914d0) at gdkcairo.c:45
#7 0x0ada350b in get_cairo_context (gdk_renderer=0x884ad010,
part=PANGO_RENDER_PART_FOREGROUND) at gdkpango.c:160
#8 0x0ada36c4 in gdk_pango_renderer_draw_glyphs (renderer=0x884ad010,
font=0x7d8982d0, glyphs=0x814f75d0, x=3584, y=60416) at gdkpango.c:230
#9 0x021065ef in pango_renderer_draw_glyphs (renderer=0x884ad010,
font=0x7d8982d0, glyphs=0x814f75d0, x=3584, y=60416)
at pango-renderer.c:598
#10 0x021063e8 in pango_renderer_draw_layout_line (renderer=0x884ad010,
line=0x80891368, x=3584, y=60416) at pango-renderer.c:529
#11 0x02105c00 in pango_renderer_draw_layout (renderer=0x884ad010,
layout=0x89312678, x=1024, y=50176) at pango-renderer.c:183
#12 0x0ada51d3 in gdk_draw_layout_with_colors (drawable=0x808914d0,
gc=0x81907dd0, x=1, y=49, layout=0x89312678, foreground=0x0,
background=0x0) at gdkpango.c:1029
#13 0x0ada54b3 in gdk_draw_layout (drawable=0x808914d0, gc=0x81907dd0, x=1,
y=49, layout=0x89312678) at gdkpango.c:1091
#14 0x1c0cd999 in nautilus_undo_transaction_unregister_object ()
#15 0x1c0cc827 in nautilus_undo_transaction_unregister_object ()
#16 0x1c0cb793 in nautilus_undo_transaction_unregister_object ()
#17 0x1c0b1162 in nautilus_icon_container_request_update_all ()
#18 0x061b6dfe in g_cclosure_marshal_VOID__OBJECT ()
from /usr/local/lib/libgobject-2.0.so.1200.4
#19 0x061a5f6e in g_closure_invoke ()
from /usr/local/lib/libgobject-2.0.so.1200.4
#20 0x061b6081 in g_signal_emit_by_name ()
from /usr/local/lib/libgobject-2.0.so.1200.4
#21 0x061b521e in g_signal_emit_valist ()
from /usr/local/lib/libgobject-2.0.so.1200.4
#22 0x061b5560 in g_signal_emit_by_name ()
from /usr/local/lib/libgobject-2.0.so.1200.4
#23 0x049eab7a in gtk_drag_begin_internal (widget=0x8885c018, site=0x0,
target_list=0x87b135c0, actions=46, button=1, event=0x829d96a8)
at gtkdnd.c:2262
#24 0x049eaf40 in gtk_drag_begin (widget=0x8885c018, targets=0x87b135c0,
actions=46, button=1, event=0x829d96a8) at gtkdnd.c:2378
#25 0x1c0b1348 in nautilus_icon_container_request_update_all ()
#26 0x1c0a7fdf in nautilus_file_is_gone ()
#27 0x0488532e in _gtk_marshal_BOOLEAN__BOXED (closure=0x8a7328d0,
return_value=0xcf7e0a50, n_param_values=2, param_values=0xcf7e0bb0,
invocation_hint=0xcf7e0a78, marshal_data=0x1c0a7e00) at gtkmarshalers.c:84
#28 0x061a61e6 in g_cclosure_new_swap ()
from /usr/local/lib/libgobject-2.0.so.1200.4
#29 0x061a5f6e in g_closure_invoke ()
from /usr/local/lib/libgobject-2.0.so.1200.4
#30 0x061b5b3b in g_signal_emit_by_name ()
from /usr/local/lib/libgobject-2.0.so.1200.4
#31 0x061b5051 in g_signal_emit_valist ()
from /usr/local/lib/libgobject-2.0.so.1200.4
#32 0x061b548b in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.1200.4
#33 0x049d00f7 in gtk_widget_event_internal (widget=0x8885c018,
event=0x829d96a8) at gtkwidget.c:3911
#34 0x049cfc8d in gtk_widget_event (widget=0x8885c018, event=0x829d96a8)
at gtkwidget.c:3717
#35 0x048839c5 in gtk_propagate_event (widget=0x8885c018, event=0x829d96a8)
at gtkmain.c:2188
#36 0x048825c4 in gtk_main_do_event (event=0x829d96a8) at gtkmain.c:1422
#37 0x0add15d1 in gdk_event_dispatch (source=0x88f6c040, callback=0,
user_data=0x0) at gdkevents-x11.c:2320
*** Bug 9587 has been marked as a duplicate of this bug. *** Patch used in Sun's JDS: http://cvs.opensolaris.org/source/xref/jds/spec-files/trunk/patches/cairo-02-8bit-fix.diff *** Bug 10460 has been marked as a duplicate of this bug. *** *** Bug 10469 has been marked as a duplicate of this bug. *** *** Bug 10516 has been marked as a duplicate of this bug. *** *** Bug 10532 has been marked as a duplicate of this bug. *** By my count there have been 16 other bug reports marked as duplicates of this one. Several patches have been offered and unless I missed it, there has been no negative feedback about these patches which has not been addressed. Is there any chance at all of these patches ever making their way back into the main source tree? Or is it always going to be the case that users will have to maintain patches if they care about users that may have older displays? Note that some users may be running on high end computers but still may have older displays and are thus crippled with this. I'm sure many of us would like to hear some official feedback especially if it is a step towards getting this fixed in the official sources. It seems there is no shortage of users to test patches although as someone pointed out quite a while back, VNC can give you access to displays with different color depths. I hate to complain too much because I'm someone who also contributes quite a bit to various open source projects I realize there isn't always time to look at all the bug reports and patch submissions, but at the same time, cairo is really critical to many many apps and it seems that the patches proposed here are seeing quite a bit of real life use and day to day testing. Perhaps it is because all the patches I've seen would need some tidying up before they'd be suitable - `patch' is very much the right word for the code given within them. They work, but you wouldn't want cairo to be comprised entirely of these patches. I would expect that if one of the patches was polished up a bit, it might have a better chance of being merged... (In reply to comment #47) > By my count there have been 16 other bug reports marked as duplicates of this > one. Yes, and the duplicates alone are annoying enough that I'd definitely like to see this bug (and other similar ones) go away for good. We've even added this to the RAODMAP for somewhere along the 1.4.x or 1.6. See: http://cairographics.org/ROADMAP > Several patches have been offered and unless I missed it, there has been > no negative feedback about these patches which has not been addressed. That's primarily because I've never even seen a patch that the author has suggested was clean or complete. And I believe the most recent discussion has happened on the cairo mailing list, not here in bugzilla, (and the whole split-conversation thing is something that I dislike about bugzilla very much). Here's a pointer to what I think is the most recent post on the mailing list on the topic: http://lists.freedesktop.org/archives/cairo/2007-February/009731.html I'd be happy to have help with this, (including success reports), -Carl thanks. I'll direct further questions to the mailing list. FWIW, here is a link to the patch currently used by NetBSD pkgsrc: http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/graphics/cairo/patches/patch-ae It seems to work alright for me with a Sun ultra/10 display (8 bit psuedo color) and we have not been hearing complaints from other users with more modern displays. Since cairo affects much of gnome as well as firefox/thunderbird/etc it is reasonably safe to assume that the attached patch has received a fair amount of road testing. *** Bug 10588 has been marked as a duplicate of this bug. *** Created attachment 9844 [details] [review] updated patch for cairo 1.4.6 I noticed that the latest version of this patch is for cairo 1.4.2 and apply against cairo 1.4.6. The code is pretty much the same, though the structures have now moved into cairo-xlib-surface-private.h. I notice when I log into my session passing "-depth 8" to the Xorg Xserver, so I am running in 8bit mode that there are some problems: - sometimes the background image doesn't look right. Depending on the background image used, it looks like it isn't being scaled cleanly or it sometimes has horizontal black lines running through the image. - I also notice that gnome-screenshot seems to take really messed up pictures of the desktop. So I'm not sure 8bit mode works perfectly even with this patch applied, though those bugs may not be related to cairo. I'm not sure. I see the exact same problems running with the earlier version of the patch with cairo 1.4.0, so I do not think these problems are introduced by my update of the patch. I haven't filed bugs against these two issues yet since this 8bit logic isn't yet integrated into cairo. I just mention I am seeing these problems so the cairo developers can look into this and see if they might understand what the problems may be. If these aren't cairo problems, we probably should file bugs against control-center Desktop Background capplet and gnome-screenshot once this patch goes upstream. *** Bug 10947 has been marked as a duplicate of this bug. *** *** Bug 11202 has been marked as a duplicate of this bug. *** *** Bug 11175 has been marked as a duplicate of this bug. *** *** Bug 11405 has been marked as a duplicate of this bug. *** It seems that cairo not only doesn't support 8bit pseudocolor but also Truecolor, remember there is still a case that the 8bit color represent as truecolor with 2bit blue, 3bit Green and 3bit Red, this kind of color system still been used in some case. Created attachment 11071 [details] [review] Revise the patch to support 8bit truecolor also *** Bug 11745 has been marked as a duplicate of this bug. *** *** Bug 11926 has been marked as a duplicate of this bug. *** *** Bug 12010 has been marked as a duplicate of this bug. *** *** Bug 13386 has been marked as a duplicate of this bug. *** So I'm trying to figure out how to apply this patch. I will say I know almost nothing about Linux, but I am a physics/astrophysics major, and most of our programs are written in Linux. It's been a helluva ride getting my program to run in Linux period, and now part of it requires running in 8 bit. But every time I try to start an 8-bit window, I get the Cairo error. If this patch can let me run my 8-bit, it will be a life saver. can anybody tell me what I do with this patch to make it work? *** Bug 13642 has been marked as a duplicate of this bug. *** I stumbled across a similar problem: Firefox wouldn't start on a 256-color Citrix Metaframe (aka ICA) display (commercial software to display X on a Windows PC). So I took cairo-1.4.12, applied the most recent of the attached patches, compiled my own libcairo, and started firefox 2.0.0.6 with LD_LIBRARY_PATH set to the new libcairo, which resulted in this error message:
Error: Cairo 1.4.12 does not yet support the requested image format:
Depth: 8
Alpha mask: 0x00000000
Red mask: 0x00000000
Green mask: 0x00000000
Blue mask: 0x00000000
Please file an enhancement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
firefox-bin: cairo-image-surface.c:199: _cairo_format_from_pixman_format: Assertion `NOT_REACHED' failed.
I tried changing line 173 of src/cairo-image-surface.c to:
case 8:
if ((am == 0xff || am == 0x0) &&
But that did not help - firefox then crashes with a segfault. Could be that the version jump of libcairo.so.2.9.2 to libcairo.so.2.11.6 was too high, and I'd have to recompile all GTK/firefox, which I cannot afford. I will try patching the older release of cairo (1.2.4), and let you know...
(In reply to comment #65) > I will try patching > the older release of cairo (1.2.4), and let you know... I used Dan's patch (https://bugs.freedesktop.org/attachment.cgi?id=6762) on cairo-1.2.4, forced firefox to use the patched libcairo.so via LD_LIBRARY_PATH and now firefox starts up happily in 8bit/256color mode on a remote connection (X Server: Citrix ICA 256 color mode). I cannot test later versions of cairo unfortunately, but at least you have this proof that the patch addresses the "depth 8" mode. Keep up the good work! -Marek Thanks Marek. Can you attach a screenshot?! I'm curious how it looks. Created attachment 13517 [details]
screenshot of firefox on 256 color (depth 8) display
Hello,
I can't use libcairo and all GTK applications of a Debian Etch (cairo 1.2.4) on my X11 NCD terminal (8bit colors) since a long time. I've tried to use patch #6762, and with it, applications launch but giving a lot of messages like :
No workaround for this pixel format: Visual: class=TrueColor, bpRGB=8, CM=8, r=7, g=38, b=c0
...
And no text appear !
I've also tried patch #6819, but applications fail :
.../libcairo-1.2.4/src/cairo-image-surface.c:155: _cairo_format_from_pixman_format: l'assertion « NOT_REACHED » a échoué.
Error: Cairo does not yet support the requested image format:
Depth: 8
Alpha mask: 0x00000000
Red mask: 0x00000007
Green mask: 0x00000038
Blue mask: 0x000000c0
Please file an enhacement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
I'm not as lucky as Marek, and always stuck on old Debian Sarge from 2005 :-(
Hi,
I applied patch 11071 on cairo 1.4.10 on AIX 52. Build Firefox with the 1.4.10 devel RPM, however Firefox still crashed when started in 8 bit color mode.
Following was the error
Error: Cairo 1.4.10 does not yet support the requested image format:
Depth: 8
Alpha mask: 0x00000000
Red mask: 0x00000000
Green mask: 0x00000000
Blue mask: 0x00000000
Please file an enhancement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
The assert subroutine failed: NOT_REACHED, file cairo-image-surface.c, line 199
obj-opt/dist/bin/run-mozilla.sh[36]: 217132 IOT/Abort trap(coredump)
Created attachment 14169 [details] [review] Patch which worked on AIX 52 I tried to play around with the patch 11071, and this is what worked finally ( was able to run Firefox) in both Pseudo color and True color. Looking for assistance in finding a suitable fix. (In reply to comment #71) > Created an attachment (id=14169) [details] > Patch which worked on AIX 52 > > I tried to play around with the patch 11071, and this is what worked finally ( > was able to run Firefox) in both Pseudo color and True color. > > Looking for assistance in finding a suitable fix. Screenshots? Does this fix have the same artifacts as the last screenshot posted? i have a monochrome XTerminal NCD 16e, same blues:
collin:~> firefox
Error: Cairo 1.4.14 does not yet support the requested image format:
Depth: 1
Alpha mask: 0x00000000
Red mask: 0x00000000
Green mask: 0x00000000
Blue mask: 0x00000000
Please file an enhancement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
firefox-bin: /home/dajobe/dev/debian/cairo/cairo-1.4.14/src/cairo-image-surface.c:199: _cairo_format_from_pixman_format: Assertion `NOT_REACHED' failed.
Abort
;)
Zap
*** Bug 12283 has been marked as a duplicate of this bug. *** This bug is now fixed in the cairo 1.5.14 snapshot and the fix will appear in the imminent 1.6.0 cairo release. Please test and let me know how things go. -Carl Hello, I've tested new 1.6.4 Cairo on a Debian Etch system (by recompiling the 1.6.4-1 Debian Sid package), and tested it on my X11 terminal : it works, but I still have a problem : all texts are painted with ugly colors (something like pink on purple (see attachment), and it's unusable. As i know there is different kinds of 8bits display, and that I tested this new Cairo version through Debian packaging, I wonder if the problem comes from Cairo, Debian packaging, GTK2 or something else. Is there something I can do to help to fix it ? Created attachment 16702 [details]
Capture of part of my screen, with 'gkrellm' from new Cairo on the top and from an old no-Cairo version on the bottom
Created attachment 22849 [details]
screen capture of Firefox 2.0.0.17 with cairo-1.8.6 on 256 color X11 on Solaris 10 x86
I confirm that cairo-1.8.6 fixes this problem; rendering on 256-color X11 works OK now. Thanks to the developers, good job!
Created attachment 132687 [details]
attachment-1164-0.html
Hello,
I am on brief vacation in Boston MA, back to work on Jul 17. I will read my email occasionally. If you need urgent response please indicate so. I will do my best to help.
Thank you,
Boris Vinarsky
Rambus IT - CRD
Created attachment 132689 [details]
attachment-10479-0.html
I will be out of the office from Friday, 7/14/2017 through 7/23/2017. Please call Steven Anderson, (214)671-0424, for urgent matters. I will be monitoring Email periodicity.
|
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.
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