From owner-freebsd-hackers Sun Aug 17 20:02:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA15583 for hackers-outgoing; Sun, 17 Aug 1997 20:02:16 -0700 (PDT) Received: from nico.telstra.net (nico.telstra.net [139.130.204.16]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA15573 for ; Sun, 17 Aug 1997 20:02:12 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by nico.telstra.net (8.6.10/8.6.10) with ESMTP id MAA11682; Mon, 18 Aug 1997 12:59:48 +1000 Received: (grog@localhost) by freebie.lemis.com (8.8.7/8.6.12) id MAA09982; Mon, 18 Aug 1997 12:29:41 +0930 (CST) Message-ID: <19970818122939.30413@lemis.com> Date: Mon, 18 Aug 1997 12:29:39 +0930 From: Greg Lehey To: =?iso-8859-1?Q?S=F8ren_Schmidt?= Cc: jkh@time.cdrom.com, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: reset screen hardware? References: <19970817163116.16698@lemis.com> <199708170951.LAA00412@sos.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 0.81e In-Reply-To: =?iso-8859-1?Q?=3C199708170951=2ELAA00412=40sos=2Efreebsd=2Edk=3E=3B_fro?= =?iso-8859-1?Q?m_S=F8ren_Schmidt_on_Sun=2C_Aug_17=2C_1997_at_11=3A51=3A1?= =?iso-8859-1?Q?9AM_+0200?= Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog X-MIME-Autoconverted: from 8bit to quoted-printable by freebie.lemis.com id MAA09982 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id UAA15576 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Aug 17, 1997 at 11:51:19AM +0200, Søren Schmidt wrote: > In reply to Greg Lehey who wrote: >>> >>> Funny, my bigget rant has to do with people going "Why doesn't FreeBSD >>> have feature XXX?!" rather than "Here are my diffs to support feature >>> XXX, please integrate them." >> >> And would you? If I had come along with the diffs for doing it this >> way, you'd have said (with some justification) "Go away, we don't want >> all this crap in the kernel". I was, in fact, considering doing the >> implementation, but I see that it's not the way to go. > > Come on here, what at least I have been advocating for, is that > we need that functionality, but we need it done RIGHT. We allready > have so many kludges/hacks in the kernel, we don't need another one. I think you're missing the point. That's what I said. Note the "(with some justification)". > If Joe random hacker cannot graps the bigger picture, and get his > hacks in the right direction, well, I'm sorry it won't be commited. > On the other hand, if Joe mature hacker comes around, and wants to > help do the hard work along the guidelines that the responsible > person(s) have laid out (and belive me, for the most part things > has been thought long and seriously about), he will be welcommed > with open arms. Sure. No debate. > So to get concrete in this matter, we need: > > 1. Being able to call realmode code from the kernel. > > 2. Being able to run BIOS functions, that is we need to keep > track of the BIOS's workspace, most often in low memory. > > 3. Then write the code to call the right BIOS functions to > be able to talk to the video HW. > > So, if someone is SERIOUS about getting this to work, pick one > of the above, come back to me so we can get technical about > the details, and them submit the diffs. Then I'm certain it will > be committed, and the author will get his fair share of applause.. > > But gimme a break on just demanding XXX functionality, sometimes > with badly (if at all) designed hacks.... Wait a while, there was no design at all at this point. We had Mike saying that it wasn't possible, and me suggesting a possible approach. My statement was that the kernel probe routines seemed the obvious place to put such code. I stand by that statement. The question was how to find out the parameters, and the fact that the code is so voluminous makes the approach impractical. But that doesn't make the approach a hack. There is, BTW, a potential problem with the "call the BIOS" approach (which I consider marginally more of a hack, since the driver doesn't know what's going on): what if the driver has set a different mode for the board, like 50 line or some such? That would have to be redone after the BIOS call. Greg