Date: Wed, 20 Feb 2008 09:25:28 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: Oliver Fromme <olli@lurza.secnetix.de> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: /boot/loader graphics support & extensibility Message-ID: <E8C3A1D8-C448-45FF-B532-D1394A55A876@mac.com> In-Reply-To: <200802201257.m1KCvibX085854@lurza.secnetix.de> References: <200802201257.m1KCvibX085854@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 20, 2008, at 4:57 AM, Oliver Fromme wrote:
> 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.
Yes, agreed. Maybe we should just call them serial consoles,
knowing that they don't have to be.
>>> 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?
It means that they can be treated the same: there's no
VGA BIOS that can be used. There may be support in the
firmware for setting graphics mode, but once you have
the abstraction in place, then that just falls into
place.
> 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?
Yes. They have VGA compatible hardware. They either have
the Intel chipset (Mac Mini) or nVidia (MacBook). Both
start up in VGA compatible mode by default, but which
EFI puts in some non-VGA mode right from the start.
>>> (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?
I haven't looked at the code yet, so I don't know
which graphics functions we're talking about. You
may want to keep in mind that EFI basically defines
a single graphics function: bitblt. If the
graphics functions are variations of bitblt, then
yes, it's very 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?
Why not have the platform set a suitable graphics mode?
In other words: rather than have the end-user code
determine a mode, which they can't do reliably, why
not have the mode be set for the end-user code.
It seems to me that there are 2 ways of thinking about
consoles. One is the traditional way of not assuming
too much and just use the console in a serial fashion
so that it works with dump terminals as well. The other
is the graphical way of thinking which removes any and
all levels of abstraction (other than using BIOS mode
numbers????) and demands that the user can set every
little bit that can be set.
There's an in-between. The loader exists only to load
a kernel. We want it to look nice, but there's no
reason to tweak resolutions so that you can see the
kernel being loader in HD. The platform, which
includes the firmware, knows best which resolutions
look good. This could very well be a non-VGA mode.
The best thing we can do is work with what is given
to us by the firmware or the platform. Then it will
look nice and it will work in cases we don't know
how to set the mode, but we know it's graphical.
> The whole idea of a graphical boot menu is inherently
> unportable. That's why abstracting the hardware is
> somewhat difficult.
It's not unportable, it's just parameterized :-)
I'm not going to suggest that you write for all
platforms and hardware combinations. I hope however
that with some thought you can implement it for
i386 with VGA BIOS in such a way that someone can
later extend the support in some direction, without
having to rewrite the whole thing...
--
Marcel Moolenaar
xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E8C3A1D8-C448-45FF-B532-D1394A55A876>