Date: Wed, 20 Feb 2008 13:57:44 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-hackers@FreeBSD.ORG, xcllnt@mac.com Subject: Re: /boot/loader graphics support & extensibility Message-ID: <200802201257.m1KCvibX085854@lurza.secnetix.de> In-Reply-To: <D31D9C9E-3473-4AC1-8C1D-94C0FE68BDC8@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802201257.m1KCvibX085854>