[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GNUstep on FreeBSD problems
GNUstep on FreeBSD problems
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 . 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
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?
 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.
Description: Binary data
- GNUstep on FreeBSD problems,
Wolfgang Lux <=