From owner-freebsd-bugs Thu Oct 28 18:28: 2 1999 Delivered-To: freebsd-bugs@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id 6466A14BCF for ; Thu, 28 Oct 1999 18:27:46 -0700 (PDT) (envelope-from rfg@monkeys.com) Received: from i180.value.net (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id SAA03403; Thu, 28 Oct 1999 18:27:35 -0700 (PDT) To: Kazutaka YOKOTA Cc: freebsd-bugs@freebsd.org Subject: Re: kern/14566: Non-kernel programs have little/no control over VGA/VESA devices In-reply-to: Your message of Fri, 29 Oct 1999 09:00:14 +0900. <199910290000.JAA06014@zodiac.mech.utsunomiya-u.ac.jp> From: "Ronald F. Guilmette" Date: Thu, 28 Oct 1999 18:27:35 -0700 Message-ID: <3401.941160455@i180.value.net> Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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