[Xquartz-dev] 2.4.0_rc2

Tue Aug 11 09:54:52 PDT 2009

Jeremy,
   I haven't had a chance to test it under x86_64 fink yet but I believe
this section of the debian rasmol patch should fix the issue. There
was another section for 2.7.4.2 which appears to now be in 2.7.5.
You might want to try this for the MacPorts rasmol package.
                     Jack

On Mon, Aug 10, 2009 at 07:35:08PM -0700, Jeremy Huddleston wrote:
> This is definitely a bug in rasmol.
>
> First off, it's failing in XCreateImage because it's passing 64 in as  
> the bitmap_pad, but that's not a valid value:
> http://tronche.com/gui/x/xlib/utilities/XCreateImage.html
>
> Once I changed it to 32, rasmol started...
>
> There are quite a number of '____ cast to ____ of different size'  
> warnings throughout the build.  I have no doubt that there are other  
> lurking issues... but so far it looks like an issue in rasmol becasue it 
> assumes the size of types.
>
> --Jeremy
>
> On Aug 10, 2009, at 18:11, Jeremy Huddleston wrote:
>
>>
>> On Aug 10, 2009, at 17:57, Jack Howarth wrote:
>>
>>> Jeremy,
>>>  The code in question is avalable for viewing at...
>>>
>>> http://www.openrasmol.org/software/rasmol/src/x11win.c
>>>
>>> At first glance, it appears that for 8-bit visuals, the
>>> PseudoColor visual is used...
>>
>> In which case, you would need to run the X11 server in "256 Color"  
>> mode in X11's preferences... The PseudoColor visual only works in 8bit 
>> mode.
>>
>>> #ifdef THIRTYTWOBIT
>>>   if( XMatchVisualInfo(dpy,num,32,TrueColor,&visinfo) ||
>>>       XMatchVisualInfo(dpy,num,32,DirectColor,&visinfo) )
>>>   {   PixDepth = 32;
>>>   } else if( XMatchVisualInfo(dpy,num,24,TrueColor,&visinfo) ||
>>>              XMatchVisualInfo(dpy,num,24,DirectColor,&visinfo) )
>>>   {   PixDepth = 24;
>>>   } else /* No suitable display! */
>>>   {   XCloseDisplay(dpy);
>>>       return(0);
>>>   }
>>
>> Ok, so XMatchVisualInfo(dpy,num,24,TrueColor,&visinfo) should  
>> certainly match something... what does 'xdpyinfo' say is available?
>>
>>> ...which explains the visual not found error message on x86_64 fink
>>> for the Radeon X1600.
>>
>> Really?  How?  You should be getting a 24bit TrueColor visual...
>>
>>> However, it would appear that TrueColor or
>>> DirectColor visuals could be used for 16 and 32 bit. On the Radeon
>>> X1600, the 16-bit version produces the visual not found error
>>
>> really? It looks like it should find a 15bit visual.
>>
>>> whereas
>>> the 32-bit version of rasmol produces the error...
>>>
>>> Renderer Error: Unable to allocate frame buffer!
>>
>> That's likely an error with its use of GLX after it was able to get a 
>> visual...
>>
>>> On an HD2600, no matter what I set PIXELDEPTH to, the program runs
>>> fine but reports a 24-bit pixel depth (which oddly isn't one of the
>>> options in the source).
>>
>> /shrug
>>
>>> When I run...
>>>
>>> bash-3.2$ export LIBGL_DIAGNOSTIC=1
>>> bash-3.2$ export LIBGL_DUMP_VISUALID=1
>>>
>>> all I get is...
>>>
>>> bash-3.2$ rasmol
>>> RasMol Molecular Renderer
>>> Roger Sayle, August 1995
>>> Copyright (C) Roger Sayle 1992-1999
>>> Version 2.7.2.1.1 January 2004
>>> Copyright (C) Herbert J. Bernstein 1998-2004
>>> *** See "help notice" for further notices ***
>>> [32-bit version]
>>>
>>>
>>> Renderer Error: Unable to allocate frame buffer!
>>
>> Then it hasn't even bothered to make a GLX call... or you're not  
>> linking against our libGL.
>>
>>> xpdyinfo shows...
>>> ...
>>> default visual id:  0x24
>>> visual:
>>>   visual id:    0x24
>>>   class:    TrueColor
>>>   depth:    24 planes
>>>   available colormap entries:    256 per subfield
>>>   red, green, blue masks:    0xff0000, 0xff00, 0xff
>>>   significant bits in color specification:    8 bits
>>
>> You should be finding this visual...
>>
>>> ...
>>> visual:
>>>   visual id:    0x263
>>>   class:    DirectColor
>>>   depth:    24 planes
>>>   available colormap entries:    256 per subfield
>>>   red, green, blue masks:    0xff0000, 0xff00, 0xff
>>>   significant bits in color specification:    8 bits
>>
>> This doesn't look like a recent server release.  Are you sure you're  
>> using a recent server?  What does X11->About X11 say the version is?  
>> We should not be providing any DirectColor visuals any more...
>>
>>
>>
>> _______________________________________________
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
-------------- next part --------------
diff -uNr rasmol-2.7.5-23Jul09/src/rasmol.h rasmol-2.7.5-23Jul09.debian/src/rasmol.h

--- rasmol-2.7.5-23Jul09/src/rasmol.h	2009-07-20 10:08:43.000000000 -0400
+++ rasmol-2.7.5-23Jul09.debian/src/rasmol.h	2009-08-11 12:27:48.000000000 -0400
@@ -78,6 +78,7 @@
 /* rasmol.h
  */
 
+#include <stdint.h>
 
 /*===========================*/
 /*  User Definable Options!  */
@@ -202,7 +203,7 @@
 
 typedef double Real;
 #ifndef APPLEMAC
-typedef unsigned char Byte;
+typedef uint8_t Byte;
 #endif
 
 #ifdef __STDC__
@@ -211,21 +212,18 @@
 typedef char Char;
 #endif
 
-#ifdef _LONGLONG
-typedef unsigned int Card;
-typedef int Long;
-#else
-typedef unsigned long Card;
+typedef uint32_t Card;
+/* Long has to be defined as long, instead of int32_t because of
+   multiple printf and scanf calls using %ld in the format. */
 typedef long Long;
-#endif
 
 #ifdef EIGHTBIT
-typedef unsigned char Pixel;
+typedef uint8_t Pixel;
 #else
 #ifdef THIRTYTWOBIT
-typedef Long Pixel;
+typedef int32_t Pixel;
 #else
-typedef short Pixel;
+typedef int16_t Pixel;
 #endif
 #endif
 
@@ -249,7 +247,6 @@
 #define ToUpper(x)   (islower((x))?toupper((x)):(x))
 #endif
 
-
 #if !defined(IBMPC) || defined(_WIN32)
 #ifdef APPLEMAC
 #define _fmalloc   NewPtrSys
