From owner-freebsd-hackers Tue Feb 18 01:01:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA15076 for hackers-outgoing; Tue, 18 Feb 1997 01:01:30 -0800 (PST) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA15057 for ; Tue, 18 Feb 1997 01:01:25 -0800 (PST) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.8.5/8.8.2) id UAA22646; Tue, 18 Feb 1997 20:00:02 +1100 (EST) From: David Dawes Message-Id: <199702180900.UAA22646@rf900.physics.usyd.edu.au> Subject: Re: pcvt/132 columns In-Reply-To: <199702180638.AAA05778@nyx.pr.mcs.net> from Chris Csanady at "Feb 18, 97 00:38:42 am" To: ccsanady@nyx.pr.mcs.net (Chris Csanady) Date: Tue, 18 Feb 1997 20:00:02 +1100 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>> 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