VGA musings...

VGA musings...

[Lucio]

>From Scott Schwartz:
> Here are some suggested changes to devvga to attempt to support screen
> blanking, in the style of XFree86 3.3.  (Doing this completely right
> requires chipset specific code, and more extensive changes.)  The
> generic vga mechanisms could probably be used via aux/vga, but
> /dev/vgactl is such a nice interface that I couldn't resist using it.
> (Is that the wrong approach?)
>
I would assume the contrary - device/chip specifics in the device driver,
generics in userland code.  Of course, that's also backwards, because
once off setting up of the VGA card should hardly be kernel resident.

I think this says something about different design criteria in hardware
and software.

Maybe a new approach would be to have a "loader" operate as a pre-kernel
and arrange all devices into an architecture independent state?  Of
course, that's the BIOS approach, but not exactly.

I can see a problem with this tack, though, because there will always
be hardware features that can only be accessed if the adaptor is set up
appropriately, highest common denominator syndrome.

As far as VGA goes, I am reminded of the Ontel Amigo, which had a Z80 to
run CP/M and a 6502 with its own, dual-ported RAM (32 K, if memory serves)
for the graphic section.  The idea was to load in video RAM actual program
code, then communicate with this program as chosen by the user.  A graphic
language (X-protocol notwithstanding) has always appealed to me as an
architecture independent approach to communicating with graphic engines.

Of course, Plan 9's text-driven devices are very close to this, although
not quite in a position to interpret a full programming notation.  Adding
a programming layer (a shell?) might in fact suffice, as long as the
underlying commands set is sufficiently powerful.
--
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.