Description of problem: Cairo/Gnome errors when using 8 bit X terminals / VNC None of th egnome suite works including GDM Version-Release number of selected component (if applicable): Cairo 1.2.6 How reproducible: 100% Steps to Reproduce: 1. Set up an 8 bit pseudo colour VNC server to connect to /usr/bin/Xvnc :1 -ac +bs -geometry 1000x740 -depth 8 -cc 3 -fp unix/:7100 securitytypes=none 2. Connect to the Xvnc server from vnclient localhost:1 3. From another shell, set your DISPLAY variable to point to the VNC server 4. export DISPLAY=localhost:1 5. In the same shell gnome-terminal Actual results: Error: Cairo 1.2.6 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 gnome-terminal: cairo-image-surface.c:201: _cairo_format_from_pixman_format: Assertion `NOT_REACHED' failed. Error: Cairo 1.2.6 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 bug-buddy: cairo-image-surface.c:201: _cairo_format_from_pixman_format: Assertion `NOT_REACHED' failed. Expected results: Gnome terminal comes up on the vnc server Additional info: Output of xdpyinfo: name of display: localhost:1.0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 70100000 X.Org version: 7.1.0 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 2 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: PointerRoot number of extensions: 21 BIG-REQUESTS DAMAGE DEC-XTRAP DOUBLE-BUFFER Extended-Visual-Information MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RECORD SECURITY SHAPE SYNC TOG-CUP VNC-EXTENSION X-Resource XC-APPGROUP XC-MISC XFIXES XFree86-Bigfont XTEST XVideo default screen number: 0 number of screens: 1 screen #0: dimensions: 1000x740 pixels (254x188 millimeters) resolution: 100x100 dots per inch depths (2): 1, 8 root window id: 0x29 depth of root window: 8 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 256 preallocated pixels: black 1, white 0 options: backing-store YES, save-unders YES largest cursor: 1000x740 current input event mask: 0x0 number of visuals: 6 default visual id: 0x21 visual: visual id: 0x21 class: PseudoColor depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x0, 0x0, 0x0 significant bits in color specification: 8 bits visual: visual id: 0x22 class: GrayScale depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x0, 0x0, 0x0 significant bits in color specification: 8 bits visual: visual id: 0x23 class: StaticColor depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x7, 0x38, 0xc0 significant bits in color specification: 8 bits visual: visual id: 0x24 class: TrueColor depth: 8 planes available colormap entries: 8 per subfield red, green, blue masks: 0x7, 0x38, 0xc0 significant bits in color specification: 8 bits visual: visual id: 0x25 class: DirectColor depth: 8 planes available colormap entries: 8 per subfield red, green, blue masks: 0x7, 0x38, 0xc0 significant bits in color specification: 8 bits visual: visual id: 0x26 class: StaticGray depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x0, 0x0, 0x0 significant bits in color specification: 8 bits
There is a bug report on freedesktop.org which describes this bug: Bugzilla Bug 4945: Cairo doesn't support 8-bit pseudocolor visuals https://bugs.freedesktop.org/show_bug.cgi?id=4945 It seems that this bug is available a long time (we have it since FC5), and that there is a patch that should be reviewed by the developers and then included in the next release. But until now the bug is leaved as new. As a consequence, some of our Sun Workstations that have only 8 bit grafic can't be used to login via ssh to a FC6 (or FC5) host and start there applications (such as ooffice, firefox, etc) because they crash in this environment. But we still need use this machines. Would it be possible for the fedora developers do include the patch shown in the freedesktop bug report to the fedora cairo package until the problem is resolved in the mainstream? Or help the freedesktop developers to include the patch (or something that solves the problem) into the mainstream code so fedora gets also the corrected code? Many thanks in advance!
*** Bug 426820 has been marked as a duplicate of this bug. ***
Yes - this bug has been around way too LONG particularly since this Cairo "upgrade" ended up BREAKING long existing 8-bit color depth capabilities. 8-bit color depths are important to me for at least the following 2 applications: - Remote desktop access where 8 bit colormaps reduce bandwidth requirements - Older X applications that only work with 8 bit color depths Please fix this, especially if a patch already exists!!!
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
I have not tested this problem at the moment. But the bug report at freedesktop tells that the problem will be fixed in 1.6.0 cairo release. https://bugs.freedesktop.org/show_bug.cgi?id=4945#c75 I think this bug is still present in Fedora 7 and Fedora 8, so this bug should be reassigned to the current Fedora release. When there is a 1.6.0 cairo release (or newer) for Fedora as package available, then we should test ist.
Thank you for the bug report. Changing version from "6" to "8".
Should work with F9. Won't fix on F8.