Date: Tue, 18 Feb 1997 09:33:57 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: ccsanady@nyx.pr.mcs.net (Chris Csanady) Cc: joerg_wunsch@uriah.heep.sax.de, FreeBSD-hackers@FreeBSD.ORG Subject: Re: pcvt/132 columns Message-ID: <199702181633.JAA11168@phaeton.artisoft.com> In-Reply-To: <199702180638.AAA05778@nyx.pr.mcs.net> from "Chris Csanady" at Feb 18, 97 00:38:42 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Others have mentioned that a frame buffer would be really slow, but that > really wasn't my intention, I should have explained a little better. It > seems I misused the term frame buffer.. what I was trying to get at was > the seperation of the code that sets the state of the graphics card, and > the code that uses it, with drawing, acceleration or whatever else. Yes. Effectively, you would move the DDX (Device Dependent X) code into the kernel. By default, you'd do generic VGA, and you'd allow a replacement driver with card specific knowledge to be loaded as an LKM. Ideally, you would make a distinction in the kernel between low, medium, and high persistence kernel memory objects, and you would make segment coloring in the binary standard, so as to seperate the character of the driver you are replacing from the character of the rest of the code in the kernel. Finally, you would allow the driver you are replacing to have its mapping paged out once it is replaced, in order to recover the memory from the now-useless driver. Segment coloring requires ELF or similar object file technology. 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?199702181633.JAA11168>