[Xprint] Re: XCreateColormap() for Pseudocolor 15bit fails

[Julien Lafon]

On Apr 9, 2005 1:45 AM, Roland Mainz <roland.mainz at nrubsig.org> wrote:
> Roland Mainz wrote:
> > > does anyone know under which conditions XCreateColormap() can fail? I
> > > have selected a Pseudocolor 15bit visual but calling XCreateColormap()
> > > fails all the time:
> > > X Error of failed request:  BadAlloc (insufficient resources for operation)
> > >   Major opcode of failed request:  78 (X_CreateColormap)
> > >   Serial number of failed request:  39
> > >   Current serial number in output stream:  40
> > >
> > > Breakpoint 1, 0x40178ab6 in exit () from /lib/libc.so.6
> > > (gdb) where
> > > #0  0x40178ab6 in exit () from /lib/libc.so.6
> > > #1  0x40070d10 in _XDefaultError (dpy=0x8052838, event=0xbffff340) at
> > > XlibInt.c:2831
> > > #2  0x40070e82 in _XError (dpy=0x8052838, rep=0xbffff430) at XlibInt.c:2883
> > > #3  0x4006edde in _XReply (dpy=0x8052838, rep=0xbffff430, extra=0,
> > > discard=1) at XlibInt.c:1812
> > > #4  0x40068762 in XSync (dpy=0x8052838, discard=0) at Sync.c:45
> > > #5  0x40068825 in _XSyncFunction (dpy=0x1) at Synchro.c:34
> > > #6  0x40047725 in XCreateColormap (dpy=0x8052838, w=61,
> > > visual=0x8057d38, alloc=0) at CrCmap.c:51
> > >
> > > Any ideas, comments, opinions on what I am doing wrong?
> >
> > AFAIK you're doing nothing wrong. The problem is that the core X
> > protocol defines |ColormapEntries| as |CARD16| (which is AFAIK a |signed
> > short|). There are two solutions:
> > 1. Create a extension (XC-BIGCOLORMAP) which hooks into libX11 and
> > allows larger colormaps (e.g. make the field |CARD32| and adjust the
> > matching function calls).
> 
> Attached patch solves the problem (for 15bit, anything deeper needs
> something like XC-BIGCOLORMAP), however it will likely break the Xfree86
> Module ABI (which leads to the debate whether we should break the ABI
> for 7.0) ... ;-(
> 
> ----
> 
> Bye,
> Roland
> 
> --
>   __ .  . __
>  (o.\ \/ /.o) roland.mainz at nrubsig.org
>   \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
>   /O /==\ O\  TEL +49 641 7950090
>  (;O/ \/ \O;)
> 
> Index: xc/programs/Xserver/include/scrnintstr.h
> ===================================================================
> RCS file: /cvs/xorg/xc/programs/Xserver/include/scrnintstr.h,v
> retrieving revision 1.4
> diff -u -2 -0 -r1.4 scrnintstr.h
> --- xc/programs/Xserver/include/scrnintstr.h    7 Aug 2004 00:58:21 -0000       1.4
> +++ xc/programs/Xserver/include/scrnintstr.h    8 Apr 2005 23:22:06 -0000
> @@ -52,41 +52,41 @@
> 
>  #include "screenint.h"
>  #include "regionstr.h"
>  #include "bstore.h"
>  #include "colormap.h"
>  #include "cursor.h"
>  #include "validate.h"
>  #include "X11/Xproto.h"
>  #include "dix.h"
> 
>  typedef struct _PixmapFormat {
>      unsigned char      depth;
>      unsigned char      bitsPerPixel;
>      unsigned char      scanlinePad;
>      } PixmapFormatRec;
> 
>  typedef struct _Visual {
>      VisualID           vid;
>      short              class;
>      short              bitsPerRGBValue;
> -    short              ColormapEntries;
> +    unsigned long      ColormapEntries;
>      short              nplanes;/* = log2 (ColormapEntries). This does not
"unsigned short" may help for Pseudocolor 15bit without breaking the
XFree 86 ABI. The question is whether such an intermediate step is
feasible or whether directly moving to "unsigned long" is the better
way to go...

Julien
-- 
Julien Lafon
Senior Staff Engineer, Hitachi