fanj@remb6489.wpd.sgi.com (Fan Jiao) (09/13/90)
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. 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. On the other hand, it is quite obvious that X11R4 requires too much memory and other hw support(a decent paging). Can we think of some kind of "X Light" so that people can do some kind "motif" work using Minix? It is clear that Minix does not need to support FULL X11R4, and a lot of things can be simplified also. -- - Fan Jiao
bunnell@udel.edu (H Timothy Bunnell) (09/13/90)
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 obvious how extensive kernel support should be or how support should be distributed within the kernel. Here are some things to consider in trying to set up graphics for Minix: 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? 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. 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? >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. > 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. >-- >- Fan Jiao -- Tim Bunnell <bunnell@udel.edu>
templon@copper.ucs.indiana.edu (jeffrey templon) (09/13/90)
How about MGR, the windowing interface from bellcore (available by anon ftp from bellcore.com)? it seems similar to X and uses a client-server model. i don't know if it would be possible to write some glue routines which would map X-windows calls to MGR routines. there is some documentation on the C interface library at bellcore (mgr-man.out or something like that.) MGR already (the server; i guess the client would run on any machine) runs on suns, Macs, decstation 3100, and AT&T unix-pcs. Other machines may be supported but I don't remember. The reason it was ported to the unixpc is precisely the one you mentioned, X takes up too much memory space. Jeff
eesrajm@cc.brunel.ac.uk (Andrew J Michael) (09/14/90)
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. > > First of all, I think we need at least two drivers, EGA and VGA. (stuff deleted) > -- > - Fan Jiao NO NO NO !!!! Please remember that (MINIX != MINIX-PC). Any graphics primitives need to work on ALL the machines to be really of use to the entire MINIX community. It's no good just writing VGA and EGA drivers; what about the Mac, ST and Amiga ? Andy Michael -- Andy Michael (eesrajm@cc.brunel.ac.uk) " Software cannot be written to 85 Hawthorne Crescent be completely free of errors." West Drayton Middlesex - Acorn Computers Ltd. UB7 9PA
7103_2622@uwovax.uwo.ca (Eric Smith) (09/14/90)
In article <58364@iuvax.cs.indiana.edu>, templon@copper.ucs.indiana.edu (jeffrey templon) writes: > How about MGR, the windowing interface from bellcore (available by anon > ftp from bellcore.com)? it seems similar to X and uses a client-server > model. i don't know if it would be possible to write some glue routines > which would map X-windows calls to MGR routines. there is some documentation > on the C interface library at bellcore (mgr-man.out or something like that.) > MGR already (the server; i guess the client would run on any machine) runs > on suns, Macs, decstation 3100, and AT&T unix-pcs. Other machines may be > supported but I don't remember. The reason it was ported to the unixpc > is precisely the one you mentioned, X takes up too much memory space. MGR does look nice. I've ported it to the atari ST (to run under MiNT, not minix). Porting it to minix should be relatively straightforward, once two things are added to the kernel: pseudo-ttys and a screen driver that allows direct access to screen memory (e.g. the /dev/screen driver I wrote for ST1.1). Having some sort of access to the blitter chip might help as well; it visibly improves the performance. MGR is not as big a memory hog as X, but it's not going to fit in small model on PC's: $ size mgr text data bss dec hex 123784 57604 6392 187780 2dd84 mgr $ ls -l x:\mgr* -r--r--r-- 1 1 315464 Jan 1 1980 x:\mgr.004 (the "x" pseudo-drive in MiNT is like the /proc filesystem in V9; the "size" of the file is the amount of memory consumed by the running system, in this case mgr with two windows open). -- Eric R. Smith email: Dept. of Mathematics ersmith@uwovax.uwo.ca University of Western Ontario ersmith@uwovax.bitnet London, Ont. Canada N6A 5B7 ph: (519) 661-3638
hp@vmars.tuwien.ac.at (Peter Holzer) (09/14/90)
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 |
cyliax@ecn.purdue.edu (Ingo Cyliax) (09/15/90)
While we are talking about a standard graphics interface, why don't we implement something really 'standard', like a subset of VDI or PostScript. What does POSIX say about graphics interfaces ? Why don't we compile a list of graphic interfaces and compare them in terms of functionality/complexity ? I think that would be _alot_ better than having more 'pseudo' standards. Making the graphics device EGA/VGA or Macintosh compatible, wouldn't make much sense, since we are not really running DOS and Macintosh applications under Minix anyway. -ingo -- /* Ingo Cyliax ECN, Electrical Engineering Bldg. * * cyliax@ecn.purdue.edu Purdue University, W. Lafayette,IN 47907 * * ing@cc.purdue.edu Work: (317) 494-9523 * * cyliax@pur-ee.UUCP Home: (317) 474-0031 */
V2057A%TEMPLEVM@pucc.princeton.edu (Juan Jose Noyles) (09/15/90)
I think the question of which graphics interface to support should be looked at in terms of the applications that MINIX will be supporting. If we're going to be doing lots of unique stuff, we'd probably be better off starting from scratch. If we want to eventually run anyone's software that's currently running, we'd better find out statistically what direction "the industry" is going in. In the PC world, there seem to be 2 standards emerging: SAA & X-windows. Since X has the advantage of being of UNIX origin, and everyone knows (or should know) that IBM regrets not having had the Bell Labs contract so that UNIX could be an IBM product now, perhaps a little gambling is in order? Personally, I'd adopt the NeXt interface. I *love* the black hole!
matthew1@stretch.cs.mun.ca (Matthew J. Newhook) (09/15/90)
cyliax@ecn.purdue.edu (Ingo Cyliax) writes: >While we are talking about a standard graphics interface, why >don't we implement something really 'standard', like a subset >of VDI or PostScript. What does POSIX say about graphics >interfaces ? Why don't we compile a list of graphic interfaces >and compare them in terms of functionality/complexity ? I think >that would be _alot_ better than having more 'pseudo' standards. >Making the graphics device EGA/VGA or Macintosh compatible, >wouldn't make much sense, since we are not really running >DOS and Macintosh applications under Minix anyway. >-ingo How about implementing a CGI terminal. This will be an international standard within the year, so if your looking for a standard here's one. >-- >/* Ingo Cyliax ECN, Electrical Engineering Bldg. * > * cyliax@ecn.purdue.edu Purdue University, W. Lafayette,IN 47907 * > * ing@cc.purdue.edu Work: (317) 494-9523 * > * cyliax@pur-ee.UUCP Home: (317) 474-0031 */ -- ----------------matthew1@stretch.cs.mun.ca "Living in the limelight; the universal dream for those who wish to seem. Those who wish to be must put aside the alienation, get on with the facination, the real relation, the underlying theme" - Rush
michael%sunham@sun.com (Michael Joswig (Vertriebsunterstuetzung Hamburg)) (09/17/90)
Fan Jiao wrote > 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. Yes, a very good idea, but did you recognize that there are many other Minix users who don`t have an PC/AT/eTC? It would be a much better idea to use a Graphics Library which can be used by different kinds of computers (Sorry for my non-English!). I thought Minix is a portable system, which means to me (Correct me if I`m wrong) programs can be used on any kind of Computer with only a small amount of changes. Michael J. Joswig.
hp@vmars.tuwien.ac.at (Peter Holzer) (09/17/90)
matthew1@stretch.cs.mun.ca (Matthew J. Newhook) writes: >How about implementing a CGI terminal. This will be an international >standard within the year, so if your looking for a standard here's one. Could you post a description of the capabilities of such a terminal? We seem now to be in a stage of discussion where everybody throws names into discussion (X, MGR, Postscript, VDI, CGI, ...) and the majority of the people does not know what we are talking about (I know X, and I have an idea what postscript is like, and if VDI is what GEM uses, I know that too, but the rest I have never heard about). So please, if you propose any "standards" to be implemented, say what functions are in that standard, how big a typical implementation is, if special hardware is needed (Postscript does lots of floating point operations so a coprocessor is almost necessary), tell us of your experiences with implementations, etc. Regards, Peter. -- | _ | 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 |
templon@copper.ucs.indiana.edu (jeffrey templon) (09/17/90)
Hi, I was the original fellow to post about MGR so I will describe it a little; I can't do too much describing since I have only begun to explore it myself. The MGR system seems to consist of two main parts. The first part is a C-language library of functions. These functions are called from a MGR-aware program and are used to draw into windows, create windows, cut/paste between windows, etc. The second part is the actual MGR program, which receives the output from the MGR functions and handles drawing the windows, executing the drawing commands, etc. The library has functions and macros which only require the C stdio library to be implemented; no X library, etc. or graphics libraries need to be linked in with the MGR function library. When a function is called to create a window, say, a certain escape sequence followed by some digits is sent to standard output. Standard output should be connected to the MGR program itself. This program knows what to do when it sees the escape codes. This part of the system contains the machine dependency, as it has to know how to draw things onto the screen. Thus, MGR would not solve the problems mentioned here about graphics primitives in the kernel, etc,; it would be oriented more towards solving the user-interface question. Having the standard graphics primitives mentioned before in this discussion would help to make MGR more portable to different machines running minix. The mgr-aware programs (ones which make calls to the MGR library of functions) are already portable, since they only use the stdio library. I can give some limited impression of the system. It seems to be fast; my experience with it is running with MGR on a Macintosh, connected through a 2400 baud modem to a vax on campus running ultrix 3.1. I had no trouble whatsoever compiling and linking the demo MGR-aware programs (a few clock programs, and some bouncing-box kind of things) on the ultrix vax, even though the distribution said "sparc". The Mac side looked to be unpolished; there was some lossage of characters and not all of the advertised functions worked; however I got the impression that the Mac MGR program was beta (there was almost no Mac-specific documentation.) It would be useful to hear from someone who has worked with MGR before on a Sun or other machine, where presumably the program is full-featured. Mostly it was very fast; I have experience with a program which plots to VersaTerm on the Mac using TEK4010 graphics codes and it is very slooowww compared to MGR. I believe that this same approach is used by X; the server (program which actually handles drawing the things on the screen) knows about and is optimized for the hardware, while the client (the program which is doing the computations) knows essentially nothing about the hardware and sends brief, standard codes out to the server device when it wants to draw things. This is about all I know wrt MGR. If people are interested, there is a document describing the C library functions and a MGR man page that I can post. The C library function document tells what all the MGR "primitives" are (drawwindoww, arc, vector, whatever.) Jeff Templon