Re: SVGA kernel chipset drivers. (yes, again)

Matty (matt@blitzen.canberra.edu.au)
Tue, 11 Jun 1996 17:17:12 +1000 (EST)


On Mon, 3 Jun 1996, Theodore Y. Ts'o wrote:

> Date: Mon, 3 Jun 1996 20:36:14 +1000 (EST)
> From: Matty <matt@blitzen.canberra.edu.au>
>
> Back onto the X point, the kernel routines are the low-level stuff
> specific to the graphics cards. Make them VESA compliant so that as many
> cards as possible are supported, and the standard kernel API can be called
> by X to do whatever.....
>
> This is another example of what happens when amatuers post to
> linux-kernel.... :-)

:) Well I joined to see what I could learn from the "experts" - so I
don't mind being shot down in flames for making stupid suggestions :)

> If you make the routines VESA complaint, then they can't take advantage
> of any of the card-specific accelerated features. This means that
> performance of the X server will go *down* as a result.

That's right, but what I'm thinking of, in more detail, is that VESA
support should be easier to write, hence it can get into the kernel
faster. Also, it will support the most cards, initially. Not
everyone has the same video card! Once this is going, interested ppl can
then write the card-specific stuff that takes advantage of accellerated
features of a particular chipset.
I guess one way of doing this is writing the VESA functions, but the
actual routines called are compiler macros, so we have (for example)

#define __what_kind_of_idiotic_mode_am_i_in_now() __VESA_get_video_mode()

And when the specific stuff goes in, we #ifdef the correct routine

#ifdef CONFIG_VIDEO_VESA
#define __what_kind_of_idiotic_mode_am_i_in_now() __VESA_get_video_mode()
#define __draw_a_rectangle(l,r,h,w) __VESA_rect(l,r,h,w)
...
...
#endif
#ifdef CONFIG_VIDEO_S3
#define __what_kind_of_idiotic_mode_am_i_in_now() __S3_get_video_mode()
/*
* okay, so get_video_mode() is a dumb example since it should be a
* generic call for all cards, right?
*/
#define __draw_a_rectangle(l,r,h,w) __S3_fast_rect(l,r,h,w)
...
...
#endif

and of course the user-level program calls the function
__draw_a_rectangle() and the kernel does its stuff, using the accellerated
function if it's compiled in, or the VESA function if not.
More #ifdef's can determine which functions to include into the actual
driver loaded into the kernel, so (for instance) it isn't bloated with
VESA routines when it's going to use accellerated ones anyway.
There's probably a better way of doing it, but this isn't meant as a "this
is how it should be done" thing anyway - just a thought-provoker.

Now programmers don't need to write that kind of stuff into their programs
anymore - they just call the appropriate routine that's built into the
kernel. Graphics programs no longer need to be setuid-0 since the kernel
does all the privileged stuff. Games programmers now have the support
they need to be able to write a graphics engine for their game and be
secure in the knowledge that the same source is going to work on all video
cards and will automagically use accellerated features (assuming the
end-user has enabled that support for their card), the X people can lose
card-specific servers - just have the one server that calls the kernel for
the low-level stuff and does the "higher" generic routines itself.

I hope I'm making sense here :)

-- Matt

,---------------------------.\|/ ____ \|/ /\ ___________
| -* Mostly Harmless ! *- | @~/ ,. \~@ / \/\ ,'Don't Panic|
`--------------------------(_/_( \__/ )_\ __ /`/ / \ `.___________|
matt@blitzen.canberra.edu.au----\__U_/-----' `--------------------||-----