Re: GNUstep on FreeBSD problems

[Fred Kiefer]

Hi Wolfgang,

thank you for this detailed report. I tried to resolve the inconsistency 
you found between the visual used by the window and the one expected by 
the art backend. Could you please give my updated code a try and report 
back, whether this helps.


Cheers,
Fred

Wolfgang Lux wrote:
> 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?
>
> Wolfgang
>
> [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.