Update of /cvsroot/linuxconsole/ruby/web/htdocs/paper
In directory usw-pr-cvs1:/tmp/cvs-serv25371
Modified Files:
fbdev.html serial.html
Log Message:
Paper updates. Adding info on new fbdev api. Needs alot of work.
Index: fbdev.html
===================================================================
RCS file: /cvsroot/linuxconsole/ruby/web/htdocs/paper/fbdev.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- fbdev.html 15 Apr 2002 23:34:10 -0000 1.2
+++ fbdev.html 16 Apr 2002 19:45:13 -0000 1.3
@@ -57,11 +57,47 @@
</H2>
<P>
+ If you look at the current framebuffer console layer you will see alot
+of replicated code and and huge of code handling tty/console functionality.
-The two major goals of the redesign was to remove all the console code out of the low
-level framebuffer drivers.
+</P>
+
+<P>
+ The primary goal is to remove the console code from fbdev and place it
+into fbcon.c. This reduces the code and makes writing a new fbdev driver
+easy since the author doesn't need to worry about console internals. It
+also allows the ability to run fbdev without a console/tty system on top
+of it.
+</P>
+
+<P>
+ First the roles of struct fb_info and struct display have changed. Struct
+display will go away. The way the the new framebuffer console code will
+work is that it will act to translate data about the tty/console in
+struct vc_data to data in a device independent way in struct fb_info. Then
+various functions in struct fb_ops will be called to store the device
+dependent state in the par field in struct fb_info and to change the
+hardware to that state. This allows a very clean seperation of the fbdev
+layer from the console layer. It also allows one to use fbdev on its own
+which is a bounus for embedded devices. The reason this approach works is
+for each framebuffer device when used as a tty/console device is allocated
+a set of virtual terminals to it. Only one virtual terminal can be active
+per framebuffer device. We already have all the data we need in struct
+vc_data so why store a bunch of colormaps and other fbdev specific data
+per virtual terminal.
+</P>
<P>
+ As you can see doing this makes the con parameter pretty much useless
+for struct fb_ops functions, as it should be. Also having struct
+fb_var_screeninfo and other data in fb_info pretty much eliminates the
+need for get_fix and get_var. Once all drivers use the fix, var, and cmap
+fbcon can be written around these fields. This will also eliminate the
+need to regenerate struct fb_var_screeninfo, struct fb_fix_screeninfo
+struct fb_cmap every time get_var, get_fix, get_cmap functions are called
+as many drivers do now.
+
+</P>
<BR><HR>
<ADDRESS>
Index: serial.html
===================================================================
RCS file: /cvsroot/linuxconsole/ruby/web/htdocs/paper/serial.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- serial.html 12 Apr 2002 19:11:16 -0000 1.1
+++ serial.html 16 Apr 2002 19:45:14 -0000 1.2
@@ -53,7 +53,7 @@
<!--End of Navigation Panel-->
<H2><A NAME="SECTION00031000000000000000">
-Restructing the framebuffer layer</A>
+New Serial Layer</A>
</H2>
<P>
|
