[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ccp4bb]: 24 (and 32) bpp colour - a note of caution
*** 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
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 advice immediately above!
Segmentation fault/core dump when running MOSFLM, occurring
immediately when the graphics window opens (or rather, when it
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
1. If you avoid `-static' in the mosflm makefile, you can use updated
versions of the shared xdl_view library (and others) without