pcolby@carbon.prime.com (Peter Colby bldg 4-1) (02/23/90)
I am running Xsun (through xinit) on a Sun 3/60 with a cgfour
frame buffer. I would like to use the second (mono) screen in addition
to the standard color display but I can't figure out how to access it.
If anyone has actually gotten both screens to work as described
in the docs, could they describe the process.
X.V11R4 by the way, mit sample server.
Thanks,
Peter Colby
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
UUCP: {sun,decvax,linus}!cvbnet!pcolby ||| "We has met the enemy and he is us."
UUCP: pcolby@carbon.prime.com ||||||||||| Pogo
INTERNET: pcolby%carbon.prime.com@RELAY.CS.NET |||mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (03/06/90)
> I am running Xsun (through xinit) on a Sun 3/60 with a cgfour frame > buffer. I would like to use the second (mono) screen in addition to > the standard color display but I can't figure out how to access it. > X.V11R4, mit sample server. The comments below apply to the MIT servers for both R3 and R4. Make sure that - /dev/cgfour0 exists - /dev/fb exists - /dev/bwtwo0 does not exist - /dev/bwtwo1 does not exist Do not give a -dev option to the server. Now to check: run xdpyinfo and it should report two screens. Under R4, screen 0 should be your color screen: an 8-bit screen with six visuals available, one of each type. Screen 1 should be a 1-bit StaticGray screen; that's your mono screen. Under R3, screen 0 should be a 1-bit StaticGray screen and screen 1 should be an 8-bit PseudoColor screen. (If you can't get xdpyinfo to list both screens, you haven't a hope of actually *seeing* the mono screen.) To see the other screen, you just have to get the mouse on it somehow. The simple thing to do is to ensure you did not give the -zaphod option to the server (R3 servers don't even have -zaphod, I think), and then move the mouse off the left or right edge of the color screen. Programmatically, you can XWarpPointer to a position on the desired screen and it should flip to that screen (I have a program that allows you do this, if you want it). der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu (Actually, the 1-bit screen *should* be a PseudoColor screen; that's what the hardware is. But StaticGray was easier, no doubt.)
john@acorn.co.uk (John Bowler) (03/08/90)
In article <9003060725.AA00997@Larry.McRCIM.McGill.EDU> mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) writes: [talking about R4 on a SUN 3/60] > >(Actually, the 1-bit screen *should* be a PseudoColor screen; that's >what the hardware is. But StaticGray was easier, no doubt.) Last time I tried making a server do this a very large number of the clients (I admit, R2 clients) became unhappy. The problem is an exaggerated example of the ``running out of colours'' problems people have with shallow PseudoColor displays; the first 3 applications get the colours they want, then all the following applications get Alloc errors from AllocNamedColor, because there are no more slots in the default colormap :-). On a display with a default depth 1 PseudoColor visual there are no free colormap cells in the default map - because the server has already allocated White and Black for the black and white pixels. It has all the attributes of a StaticGray display but none of the advantages; in particular Alloc[Named]Color never fails on a colormap from a static visual through not being able to arrange for a suitable (:-)) colour in the colormap. John Bowler (jbowler@acorn.co.uk)
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (03/09/90)
[ >> = me ] [ > = mcsun!ukc!acorn!john@uunet.uu.net (John Bowler) in <1798@acorn.co.uk> ] >> (Actually, the 1-bit screen [on a Sun cg4] *should* be a PseudoColor >> screen; that's what the hardware is. But StaticGray was easier, no >> doubt.) > Last time I tried making a server do this a very large number of the > clients (I admit, R2 clients) became unhappy. The problem is an > exaggerated example of the ``running out of colours'' problems people > have with shallow PseudoColor displays; [...]. This is an *excellent* reason to do it this way: it weeds out broken clients. (It would be nice to have a -staticgray switch so the broken clients can be run.) Besides, things have improved. I hacked on the cg2 code to take advantage of the alternate view provided by the hardware[%], and the resulting 1-bit PseudoColor screens never give me any trouble. (This was the R3 server; I haven't (yet) made the appropriate changes to the R4 server.) > On a display with a default depth 1 PseudoColor visual there are no > free colormap cells in the default map - because the server has > already allocated White and Black for the black and white pixels. It > has all the attributes of a StaticGray display but none of the > advantages; in particular Alloc[Named]Color never fails on a colormap > from a static visual through not being able to arrange for a suitable > (:-)) colour in the colormap. The client should not - without explicit directions from the user - insist on getting its colors from the default colormap; it should create its own colormap if necessary. You do get technicolor effects, and each application (well, each window) is restricted to at most two colors, but there's no way around that, and you do have color. All[$] my clients do something like setup_color(str,col,what) char *str; XColor *col; char *what; { if (XParseColor(disp,wincmap,str,col) == 0) { fprintf(stderr,"%s: bad color `%s'\n",argv0,str); exit(1); } while (1) { if (XAllocColor(disp,wincmap,col) == 0) { if (wincmap != defcmap) { fprintf(stderr, "%s: can't allocate colormap cell for color `%s'\n", argv0,str); exit(1); } wincmap = XCopyColormapAndFree(disp,wincmap); continue; } break; } } [%] The cg2 has 8 bits per pixel, but the hardware lets you access it as either one 8-bit plane or 8 one-bit planes (or even both at once, but it's up to you to keep it straight). [$] Well, all the ones that have been overhauled since I realized how colormaps and colormap entries work. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu