/boot/loader graphics support & extensibility

Thu Feb 21 07:28:44 UTC 2008

On Feb 20, 2008, at 3:44 PM, Marcel Moolenaar wrote:

>> That would be possible.  But then there will be other
>> problems.  For example, lets say that the i386 loader
>> decides to use 640x480 @4bit, and the sparc64 loader
>> decides that 1152x900 @8bit is "best".
>>
>> The Forth code clearly needs a way to query the resolution
>> and bit depth that was set, so it can chose an appropriate
>> background image.  It might also have to chose a different
>> font.
>
> Yes, that's generally the difficulty with graphics.

Consider other potential issues.  I use a widescreen monitor that does 
1440x900, which isn't supported by vga or vesa, so if I wanted an image 
that was actually full screen and "pixel perfect" I'd be out of luck.  
But at the same time, I use amd64 and I'm stuck with 80x25 for the 
console.

But if you can figure some of the tricky stuff out, at least it could 
be made to not look stretched like the Ubuntu load screen.

>> So the bottom line is that the Forth code cannot easily
>> be abstracted from the hardware anyway.
>
> Well, it cannot be abstracted from the graphics settings,
> but it is abstracted from the hardware.
>
>> There's also a problem when VESA support is added:  It's
>> not possible to reliable detect what resolutions the
>> attached monitor supports, so by default we must use
>> 640x480 anyway, even if VESA support is present and the
>> hardware can do 1600x1200 or whatever.  Using a higher-
>> resolution mode is a decision that needs to be made by
>> the admin, not by the loader, so there must be a way
>> for the Forth code to request a specific resolution.
>
> This does not have to be done in Forth. If in Forth you
> simply say "Switch to graphics" and the platform code
> looks up an environment variable for the actual mode,
> then the user is still control of the resolution. In
> fact, this is much more user friendly than having the
> user edit Forth code, which he/she may not...

Relying on people to edit the code means being responsible for fixing 
their breaks, which they will of course break.  No warranty doesn't 
mean no responsibility.

>>> 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 will be users who want exactly that, i.e. be able
>> to set every little bit that can be set.  I already got
>> such requests in private mail.
>
> While I understand the request, it should not be forgotten
> that it's easy to end up with nothing if you allow the user
> control over everything. On top of that, we can't use any
> code in the loader from the kernel, so whatever support we
> add, we need to add to the kernel too. At least, I think
> it's lame to support fancy graphics in the loader and then
> not support at least the same in the kernel. If you raise
> the bar for the loader, you also have to raise it for the
> kernel. How else would the kernel be able to use the console?
>
> So, the question is: how important is it for the user to
> be able to tweak it all. Is it merely people going nuts
> over it (like a toddler going nuts over candy) than we
> should simply forget about it (and tell the user to grow
> up :-). If there's an actual reason for it (say: to support
> HD TVs) then it's something that we could keep in mind if
> we think it's the future (I have my Mac Mini hooked up to
> my TV, so it's real for me).

For the desktop OS aspect of FreeBSD I think it'd be good.  MacOS X 
hides the console unless you go into single user mode or boot 
verbosely, which gives a more user friendly appearance.  And if you 
have any meaningless errors, the user probably won't see them to 
complain about them.  No one would care about this idea for their rack 
server, but people would want it for their desktop.

>> Of course, it would be pretty easy to implement both.
>> So you have one function that simply set the mode that
>> the driver thinks is best (that would be a 640x480 mode
>> in the i386 case).  And a second function that takes
>> resolution and depth as parameters, in order to switch
>> to a specific mode.  There could be a special depth
>> value (0 or -1) indicating "I don't care, just give
>> me whatever you can at this resolution".
>
> Yes. If common code doesn't care about the setting, then
> it's easy enough to allow the user to pick the setting
> of choice...
>
>>> 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.
>>
>> I bet there will be people who disagree with the firmware
>> about which resolution looks good.
>
> True. But in that case you want to change the setting in
> the firmware, not in the loader. If you want to depend on
> the firmware/BIOS for mode setting then you also have to
> depend on the Firmware/BIOS to allow the user to select
> a setting of choice. Here too the loader then pretty much
> as to work with whatever it gets thrown at it.
>
>>> 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.
>>
>> I agree that the Forth code should not need to know how to
>> set a mode.  I will change the current interface in my code
>> so it doesn't use VGA mode numbers.
>>
>> My goal is that the Forth code should not have to care
>> about the graphics hardware at all, as long as the
>> underlying driver supports a resolution that the Forth
>> code is prepared to deal with.
>
> Agreed. Even if that's standard VGA for now...
>
>> It's not feasible to define a hardware-specific setpixel
>> function and let all other functions use it.  That would
>> make all functions slower.  A _lot_ slower.  Orders of
>> magnitude slower.  In VGA planar modes, you have to
>> select each of the four bitplanes, one after another
>> (using inb + mask + outb to the ISA registers), in order
>> to set a single pixel.  Doing that for every single pixel
>> in a character string or PCX image would be prohibitively
>> inefficient.  These functions need to deal with the bits
>> directly, and only switch planes if necessary.
>
> That's why there's bitblt. See the URL above...
>
> -- 
> Marcel Moolenaar
> xcllnt at mac.com
>
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to 
> "freebsd-hackers-unsubscribe at freebsd.org"
>