Date: Fri, 7 Mar 1997 12:49:34 +0100 (MET) From: Mikael Karpberg <karpen@ocean.campus.luth.se> To: ccsanady@nyx.pr.mcs.net (Chris Csanady) Cc: FreeBSD-hackers@FreeBSD.org Subject: Re: pcvt/132 columns Message-ID: <199703071149.MAA25547@ocean.campus.luth.se> 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
According to Chris Csanady: > > >As Chris Csanady wrote: > > > >> 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. > > There would be a generic graphics driver of sorts, that is primarily > concerned with setting the state of the graphics board. I dont know the > specifics, but what I see is a kernel module for each of the cards that > implements a certain set of functions that set the state. These would > be well defined by the generic driver interface, and called when > necessary to switch resolutions, etc. > > If such a standard interface were to be implemented in the X server, I > think it would make it easy to creat kernel modules for this. I could > be wrong, but it seems to me it would just be moving some code around, > and it would benefit everyone. I think that this would be much easier > than designing a generic acceleration and stuff the whole driver in the > kernel, but would include most of the important benefits. I'm not saying no one has thought of this before, but WHY in gods name, not just use THE standard interface? Hard to keep track of all new cards? Feeling happy when the driver comes out 1 year after the card is realeased? Guess what? The drivers... *drums* _comes_with_the_cards_ TADA! It's supplied by the manufacturers. It's downloadable from their sites. Yes... I'm talking Windoze drivers. That's a standard interface for you. One which will allow you to use any card with full driver support. That's would be the only thing wee needed to implement in the kernel, except for a few drivers for standard VGA etc, so that we can the get user booted. Ones you support that driver interface, and a loading of such a driver file, it's easy to keep track of all cards. With 2D/3D accelleration and anything else you want, fully supported. All the user has to do is insert the disk that came with his card and mcopy a file into a directory which is scanned at boot time, or something like that. This sounds great to me. Where's the problem? Why is this not allready done? I admit I really don't know what I'm talking about in this case, but the idea in itself seems excellent, and it should be doable. What am I missing? No, we can't send those drivers with the distribution, but we can have the drivers we have today in the distribution, and the interface to load a windows NT driver, and then let the user add the file himself, if he has a need for it. So again... What, the problem with this idea? I'll just STFU and crawl back under my rock now :-) /Mikael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703071149.MAA25547>