From owner-freebsd-hackers  Thu Oct 17 14:56:48 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id OAA02842
          for hackers-outgoing; Thu, 17 Oct 1996 14:56:48 -0700 (PDT)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA02835;
          Thu, 17 Oct 1996 14:56:44 -0700 (PDT)
Message-Id: <199610172156.OAA02835@freefall.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA052979402; Fri, 18 Oct 1996 07:56:42 +1000
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: high resolution text modes
To: sos@FreeBSD.org
Date: Fri, 18 Oct 1996 07:56:41 +1000 (EST)
Cc: proff@suburbia.net, hackers@FreeBSD.org
In-Reply-To: <199610171051.MAA05164@ra.dkuug.dk> from "sos@FreeBSD.org" at Oct 17, 96 12:51:20 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

In some mail from sos@FreeBSD.org, sie said:
> 
> In reply to Julian Assange who wrote:
> > 
> > Success!
> > 
> > I'm now running on a 100x30(16x9 font) 88hz modified FreeBSD syscons.c.
> > I still have some issues to address vis automatically changing between
> > resolutions on different VT's. Some video cards clocks require
> > programming in particular ways. It would be nice if one could do a
> > "register dump" of the current mode and save it in an array and later
> > restore the values when the VT is again made active. I am not hopeful
> > given the hardware dependent manner that many dot clocks are programmed
> > in and the use of register extension portals. I suspect that any
> > solution would approach the code size of SVGATextMode itself.  My
> > intention is to remove per-vt resolutions entirely. They seem like
> > creeping featurism to me and of little use - I noted a comment in the
> > linux kernel code stating that the linux per-vt resolutions which were
> > removed for similar reasons.
> 
> Erhm, You are not going to remove anything of that kind from
> syscons if thats what you want. I'll provide you with a interface
> for doing this if need be, but this will NOT go into syscons, or
> I'll resign as its maintainer.

Well, how about "option NEW_SYSCONS" for those who'd rather have a 100x30
(or better) console without having to do it per-vt or who want it before
multiuser mode ?

Darren