Date: Mon, 18 Aug 1997 08:45:26 +0200 (MEST) From: Søren Schmidt <sos@sos.freebsd.dk> To: grog@lemis.com (Greg Lehey) Cc: jkh@time.cdrom.com, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: reset screen hardware? Message-ID: <199708180645.IAA01679@sos.freebsd.dk> In-Reply-To: <19970818122939.30413@lemis.com> from Greg Lehey at "Aug 18, 97 12:29:39 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Greg Lehey who wrote:
> 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 was design but only in a few peoples heads sofar, as we need
the 3 above points implemented first, so should we start there please ?
> 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.
Sigh, the call BIOS is the only option we've got, (well besides making
it possible to use win95/NT drivers, which is a HUGE task if at all
feasible).
There is no problem in using the BIOS (except that we dont have the
code to do it, yet). Syscons allways know exactly where it has its
video card, except in the case of X where the app reprograms
the card. Now when we have the BIOS calls working syscons takes over the
task of modifying the cards regs etc. via the BIOS, and the apps are
denied acces to the ports. Then syscons always knows where and how
the card is and can restore whatever mode it (and of cause the BIOS)
understand.
Pretty simple actually, once you have the means to call the BIOS...
Now, who volounteers the diffs ??
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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?199708180645.IAA01679>