Path: utzoo!attcan!uunet!mcsun!tuvie!vmars!hp From: hp@vmars.tuwien.ac.at (Peter Holzer) Newsgroups: comp.os.minix Subject: Re: Graphics Lib, GUI, ..., "X Lit"? Keywords: Minix V1.5, EGA, VGA, Drivers, GUI Message-ID: <1818@tuvie> Date: 14 Sep 90 15:06:25 GMT References: <69159@sgi.sgi.com> <30331@nigel.ee.udel.edu> Sender: news@tuvie Lines: 137 bunnell@udel.edu (H Timothy Bunnell) writes: >In article <69159@sgi.sgi.com> fanj@remb6489.wpd.sgi.com (Fan Jiao) writes: >>While hearing people talking about X for Minix, it seems that >>at least we need some graphics primitives to start with playing >>with graphics stuff. >> >I agree. Some primitives need to be included in the kernel. It is not I agree, too. >1. Should a graphics kernel support switching the hardware in and out of > graphics and text modes, or always run in bitmapped graphics mode with > no hardware character generation or scrolling? Bitmapped only (or configurable at startup). Once you start with a window manager and have several programs running in windows you will get troubles if some program decides it wants text mode for faster scrolling and switches ... >2. How (if at all) should user processes get access to video ram? > A. Directly read from or write to something like /dev/screen? > B. Open some kind of /dev/screen giving it the address of a > (user space) memory block the the program will write to > directly as a virtual screen and let /dev/screen update > the real video ram from the virtual screen? > C. Load all graphics capabilities into /dev/console and > have it look like a graphics terminal (e.g., Tek 4010 :-)? > Each of these has several obvious advantages and disadvantages. I would vote for a server (like FS and MM) which processes can send messages to (and get answers back). I think we would need the following RPCs: (I am using slightly modified Turbo C functions because I am used to them. If you want other names or other functionality, I am open to discussion) int getmaxcolor (void); int getmaxx (void); int getmaxy (void); void setcolor (int color); void setfillpattern (void * pattern); We need a method to specify the pattern machine independent here. Differences in word size, endianness and bit ordering in video hardware (MSB left or right) should be transparent to the user/programmer. void setwritemode (int mode); There are sixteen possible modes, of which we would need at least COPY, OR, and XOR. void setpixel (int x, int y); void moveto (int x, int y); void lineto (int x, int y); void bar (int left, int upper, int right, int lower); Fills a rectangle with current fillpattern in current color. void fillpoly (int points [][2], int nopoints); Fill a polygon. void setorigin (int x, int y); Might maybe set directions of x and y axis as well. void setcliparea (???); That's difficult. The primitive solution would be to allow only rectangular clipping regions, but that does not work well if you want overlapping windows. The Postscript solution of allowing arbitrary closed curves is the other extreme. We might want to settle somewhere in between by allowing either polygons or sets of rectangles. Does anybody know which is more efficient? void setfont (???) What fonts do we need? Bitmapped fonts are necessary for high speed, but we could allow stroked fonts too (although these could be simulated by the clients by issuing many movetos/linetos). Do we want/need proportional fonts? int gettextheight (char * text); int gettextwidth (char * text); We need these in any case. A PC with CGA might use 8x8, An Atari might use 8x16, and some other system might use proportional fonts. int outtext (char * text); Draw the text. int haspalette (void); void getpalette (int color, int * red, int * green, int * blue); The same (physical) color should yield the same RGB values on all systems regardless of the resolution of their palette (EGA 2 bits, ST 3 bits, Amiga 4 bits, VGA 6 bits, ...). To stay ahead of hardware for some time we should assume a 15bit palette (i.e. white = 32767,32767,32767). void setpalette (int color, int red, int green, int blue); Can't think of any more PRIMITIVES now, so I conclude this list. There is an additional problem if many programs use the server at the same time: The server has h-state (current color, fill-pattern, font, ...) so grave disorder may arise if each program can change this h-state without notifying another. Two solutions come to mind: Several Graphical contexts are stored in the server, and each program gets a context wich it can modify. The significant parts of the context are passed with each call (so outtext would become outtext (char * text, int x, int y, int color, font_id font);). Neither solves the problems that arise if programs can change the palette. >3. Should character generation be limited to a single bit-plane on EGA/VGA > to be as fast as possible at the expense of versatility in color? You want multi-colored characters? They sure would look nice, but I don't think we need them that much that we should define primitives for them (they can be faked by bitblt'ing). The ability to show one font in different colors is more necessary. >>First of all, I think we need at least two drivers, EGA and VGA. Also >>we may consider necessary to include an "extended lib"(non ANSI) like >>MicroSoft C's one. Then we can begin talking GUI. All the above functions would do a sendrcv to communicate with the server. >> >EGA and VGA are sufficiently alike that a single driver might handle both. >I don't see how one could avoid Hercules support as well, and a CGA driver >would follow easily from the HGC. Don't forget the non-PC users here. Our ``graphics standard'' should not leave them out. To all those who are still with me :-): I have ordered Minix 1.5 this week, and it will hopefully arrive before I am back from my holidays (in about two weeks) so I will start hacking at this then (On a 386 with a VGA card). -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technische Universitaet Wien | as evolution | | | | | hp@vmars.tuwien.ac.at | in action! | | __/ | ...!uunet!mcsun!tuvie!vmars!hp | Tony Rand |