Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 29 Jun 1996 21:14:50 +0200 (MET DST)
From:      sos@FreeBSD.ORG
To:        joerg_wunsch@uriah.heep.sax.de
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: Syscons CUT&PASTE functionality added...y
Message-ID:  <199606291914.VAA00534@DeepCore.dk>
In-Reply-To: <199606291335.PAA28476@uriah.heep.sax.de> from J Wunsch at "Jun 29, 96 03:35:44 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
In reply to J Wunsch who wrote:
> As sos@FreeBSD.ORG wrote:
>=20
> > >                               (There are more nifty but not DEC-VT
> > > related features like the ability to control the VGA RAMDAC, which =
are
> > > IMHO incompatible with syscons' goals.)
> >=20
> > Yep, because now we are talking features that doesn't work on all
> > hardware and that is The Wrong Thing because:
>=20
> This works on all VGAs.  Syscons doesn't work very well on other
> adapters at all (pcvt is somewhat better, but has also some weak
> points as well -- try using an MDA as console, and a VGA as X11
> screen).

???? one of my machines here has exactly that combination, no
problems ????

> > 1. There is no end to the supportproblem on this, and the percentage
> >    of supported hardware is falling by the minute.
>=20
> I've never got any ``support call'' regarding the RAMDAC loading. :)
> Really, you should look into the code: it's in no way card-specific!

Actually I was refering to the "and like" features.... but I'm sure
I can come up with a videocard that it won't work on :)

> > 2. The kernel size will explode if just a tiny fraction of the possib=
le
> >    video hardware is to be supported.
>=20
> Ah, i know what you're confusing this with: 132-column support.
> Anyway, this is also ``nice to have'', but it should actually be done
> as an LKM (with a generic [non-132 column] MDA/CGA/EGA/VGA driver in
> the kernel that can be overloaded by an LKM).

I'm not confusing anything, I meant exactly all the "like" features
and if you read my postings carefully, you would see that I'm advocating
for exactly a generic driver, as which I see syscons being the best
bet we have modulo some changes that I've allready done locally. Then
one can load different emulatortypes, special HW drivers etc etc, but
all my attempts to get the development in that direction has until now
been dismissed with more or less religious arguments...
I guess I should just take the currently popular action and just
commit what *I* think is the best soulution to the tree, no
questions asked...
=20
> There are other things i don't like in either console driver, like the
> hard-coded assumption about which number of scan lines is supported in
> the charactersets (for no good reason, it can be entirely calculated
> at run-time).  I've done a bit in pcvt to make it more benign, so at
> least my notebook with its 480 scanlines total looks a bit better now.

I'm not sure what you mean here... In syscons the decision on what
charset to use, is taken (at runtime) from the videomode table in the
video BIOS, so far all possible sizes is 8, 14 & 16 scanlines for the
std. modes.
As far as notebooks are concerned, we are into the HW specific section
again. My notebook will not display more than 400 lines in a text mode
without special programming. If you just use more lines the excess over
400 will dissappear out the bottom of the display. This is because it
has a builtin expand feature, which is on as a unchangeable default,
and it can ONLY be disabled by special programming of the videochip.
(I have this as an LKM so it can be done, sure, but it has _nothing_
to do in a generic driver).

So, my proposal is still to have a generic driver, with clean and
easy hooks to loadable modules. And IMNHO syscons is the closest
thing we have to that, and it is getting closer in the near future..

If I have to do that all by myself, fine, I'll do it, if we could
muster more volounteers I'll be more than happy....

Or I can just throw in the towel and let others decide and simply
do nothing (except complain on what others maybe might do......)

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-
S=F8ren Schmidt               (sos@FreeBSD.org)               FreeBSD Cor=
e 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?199606291914.VAA00534>