1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
|
<!--startcut ==========================================================-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<title>Kernel 2.2's Frame-buffer LG #36</title>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#A000A0"
ALINK="#FF0000">
<!--endcut ============================================================-->
<H4>
"Linux Gazette...<I>making Linux just a little more fun!</I>"
</H4>
<P> <HR> <P>
<!--===================================================================-->
<center>
<H1><font color="maroon">Kernel 2.2's Frame-buffer Option</font></H1>
<h4>By <a href="mailto: layers@marktwain.net">Larry Ayers</a></h4>
</center>
<P> <HR> <P>
<center><font color="maroon"><h3>Introduction</h3></font></center>
<p>The long-awaited new stable version 2.2 of the Linux kernel is on the verge
of release as the new year begins; a great variety of new features and drivers
will be included. One of the new features is the option to use a new device
type for the virtual consoles, the frame buffer device (<kbd>/dev/fb[0-7].</kbd>)
This new device type isn't really essential for the many Linux users running
Intel machines, but those people using Alpha, Sparc, PPC, or any of the other
platforms supported by Linux should benefit, as the idea behind the
frame buffer console is to provide a hardware-independent console device.
<p>Geert Uytterhoeven, a Belgian programmer and one of the primary frame
buffer developers, wrote a succinct introduction to one of
the frame buffer documents included with the kernel source:<br>
<blockquote>
The frame buffer device provides an abstraction for the graphics hardware. It
represents the frame buffer of some video hardware and allows application
software to access the graphics hardware through a well-defined interface, so
the software doesn't need to know anything about the low-level (hardware
register) stuff.
</blockquote>
<p>Users of Intel machines already have methods available to vary the
size of the text console screen, such as the <kbd>video=ask</kbd> Lilo
parameter and the SVGATextMode utility. I've used SVGATextMode for quite some
time to set the console text to a 116x34 resolution. It works fine, but while
configuring recent 2.2 beta kernels with menuconfig I couldn't help but be
intrigued by the choices offered in the <kbd>Console Drivers</kbd>
sub-screen. My video card these days is a Matrox Mystique, and when I saw a
new frame buffer driver for Matrox cards and another option for Mystique
support I just had to give it a try.
<center><font color="maroon"><h3>Installation Tips</h3></font></center>
<p>The first time I tried a kernel with Matrox frame buffer support I could
see that the card was detected (as the boot messages scrolled by) and the
penguin logo's appearance at the upper right corner of the screen seemed
to indicate that at least part of this compiled-in feature was working, but
the console was the same old 80x25 default. Back to the documentation, where
I learned that a utility called <i>fbset</i> would be helpful. This small
program (written by Geert Uytterhoeven and Roman Zippel) is used to change or
query the current frame buffer mode. Even more important, the installation of
<i>fbset</i> creates the special device files <kbd>/dev/fb[0-7]</kbd> which
are needed for frame buffer functionality. The <i>fbset</i> archive can be
found at this FTP
<a href="ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/680x0/">site</a>.
<p>Another document found in the <kbd>fb</kbd> subdirectory of the kernel
source's <kbd>Documentation</kbd> directory is called <kbd>matroxfb.txt</kbd>.
Written by Petr Vandrovec, the Czech developer responsible for the Matrox
frame buffer drivers, this document is a great help in setting up workable
frame buffer modes. Another, more generic document called
<kbd>vesafb.txt</kbd> can be consulted when setting up modes for other
VESA-2.0 compliant video cards.
<p>There are two ways to tell the kernel which frame buffer mode to use.
While experimenting, setting the mode specification at the Lilo prompt is a
quick way to try a mode out. Let's say that your main dependable kernel is
the first one in the <kbd>/etc/lilo.conf</kbd> file, and the frame buffer
kernel is the second and is named bzImage-2.2. Your computer boots, the LILO
prompt appears, and you press the shift key. Here is an example of a mode
being set:<br>
<p><kbd>LILO bzImage-2.2 video=matrox:vesa:0x188</kbd>
<p>If the mode is acceptable, the console screen will switch to the new mode
(in this case, 960x720) soon after the boot messages begin to scroll by. The
relevant boot messages will look something like this:<br>
<p><pre><kbd>
matroxfb: Matrox Mystique (PCI) detected
matroxfb: 960x720x8bpp (virtual: 960x4364)
matroxfb: framebuffer at 0xE0000000, mapped to 0xc4807000, size 4194304
Console: switching to colour frame buffer device 120x45
fb0: MATROX VGA frame buffer device
</kbd></pre>
<p>If you like the mode, a variation of the above Lilo command can be
inserted directly into the <kbd>/etc/lilo.conf</kbd> file; the line should
look something like this:<br>
<p><kbd>append="video=matrox:vesa:392"</kbd>
<p>The quotes are essential, and notice that the hex number 0x188 has been
converted to its decimal equivalent 392, since Lilo can't understand hex
numbers in the <kbd>lilo.conf</kbd> file.
<p>Once the frame buffer kernel is booted the <i>fbset</i> utility can be used
to switch to other modes. Mode specifications can be derived from X modes,
but not wanting to spend hours fooling around with this I took the easy way
out. Before I edited the <kbd>lilo.conf</kbd> file so that the mode would be
set automatically when booting, I tried several different hex numbers at the
Lilo prompt. After booting each one I ran <i>fbset</i> without any
arguments. When run this way <i>fbset</i> outputs to the screen the current
mode specs in a format usable in the (initially nonexistent) config file
<kbd>/etc/fb.modes</kbd>. Here's a sample of the output:<br>
<p><pre><kbd>
kbdmode "name"
# D: 56.542 MHz, H: 45.598 kHz, V: 59.998 Hz
geometry 960 720 960 4364 8
timings 17686 144 24 28 8 112 4
endmode
</kbd></pre>
<p>Several of these mode specs can be pasted into a new
<kbd>/etc/fb.modes</kbd> file, substituting different mnemonic names for the
"name" in the pasted output. One useful mode to include is a basic,
non-color text mode, either by trying one of the text modes described in the
documentation or simply by running <kbd>fbset -depth 0</kbd>. SVGAlib console
graphics programs won't run properly in frame buffer consoles with higher
color-depths. Once a <kbd>fb.modes</kbd> file has been created the frame
buffer mode can be changed by running the command <kbd>fbset name</kbd>, where
"name" is one of the mode names in the file.
<center><font color="maroon"><h3>Frame Buffers and X</h3></font></center>
<p>Naturally, the big question many readers will have is "Will X Windows
run when started from a frame buffer console?". The answer is "It
depends.". Some combinations of X servers and video cards are known to
have problems, especially when switching back and forth from X to a virtual
console. This can be a problem with SVGATextMode as well. The XFree86 3.3.3
SVGA server I've been using with my Matrox card has worked well with the
frame-buffer consoles. Your mileage may vary.
<p>There <em>is</em> a special server available in source form; it's called
XF68_FBDev and it's included in the XFree86 3.2 (and later) sources. Binaries
aren't available, and the server is unaccelerated and would mainly be of interest
to those running Linux on non-standard hardware such as PPC.
<center><font color="maroon"><h3>Conclusion</h3></font></center>
<p>The majority of Linux users probably won't be using the frame buffer kernel
options any time soon. It has advantages with some hardware, but it takes
time to figure out and use effectively, and the benefits are nice for console
users but won't be of much use to those who spend most of their time in X
Windows. I think that the reason it will be a part of the next stable kernel
release is that frame buffer devices aren't Intel-specific, as is much of the
current console code. It's likely that the much-anticipated release of
XFree86 4.0 (possibly this year) will include more frame buffer compatibility
in its server modules, such as seems to exist now in the SVGA server.
<p>
<hr>
<!-- hhmts start -->
Last modified: Sun 3 Jan 1999
<!-- hhmts end -->
<!--===================================================================-->
<P> <hr> <P>
<center><H5>Copyright © 1999, Larry Ayers <BR>
Published in Issue 36 of <i>Linux Gazette</i>, January 1999</H5></center>
<!--===================================================================-->
<P> <hr> <P>
<A HREF="./lg_toc36.html"><IMG ALIGN=BOTTOM SRC="../gx/indexnew.gif"
ALT="[ TABLE OF CONTENTS ]"></A>
<A HREF="../lg_frontpage.html"><IMG ALIGN=BOTTOM SRC="../gx/homenew.gif"
ALT="[ FRONT PAGE ]"></A>
<A HREF="./coleman.html"><IMG SRC="../gx/back2.gif"
ALT=" Back "></A>
<A HREF="./merlino.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
<P> <hr> <P>
<!--startcut ==========================================================-->
</BODY>
</HTML>
<!--endcut ============================================================-->
|
