Date: Thu, 28 Oct 1999 18:27:35 -0700 From: "Ronald F. Guilmette" <rfg@monkeys.com> To: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> Cc: freebsd-bugs@freebsd.org Subject: Re: kern/14566: Non-kernel programs have little/no control over VGA/VESA devices Message-ID: <3401.941160455@i180.value.net> In-Reply-To: Your message of Fri, 29 Oct 1999 09:00:14 %2B0900. <199910290000.JAA06014@zodiac.mech.utsunomiya-u.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199910290000.JAA06014@zodiac.mech.utsunomiya-u.ac.jp>, you wrote: > >> Yes, the vgl(3) library contains functions which implement the kinds of >> things that I was talking about, and yes, there should be a reference to >> vgl(3) _somewhere_ on the vga(4) man page. >> >> However, I think that my bug report is still very valid. >[...] >> The vgl(3) library is an ordinary, user-level library, properly documented >> in Section 3 of the manual. But the functionality it provides *must* be >> implemented in terms of some lower-level (kernel) capabilities. Those >> lower level (direct hardware control) capabilities are obviously available >> in user land (or else the vgl(3) library could not have been built) but I >> still don't know how _I_, as a programmer, can get at those lower level >> capabilities directly. >[...] > >I don't know how closely you want to control the video hardware. But, >I have a version of slightly enhanced vgl library which can do VESA >modes as well as the standard VGA modes (the version of vgl included >in -CURRENT and -STABLE cannot handle the VESA modes *sigh*). > >Soeren and I developed it, but have not yet committed to the source >tree. I can send you the new version for review if you like. Thank you. It is a generous offer, however I think you're not understanding what I am really driving at. I am merely arguing in favor of strict adherence to the general principal that low-level hardware functionality ought to be accessed in all cases via some well-documented user/kernel interface that is both documented and also available to _all_ applications. In fact, I do not have _anything_ specific that I want to do to the video hardware _today_. I do however worry about the things that I may want to do in the future, and about how I will find out how to acomplish those things. And also, as I mentioned (above) I think it is Important to stick to first principals and to provide a comprehensive _abstraction_ of the actual hard- ware at the user/kernel interface. (This could be important if, for example, someone somday wants to write a new OS and wants to have it provide full FreeBSD emulation, just as FreeBSD now provides Linux emulation.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3401.941160455>