From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 12:57:47 2008 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D5D916A404 for ; Wed, 20 Feb 2008 12:57:47 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id C04BC13C44B for ; Wed, 20 Feb 2008 12:57:46 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1KCviUj085855; Wed, 20 Feb 2008 13:57:45 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1KCvibX085854; Wed, 20 Feb 2008 13:57:44 +0100 (CET) (envelope-from olli) Date: Wed, 20 Feb 2008 13:57:44 +0100 (CET) Message-Id: <200802201257.m1KCvibX085854@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, xcllnt@mac.com In-Reply-To: X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 20 Feb 2008 13:57:45 +0100 (CET) X-Mailman-Approved-At: Wed, 20 Feb 2008 13:11:00 +0000 Cc: Subject: Re: /boot/loader graphics support & extensibility 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: Wed, 20 Feb 2008 12:57:47 -0000 Marcel Moolenaar wrote: > Oliver Fromme wrote: > > > It will not replace the current text menu ("beastie.4th"), > > so you can still use it on your Hercules monochrome or CGA > > machine or with serial console, of course. > > We can probably forget about those configurations. OK, maybe not Hercules or CGA cards, but there are certainly situations where a pure text-based menu is required. > > This is a list of things that comes to mind: > > > > (a) Support for i386/amd64 machines that have VGA hard- > > ware but no VGA BIOS (this is different from the > > system BIOS!). Is there a sufficiently large number > > of such systems that it would be desirable to support > > them? > > Yes, see (b). > > > (b) Support for non-i386/amd64 machines that have VGA > > hardware (ia64, powerpc, ...). > > Yes, see (a). I understand the "yes" part, but I do not understand the "see (a)/(b)" part. :-) What does the recursive reference mean? Just out of curiosity, what would be examples of machines that fall in categry (a)? I think maybe x86-based Macs which don't have a BIOS (and probably no VGA BIOS either), but do they really have VGA-compatible hardware? I'm sorry if that's a stupid question, I've never touched an x86 Mac. > > (c) Support for non-VGA graphics hardware (any platform). > > Think sparc64, here. Abstraction of the hardware should be > enough to make it easy for someone with the specs in hand > and the hardware on the shelf. Yes, I agree. I played with CG6 graphics hardware on 32bit sparc machines myself, about 12 years ago. > > Currently my code is simply compiled conditionally, > > depending on make(1) variables (${MACHINE_ARCH}), so it > > is only included for i386 and amd64. > > > > So, basically, if multiple platforms are supported, the > > source file with the graphics support functions would be > > selected based on ${MACHINE_ARCH}. > > > > Would that be sufficient? I have looked at the archsw, > > but I'm not sure if that gives any additional benefit > > in this case. For a different architecture you ahve to > > compile a different binary anyway, so it seems that it > > is sufficient to make the decision at build time, so the > > additional indirection of the archsw isn't required. > > Please someone correct me if I'm wrong. > > True; the archsw is mostly bogus. We can simply call, say, > arch_copyin(), rather than do it indirectly with > archsw.arch_copyin(). So, there's no need to go through > archsw per-se. The point is mostly one of abstracting the > hardware using the right "call-back" functions. OK. I will have to implement a certain level of abstraction for the graphics functions anyway: The current code (in perforce) supports 4bit planar modes only, but it should be possible to support other modes (e.g. 8bit linear). Of course, the FICL interface should not need to care about it. Therefore all graphics functions must go through a "switch" that executes the right function depending on the graphics mode. Dos that sound reasonable? However, I'm not sure how to go about the initialization of the graphics mode. Currently I have a FICL word called "vmode" that takes an integer parameter from the stack which is the VGA mode number. That is, this line: 18 vmode will switch to VGA mode 0x12 (that's 640 x 480 @ 4bit) by calling the appropriate VGA BIOS function. This is all in the ficl/i386/* subdirectory, so it's compiled only for the i386 boot loader. If someone else writes support for some sparc64 graphics hardware, that code would be located in ficl/sparc64/* so it would be compiled in when building the loader for sparc64. However, on sparc64 there is no such thing as VGA mode 0x12, so the vmode instruction has to have a different interface. I'm not really sure what to do here. One possible approach would be to let "vmode" take three parameters: x resolution, y resoluton, depth. So you could type: 640 480 4 vmode In that case every graphics driver needs to have a table that maps resolution and depth to mode numbers. OK. But what if the desired mode isn't supported at all? For example, the sparc CG6 does not support the above mode at all. Should the vmode instructon fail in such a case? The above means: When you port a certain graphical boot menu to a different architecture, you will have to change the Forth code. You will probably also have to change other things, such as the font and the background image. The whole idea of a graphical boot menu is inherently unportable. That's why abstracting the hardware is somewhat difficult. > > Comments appreciated. > > I love the screenshot. I'm going to use the background in > my VTY driver as well :-) It's based on the artwork from Anton Gural, so credit should go to him. In fact I simply took the wallpaper from www.freebsd.org/logo.html (the last one at the bottom of that page), modified it a little bit and adapted it to the size and bit depth required for the 640x480 standard VGA mode. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "anyone new to programming should be kept as far from C++ as possible; actually showing the stuff should be considered a criminal offence" -- Jacek Generowicz