Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Feb 1997 20:00:02 +1100 (EST)
From:      David Dawes <dawes@rf900.physics.usyd.edu.au>
To:        ccsanady@nyx.pr.mcs.net (Chris Csanady)
Cc:        hackers@freebsd.org
Subject:   Re: pcvt/132 columns
Message-ID:  <199702180900.UAA22646@rf900.physics.usyd.edu.au>
In-Reply-To: <199702180638.AAA05778@nyx.pr.mcs.net> from Chris Csanady at "Feb 18, 97 00:38:42 am"

next in thread | previous in thread | raw e-mail | index | archive | help
>>> Just a thought, but what about using some sort of generic frame
>>> buffer driver in the kernel.  I dont think it should be the
>>> responsibility of the Xserver or anything else to twiddle with the
>>> cards settings directly.  The kernel would just need to know a few
>>> card specific things about setting timings, etc.
>>
>>Basically: Yes!
>>
>>However: have you ever counted the number of hardware-dependant code
>>lines in XFree86?  No?  Then you don't know what you're talking
>>about. :~)  Last time i counted, we spoke about some 200+ Klines of C
>>code. :-O
>
>Others have mentioned that a frame buffer would be really slow, but that
>really wasn't my intention, I should have explained a little better.  It
>seems I misused the term frame buffer.. what I was trying to get at was
>the seperation of the code that sets the state of the graphics card, and
>the code that uses it, with drawing, acceleration or whatever else.

A large proportion of the hw-specific code is required precisely for
initialising the state of the graphics card.  From our (XFree86's)
experience, this is the hard part.  The rest is relatively easy.

I'd strongly suggest that anyone interested in following this up get
themselves very familiar with the details before speculating about it.
I'm not saying it shouldn't be done (it'd be great to get some of this
stuff out of the X servers).  I'm saying that it isn't nearly as easy
as you're making it sound (the comparison with Sun hardware is not at
all appropriate -- most of that hardware doesn't ever run in more than
one video mode, and that is initialised by the firmware).

Being able to make use of the video BIOS to do this sort of thing may
help, but I've seen comments suggeting that even this is no magic
solution.

>>Have a look at /usr/src/usr.sbin/pcvt/set2061/, just to get the
>>feeling for _one_ (now already fairly aged) piece of hardware that
>>needs to be supported, the ICD2061A clock synthesizer.

And the exact details of programming a chip like this depends on the
card it is on.  The version in pcvt/set2061 only deals with S3 cards.

David



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702180900.UAA22646>