[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GNUstep on FreeBSD problems

From: Wolfgang Lux
Subject: GNUstep on FreeBSD problems
Date: Sat, 13 Sep 2008 22:08:42 +0200


I recently installed FreeBSD and also attempted to use GNUstep on FreeBSD. Building GNUstep-startup from svn worked fine with one minor exception [1]. However, when starting any GNUstep program I got XBadMatch errors on the console and the windows and menus were all completely white. After finding this helpful hint http://lists.gnu.org/archive/html/discuss-gnustep/2008-04/ msg00081.html from Andrew Ruder to set the environment variable XLIB_SKIP_ARGB_VISUALS everything seems to works fine.

This weekend, I found some time to take a closer look at the problem. Apparently, it is caused by an inconsistent handling of X visuals in x11/context.m and in the libart backend. The latter in method setupDrawInfo of class ARTContext simply uses the first DirectColor or TrueColor visual returned by XGetVisualInfo. The code in x11/ context.m, on the other hand, is more involved. The function bestContext looks at all TrueColor visuals returned by XGetVisualInfo and chooses a visual with depth 24 or higher if available. On my FreeBSD installation this leads to a problem because the Xorg server's default visual uses 16 bits, but the server also offers a 32- bit visual (unless XLIB_SKIP_ARGB_VISUALS is set). Thus, every X window will use a 32-bit drawable but the graphic primitives of the libart backend attempt to send 16-bit images to that drawable causing the XBadMatch errors.

Of course, a quick and dirty fix would be to copy the code from bestContext to setupDrawInfo (or vice versa), but I feel that XGServer's context and ARTContext should not be using different visual in the first place. Unfortunately, I haven't dig far enough into the sources so far in order to understand the relation between the libart and cairo backends on one side and the common X11 code on the other side, but maybe someone more knowledgeable than me (Fred?) has some idea how to fix this.

Incidentally, XGScreenContext's code includes some logic to force XGServerWindow into using a particular visual under control of the user default NSDefaultVisual, but unfortunately the call to the relevant method (_getXDefaults) is commented out in - initForDisplay:screen:. Is there any reason for this?


[1] Given the recent discussions on libffi vs. ffcall, I decided to build GNUstep with libffi. Since FreeBSD is considered a generic platform by GNUstep-startup the default is to use ffcall. I therefore invoked InstallGNUstep with the --ffi=libffi option but this did not work because the gsflags shell function resets the GS_FFI variable to the default for the chosen platform. The following patch is a workaround, but it looks like a hack to me; there should be no need to set GS_FFI twice.

Attachment: startup.patch
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]