Date: Thu, 24 Oct 1996 07:40:26 +1000 (EST) From: Julian Assange <proff@suburbia.net> To: freebsd-hackers@freebsd.org Subject: VSTa graphics and Linux GGI (was Re: put pixel on screen in VGA) (fwd) Message-ID: <199610232140.HAA09248@suburbia.net>
next in thread | raw e-mail | index | archive | help
Forwarded message: >From vandys@cisco.com Thu Oct 24 05:50:32 1996 Message-Id: <199610231916.OAA23073@terra.igcom.net> Date: Wed, 23 Oct 1996 14:16:40 -0500 From: jeske@igcom.net (David Jeske) To: vsta@cisco.com Subject: VSTa graphics and Linux GGI (was Re: put pixel on screen in VGA) References: <Pine.BSI.3.94.961022133642.26255A-100000@black.cypher.net> <199610230940.LAA22692@clipper.ens.fr> X-Mailer: Mutt 0.48.1 Mime-Version: 1.0 X-Uri: <URL:http://www.igcom.net/~jeske/>; In-Reply-To: <199610230940.LAA22692@clipper.ens.fr>; from Francois-Rene Rideau on Oct 23, 1996 11:40:58 +0200 On Oct 23, rideau@clipper.ens.fr (Francois-Rene Rideau) wrote: >> the whole point of the graphics arbitration server is that it does nothing >> but multiplex access to the physical hardware. any sort of abstraction >> occurs at higher levels, and is therefore totally optional. > Of course, a ggi client can use the ggi screen just like a frame > buffer! Yes, but it can't just get direct hardware access to it.. from what I've read anyhow... (i.e. fiddling with registers and such) I have read a bunch about the GGI and here are my conclusions: The hope is that the GGI will be "the" interface for all graphics programs to use on Linux. However, currently graphics programs for Linux work in a "cooperative" mode where they get full access to the hardware, and when the kernel tells them to "let go" they are required to put the screen back into the text mode it was in before they got it. (i.e. for a virtual console switch) Xfree86 does this, svgalib does this, and GGI does this as well... In the future it's hoped (expected?) that svgalib will be repaced/incorporated into the GGI, and Xfree86 will talk to the GGI instead of using custom drivers. If the performance is there, this will be a big win in terms of centralized hardware support and simplification of configuration. It will also remove the requirement that graphics programs run as root on Linux. GGI as it relates to VSTa: I think in the end a GGI-port to vsta would be beneficial if only to take advantage of Linux's popularity and support. Of course it would be only source compatible, since the structure of GGI on VSTa would differ and there are no existing plans to run Linux binaries on VSTa anyhow. [Who is interested in working with GGI people on a port?] However.. I've also concluded that it will be worthwhile for us to also have this lower "cooperation layer" for graphics subsystems that talk directly to the hardware to play nice in... While we could abstract this out of cons, I see no pressing reason to do so. This level should not be a primary level of abstraction, it will just be there so that direct-to-hardware graphics subsystems don't have to fight. I would like to mirror the "effect" of Linux, with a slightly different mechanism. If anyone is familiar with the specifics of how virtual console switching on Linux works with respect to graphics software like XF86 and svgalib, I would appreciate a summary of the technical details. Otherwise, I'll spend some time looking into it myself to see how they do it... My initial VSTa solution: - "Graphics" subsystems will tell cons that they want to go into "hardware" mode with the card. (GIMME-HW) - cons will let them know when it's okay (i.e. they are the current VC) (GO-AHEAD) - when a "vc switch" is to occur, cons will ask the client to put it back to the way it got the video card (LET-GO). - After the client has LET-GO, cons can then continue switching to another console safetly. (TAKE-HW) - There should also be a mechanism for telling cons to switch to a particular VC, listing the VCs, and for telling cons not to interpret ANY keys (i.e. no VC switch keys) This is intended to be VERY simple, it shouldn't take long to implement, and my goal is to get it up and going ASAP so that I can get MGR to play nice and still switch to another VC while it's running. I think the major decision I need to figure out is what mechanism will be used to deliver functions. (ie GIMME-HW, GO-AHEAD, LET-GO, TAKE-HW) It should be possible to do them either with stat messages or with VSTa events. Unless I can think of a reason they need to be asynchronous events though, I am pretty sure I'll just make them messages. -- David Jeske (N9LCA) + jeske@igcom.net + http://www.igcom.net/~jeske/ -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | C7F81C2AA32D7D4E4D360A2ED2098E0D | +---------------------+--------------------+----------------------------------+
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610232140.HAA09248>