nanogui: Thread: frame buffer part 423423512435

Hello All,

I been thinking a bit and can't realy figure out what would be
the best place to split between "kernel" and "user" or ("bsp" and
"application" if you like those terms better) 

1) framebuffer (fake or virtual or real) that only offers very minimal
   functionality , address pointer for framebuffer access and init (mode
switch
   function)

   + this makes the kernel part very small and "easy" which is good.
   - the number of different pixel formats is large and the framebuffer
must
     offer the graphics libary info about the organisation of the
buffer.
   - hardware acceleration isn't realy posible without extra interfaces

2) device driver like table with functions like draw pixel, switch mode
, etc.
   + very fixed and defined interface
   + the line drawwwing for example could be hardware accelerated 
   + the graphics libray can concentrate on graphics and not on hardware
   + BSP providers can offer a easy interface to graphics hardware.
   - the number of possible hardware accelerated functions can grow
rather large.


I think point 2 is the more interesting one , cause it hides more of the
hardware behind
a wel difent interface. Things like line drawing can be optimized in
assembly which
make them CPU dependend which is probebly something you cant to keep out
of yer graphics
libraries. It also makes it easier to add "strange" hardware which
doesn't directly
have a memory mapped framebuffer, or useses some window due to lack of
address space
or cost reduction in hardware. 

Maybe we should make a list with operations that we need on a graphics
display ?
I will see what i can do with PK's VGA interface.

- Erwin

: 1) framebuffer (fake or virtual or real) that only offers very minimal
:    functionality , address pointer for framebuffer access and init (mode
: switch
:    function)
:
:    + this makes the kernel part very small and "easy" which is good.

Very very good for embedded and small systems.


:    - the number of different pixel formats is large and the framebuffer
: must
:      offer the graphics libary info about the organisation of the
: buffer.

No big deal.  Getting height, width, linesize, bpp and address are basically
enough.  I've got code for drawing on all sorts of different pixel formats
already.


:    - hardware acceleration isn't realy posible without extra interfaces

No problem for rev 1.  Microwindows doesn't do hw accell either
at this point, and if it the designer needs it, it doesn't yet have to go into
the kernel.  There are trillions of issues with hw accelleration.  Take
a look at the DirectX driver API for good details ;-)



:
: 2) device driver like table with functions like draw pixel, switch mode
: , etc.
:    + very fixed and defined interface
Actually, no.  We're not yet at the point of defining a good, stable
interface.  And it'll end up being quite large if we had to.  Every new
acceleratable feature in Microwindows, for instance, might have to
add another entry point.



:    + the line drawwwing for example could be hardware accelerated
This won't buy much now.  Fast byte move CPU instructions will work
just fine.



:    + the graphics libray can concentrate on graphics and not on hardware
Yes

:    + BSP providers can offer a easy interface to graphics hardware.
Well, in rev 1, thats what the fb is for.

:    - the number of possible hardware accelerated functions can grow
: rather large.
:
Very.

:
: I think point 2 is the more interesting one , cause it hides more of the
: hardware behind
: a wel difent interface. Things like line drawing can be optimized in
: assembly which
: make them CPU dependend which is probebly something you cant to keep out
: of yer graphics
: libraries.

At this point, noone wants to write asm routines for all the graphics stuff,
for each different chip.  Way too much work for rev 1.  The whole point of
Microwindows is to bring a small, easy, portable graphics system to
more developers WITHOUT having to write more low level code.




 It also makes it easier to add "strange" hardware which
: doesn't directly
: have a memory mapped framebuffer, or useses some window due to lack of
: address space
: or cost reduction in hardware.

Strange hardware that can't map a framebuffer shouldn't necessarily be
the first consideration.  Especially when we don't have the easier chips
working.

I strongly think that your Option #1 is the way to go.  Especially to keep
things simple.  Keeping things very simple will allow for more programmers
to contribute to this project, which will be needed to get all the chipsets
done.


:
: Maybe we should make a list with operations that we need on a graphics
: display ?

See the SCREENDEVICE struct in Microwindows' device.h for a start.
But I don't think the kernel should get involved with this.  That's what
Microwindows is for.

Greg