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
[EMAIL PROTECTED]
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
