From owner-freebsd-current Sat Jun 29 19:13:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA03845 for current-outgoing; Sat, 29 Jun 1996 19:13:03 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA03829 for ; Sat, 29 Jun 1996 19:12:58 -0700 (PDT) Received: from DeepCore.dk (aalb23.pip.dknet.dk [194.192.0.183]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id MAA18152 for ; Sat, 29 Jun 1996 12:27:24 -0700 Received: (from sos@localhost) by DeepCore.dk (8.7.5/8.7.3) id VAA00534; Sat, 29 Jun 1996 21:14:51 +0200 (MET DST) Message-Id: <199606291914.VAA00534@DeepCore.dk> Subject: Re: Syscons CUT&PASTE functionality added...y To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 29 Jun 1996 21:14:50 +0200 (MET DST) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <199606291335.PAA28476@uriah.heep.sax.de> from J Wunsch at "Jun 29, 96 03:35:44 pm" From: sos@FreeBSD.ORG Reply-to: sos@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 ..