Date: Wed, 19 Feb 1997 11:33:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: sos@ravenock.cybercity.dk (Søren Schmidt) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, hm@kts.org, ccsanady@nyx.pr.mcs.net, joerg_wunsch@uriah.heep.sax.de, FreeBSD-hackers@freebsd.org Subject: Re: pcvt/132 columns Message-ID: <199702191833.LAA13401@phaeton.artisoft.com> In-Reply-To: <199702191034.LAA09053@ravenock.cybercity.dk> from "Søren Schmidt" at Feb 19, 97 11:34:52 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Look at the "Linux GGI" code (run a search on AltaVista for it, or > > look for "Generic Graphic Interface" in the Linux groups on DejaNews). > > It is *exactly* the "super console" design that never got done in > > the BSD camps after it was first discussed in fall of 1993. > > I've looked at it, and I'm not that impressed. It tires to solve the > problems we all know and love, but its still VERY green. I agree. I was responding to the idea Mike put forward: ] ... ] the fact that they haven't been ] implemented should tell you something very important. ] ... to wit: they *have* been implemented. > Its like the svgalib, its starts out as a good idea, but fall short > in getting enough support for all the different chipsets. It > seems they only have very rudimentary support yet, they havn't > gotten all of XFree86 in there yet... I know. And I'm not advocating that... they have approached it differently than I would have approached it: I would have started with an SVGA driver in a framework which did not preclude (but also didn't initially provide) drivers with more suported modes, both text and graphic. > Even XFree86 has now the problem that it "only" supports so many > chipsets, and I (and lots of others) has found it nessesary to > go BUY (yuck!) a Xserver to cope with ones wierd videohardware. Different problem. Manufacturers haven't learned how to write video BIOS yet -- or they intentionally avoid standardizing on a mode data abstraction mechanism to make it difficult to support cards from them *and* their competitors. > I think we are better of letting the Xserver vendors have the > "good times" doing the chiplevel support (hey then they can live > too!), and let the rest of us just use X, and then spend the > huge amounts of time we save on other businesses. Support for mode selection and access type (linear frame buffer, etc.) can be logically seperated from sending chipset specific commands for line draws, etc.. I'd still keep part of DDX in user space. > Oh, yes and the GGI people has allready written off all the *BSD's > by cribbeling the code with GNU's copytheft... > (XFree86 Inc can now find lots of their code GNUinfected :) :) ) I saw that too; like I said: they have approached it differently than I would have approached it. > Besides this I still think we could need a simple system that will > run on std VGA/EGA/CGA/HGA, and provide a simple graphics interface > for sysadm utils and the like, but being REAL small on resource > usage (yes I have been working on this for a looooong time, and > have most of whats needed, just no real use for it yet). > This can be done with the support we allready have, including > switching vtys etc etc.... If we look at the current console driver as our "default" SVGA driver, then we have this support already. The missing piece is the component seperation of emulation and VT management from mode and access type. This seperation would be a win in any event, even if we never took it any further. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702191833.LAA13401>