Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!mouse From: mouse@thunder.mcrcim.mcgill.edu (der Mouse) Newsgroups: comp.sys.next Subject: Re: Xnext (mouse-X) Message-ID: <1991Mar20.130027.17254@thunder.mcrcim.mcgill.edu> Date: 20 Mar 91 13:00:27 GMT References: <1991Mar15.052404.4117@neon.Stanford.EDU> <1991Mar15.212326.19805@neon.Stanford.EDU> Distribution: na Organization: McGill Research Centre for Intelligent Machines Lines: 34 In article , scott@texnext.gac.edu (Scott Hess) writes: > In article <1991Mar15.212326.19805@neon.Stanford.EDU> zimmer@calvin.stanford.edu (Andrew Zimmerman) writes: >> 2. xmag doesn't seem to work correctly. Both xmag on a NeXT, and >> xmag running on a DEC3100 using a NeXT display had the same >> wrong image. > Yeah, I've noticed that, too. Apparently it scales stuff incorrectly > or something. This was one of the first things I found broken, back when I first did things under 1.0. Two possible reasons come to mind. One is that xmag is just one of those programs that doesn't like a 2-bit StaticGray visual. This seems doubtful, at best. The other is that every version of mouse-X I've ever distributed contains a protocol violation. I was not aware of this until comparatively recently and have not (yet) fixed it; I assume Howie's distribution has it as well, because he hasn't said anything to me about it. What is this violation? Simply this: the protocol does not allow two-bit pixels on the wire. They must be expanded with two bits of padding. (At the last X conference, Keith Packard said something to me about their never expecting anyone to make a 2-bit display when I mentioned this to him.) It seems entirely plausible that xmag is getting indigestion over this: my server advertises a pixmap format with 2-bit pixels.... der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu