nanogui: frame buffer part 423423512435
Subject:
frame buffer part 423423512435
From:
Erwin Rol ####@####.####
Date:
5 Feb 2000 03:09:53 -0000
Message-Id: <389BA219.23BB54A6@muffin.org>
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
