Date: Sun, 16 Feb 1997 11:33:14 +0100 (MET) From: Søren Schmidt <sos@ravenock.cybercity.dk> To: jdc@xinside.com (Jeremy Chatfield) Cc: hm@kts.org, FreeBSD-hackers@FreeBSD.org, FreeBSD-current@FreeBSD.org Subject: Re: pcvt/132 columns Message-ID: <199702161033.LAA01362@ravenock.cybercity.dk> In-Reply-To: <33068F05.708D5F1B@xinside.com> from Jeremy Chatfield at "Feb 15, 97 09:37:25 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Jeremy Chatfield who wrote:
>
> What I'd like to see in FreeBSD, are a more complete set of things for
> handling VT's. Fortunately, I think that the functions can be split to
> make it manageable, though I'll admit I've no intention of doing any of
> this work ;-)
Hmm, this is the showstopper EVERY time :(
> There are many ways to create a more flexible, more fully featured and
> safer VT switching mechanism than those in SVR4 and Linux. Here are
> some desirable characteristics:
>
> 1/ doesn't permit VGA BIOS control over switching, at all.
I'm not sure what you mean by that..
> 2/ uses a consistent body of knowledge for switching to a mode.
Yeah, but where do we GET that info from, SVGA cards appears at a
rate that there is NO way we can follow up on that :(
> 3/ assumes that all switches that it does not make, will be returned to
> a safe mode.
Hmm, I think that the code should be able to return the card to a well
determined state, regardless of what have been done to it. We have no
way of demanding that others set up things correctly.
> 4/ is triggered whenever switching to a specific VT.
allready so
> 5/ has VT specific configuration modes.
you mean pr VT configs or what ??
> 6/ may use a VGA library, if one is present, so that games and other
> non-X graphics, can use a common knowledge base for safer switching.
That would be nice, but who is going to make the HUGE affort of
producing this, with support for bezillions of video chipsets ??
> The key points that I'm trying to make, are that it should not be the
> responsibility of the X Server to guess what knowledge base was used to
> set up a text mode, and that this is reasonably a function of an
> Operating System (providing controlled access to a shared resource).
> Once you start to think like that, wider solutions with more features
> are possible.
As long as nobody REALLY cares about this, the X server is going to
HAVE to take on this responsibility.
I see only one really usable way, and that is to use the BIOS on
the card, utilizing the VM86() call that we still does not have.
This will give us the methods we need without us chasing a constantly
moving target.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team
Even more code to hack -- will it ever end
..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702161033.LAA01362>