From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 6 15:49:23 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B9811065674 for ; Tue, 6 Mar 2012 15:49:23 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 8023A8FC08 for ; Tue, 6 Mar 2012 15:49:23 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta07.emeryville.ca.mail.comcast.net with comcast id iFVT1i0080lTkoCA7FpHWv; Tue, 06 Mar 2012 15:49:17 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta04.emeryville.ca.mail.comcast.net with comcast id iFpG1i0064NgCEG8QFpHup; Tue, 06 Mar 2012 15:49:17 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q26FnFrp015051; Tue, 6 Mar 2012 08:49:15 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Brandon Falk In-Reply-To: <4F562C38.4010203@brandonfa.lk> References: <4F55A0EA.8000300@gmail.com> <4f5635d4.5Qp6ViEgiFLUuPKI%perryh@pluto.rain.com> <4F562C38.4010203@brandonfa.lk> Content-Type: text/plain; charset="us-ascii" Date: Tue, 06 Mar 2012 08:49:14 -0700 Message-ID: <1331048954.32194.5.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Graphical Terminal Environment X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 15:49:23 -0000 On Tue, 2012-03-06 at 10:24 -0500, Brandon Falk wrote: > On 3/6/2012 11:05 AM, perryh@pluto.rain.com wrote: > > Brandon Falk wrote: > > > >> I havent tried tmux yet, but on my system im only able to get > >> 80x40 with vidcontrol on one monitor. But with xterm in xorg > >> i can get 319x89 per monitor ... > > > > To get higher resolution than what vidcontrol provides, you'll most > > likely need to run the display in graphic mode (which is what X11 > > does) rather than in text mode. That means that you will need to > > either use, or reinvent, the lowest levels of X (display driver, > > window mapping) and at least part of the xterm/rxvt application > > (terminal emulation, font rasterizing, perhaps scrolling). You > > could, however, eliminate the X practice of using the network to > > connect the terminal emulator to the display; this would give you > > an architecture resembling SunView (and its predecessor, SunTools). > > > > I _think_ SunTools/SunView were proprietary, although it's possible > > that Sun released the source code at some point. You could try > > doing some research with Google and/or the Internet Archive. > > That's pretty much my plan. To write some lower level drivers to put the system > in a graphics mode. I have 4 monitors and there is no other way to get multiple > monitors without a GPU specific driver (at least from my VGA OSDev experience). > My goal will be to make a driver that will be able to be runnable by any other > driver easily. Instead of having to use Xorg, just calls to the video driver to > set the mode to graphics, then some primitive functions to draw lines and dots. > > I don't see why Xorg should dominate the drivers completely, I really wish it > was a matter of having an open, well documented, easy to use API that you can > just give direct commands to. > > >From my understanding, this is the current model: > > [ Apps ] > | > v > [ Xorg ] > | > v > [ Driver ] > | > v > [ GPU ] > > I think it should be the following: > > [ Apps ] > | > v > [ Xorg ] [ Apps ] > | | > v v > [ Driver ] > | > v > [ GPU ] > > Does this make sense to anyone else? I really want to get this idea across > because I think it would be really beneficial. > > -Brandon With that model and your statement that the driver should support only primitive functions to draw lines and dots, that leaves the non-trivial problem of font rendering to the app. Given your original goal, font rendering is pretty much the bulk of what you want to do, is the app layer the right place for it? -- Ian