Hrvoje Niksic wrote: Yes. XCreatePixmapCursor only accepts pixmaps of depth 1, so the cursor can only have two colours (plus a mask). Searching for XCreatePixmapCursor reveals the following comment in glyphs-x.c: /* With an XBM file, it's obvious which bit is foreground and which is background, or rather, it's implicit: in an XBM file, a 1 bit is foreground, and a 0 bit is background. XCreatePixmapCursor() assumes this property of the pixmap it is called with as well; the `foreground' color argument is used for the 1 bits. With an XPM file, it's tricker, since the elements of the pixmap don't represent FG and BG, but are actual pixel values. So we need to figure out which of those pixels is the foreground color and which is the background. We do it by comparing RGB and assuming that the darker color is the foreground. This works with the result of xbmtopbm|ppmtoxpm, at least. It might be nice if there was some way to tag the colors in the XPM file with whether they are the foreground - perhaps with logical color names somehow? Once we have decided which color is the foreground, we need to ensure that that color corresponds to a `1' bit in the Pixmap. The XPM library wrote into the (1-bit) pixmap with XPutPixel, which will ignore all but the least significant bit. This means that a 1 bit in the image corresponds to `fg' only if `fg.pixel' is odd. (This also means that the image will be all the same color if both `fg' and `bg' are odd or even, but we can safely assume that that won't happen if the XPM file is sensible I think.) The desired result is that the image use `1' to represent the foreground color, and `0' to represent the background color. So, we may need to invert the image to accomplish this; we invert if fg is odd. (Remember that WhitePixel and BlackPixel are not necessarily 1 and 0 respectively, though I think it might be safe to assume that one of them is always 1 and the other is always 0. We also pretty much need to assume that one is even and the other is odd.) */ My guess (and it is just that) is that on an PseudoColor display, the foreground and background colours would often be allocated adjacent colourmap cells, resulting in one being odd and the other being even, whilst on a DirectColor display, the values would be fixed. -- Glynn Clements <glynn(a)sensei.co.uk&gt;