ndd@macbeth.cs.duke.edu (Ned D. Danieley) (02/08/90)
when a user on a 3/260CXP selects xlock, he gets the following error message: twm: client illegally changed colormap (i = 0, j = -1 xlock does lock the screen, but the patterns don't look right, and the qix display looks bad. this didn't happen under R3; any idea why it would with R4? X11R4, SunOS 4.0.3, Sun 3/260CXP, gcc 1.35, fixes 1 installed, shared libs. xlock has had the patch from naughton@sun.com installed. Ned Danieley (ndd@sunbar.mc.duke.edu) Basic Arrhythmia Laboratory Box 3140, Duke University Medical Center Durham, NC 27710 (919) 660-5111 or 660-5100
mikey@decwrl.dec.com (Mike Yang) (02/08/90)
In article <17381@duke.cs.duke.edu> ndd@macbeth.cs.duke.edu (Ned D. Danieley) writes: >when a user on a 3/260CXP selects xlock, he gets the following >error message: > >twm: client illegally changed colormap (i = 0, j = -1 > >xlock does lock the screen, but the patterns don't look right, >and the qix display looks bad. this didn't happen under R3; >any idea why it would with R4? The problem is that xlock calls XInstallColormap itself, instead of setting the colormap window attribute and letting the window manager peform the installation, as the ICCCM states. The version of twm shipped with R4 enforces this convention and negates the installation by reinstalling the colormaps it wants installed. Therefore, the hardware colors are not as xlock expectes, and this would explain why things "don't look right." The solutions are to fix xlock to follow ICCCM conventions, or to use a less restrictive window manager. ----------------------------------------------------------------------------- Mike Yang Western Software Laboratory Digital Equipment Corporation mikey@wsl.dec.com decwrl!mikey 415/853-6677
stripes@eng.umd.edu (Joshua Osborne) (02/08/90)
In article <97@gilroy.dec.com> mikey@decwrl.dec.com (Mike Yang) writes: [...] >The problem is that xlock calls XInstallColormap itself, instead of >setting the colormap window attribute and letting the window manager >peform the installation, as the ICCCM states. [...] >The version of twm shipped with R4 enforces this convention and >negates the installation by reinstalling the colormaps it wants >installed. Therefore, the hardware colors are not as xlock expectes, >and this would explain why things "don't look right." > >The solutions are to fix xlock to follow ICCCM conventions, or to use >a less restrictive window manager. I fixed my version to not install color maps, and to instruct the window manager to do it (I use twm right now). However the colormap *STILL* doesn't look right. The qix is made of the colors allocated by the other clients, half of which are black. The code seems to make a HSB map for the qix but I have never seen it. Life and hop (the fractals) also seem to suffer from an overabundance of black. I am shure twm installs my colormap, I set the ColormapChangeMask bit so I could get colormap notify events. I recieve one on the xlock window for the cmap that xlock creates, and I never see it get uninstalled. So something strange is up with colormaps, do I not only have to tell twm to install my map, but that I changed it? That doesn't seem right... -- stripes@wam.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Mutitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood Who needs friends when you can sit alone in your room and drink?