Re: [ccp4bb]: 24 (and 32) bpp colour - a note of caution

[Dave Love <d.love@dl.ac.uk>]

***  For details on how to be removed from this list visit the  ***
***    CCP4 home page http://www.dl.ac.uk/CCP/CCP4/main.html    ***

I asked for a chance to look at the patch first, which I didn't get.

I've now checked it properly and replied to its author.  The main part
is bogus, as demonstrated by the 8bpp behaviour -- the relevant memory
_was_ allocated previously.  I'll fix the trivial memory leak slightly
differently.

I've run mosflm on glibc-2.1, xfree86-3.n based GNU/Linux systems
against 8-, 16- and 24-bit servers using the latest release (4.2) of
the xdl_view library, and it works.  mosflm should use that version.¹
It specifically fixes this incorrectly diagnosed problem from the
mosflm page, as I've posted previously:

   9. Before you try this, try the [15]advice immediately above! 
       Segmentation fault/core dump when running MOSFLM, occurring
       immediately when the graphics window opens (or rather, when it
       should open!).
       This seems to happen only on newer machines, when the graphics
       have been set to 24 bpp (usually SUSE) or 32 bpp (RedHat)
       graphics. It appears to be caused by a fault in the X-server in
       Linux distributions; the answer is to set your colour depth to no
       more than 16 bpp.

If people still have problems with xdl_view-4.2, please let me know
with complete information, including the output of `xdpyinfo'; I will
investigate, if not instantly.

While xdl_view is free software, as I'm tasked with maintaining it I'd
be grateful if random changed versions didn't propagate and cause
confusion.

Footnotes: 

1. If you avoid `-static' in the mosflm makefile, you can use updated
   versions of the shared xdl_view library (and others) without
   relinking.