Commit cddfa0006e5f65e4485301c6f1b508d310dc0637 - fbset

sync documentation with v5.4-rc6 Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Sudip Mukherjee 4 years ago

70 changed file(s) with 5678 addition(s) and 4558 deletion(s). Raw diff Collapse all Expand all

+307

-0

debian/doc/kernel-doc/api.rst less more

	0	===========================
	1	The Frame Buffer Device API
	2	===========================
	3
	4	Last revised: June 21, 2011
	5
	6
	7	0. Introduction
	8	---------------
	9
	10	This document describes the frame buffer API used by applications to interact
	11	with frame buffer devices. In-kernel APIs between device drivers and the frame
	12	buffer core are not described.
	13
	14	Due to a lack of documentation in the original frame buffer API, drivers
	15	behaviours differ in subtle (and not so subtle) ways. This document describes
	16	the recommended API implementation, but applications should be prepared to
	17	deal with different behaviours.
	18
	19
	20	1. Capabilities
	21	---------------
	22
	23	Device and driver capabilities are reported in the fixed screen information
	24	capabilities field::
	25
	26	struct fb_fix_screeninfo {
	27	...
	28	__u16 capabilities; /* see FB_CAP_* */
	29	...
	30	};
	31
	32	Application should use those capabilities to find out what features they can
	33	expect from the device and driver.
	34
	35	- FB_CAP_FOURCC
	36
	37	The driver supports the four character code (FOURCC) based format setting API.
	38	When supported, formats are configured using a FOURCC instead of manually
	39	specifying color components layout.
	40
	41
	42	2. Types and visuals
	43	--------------------
	44
	45	Pixels are stored in memory in hardware-dependent formats. Applications need
	46	to be aware of the pixel storage format in order to write image data to the
	47	frame buffer memory in the format expected by the hardware.
	48
	49	Formats are described by frame buffer types and visuals. Some visuals require
	50	additional information, which are stored in the variable screen information
	51	bits_per_pixel, grayscale, red, green, blue and transp fields.
	52
	53	Visuals describe how color information is encoded and assembled to create
	54	macropixels. Types describe how macropixels are stored in memory. The following
	55	types and visuals are supported.
	56
	57	- FB_TYPE_PACKED_PIXELS
	58
	59	Macropixels are stored contiguously in a single plane. If the number of bits
	60	per macropixel is not a multiple of 8, whether macropixels are padded to the
	61	next multiple of 8 bits or packed together into bytes depends on the visual.
	62
	63	Padding at end of lines may be present and is then reported through the fixed
	64	screen information line_length field.
	65
	66	- FB_TYPE_PLANES
	67
	68	Macropixels are split across multiple planes. The number of planes is equal to
	69	the number of bits per macropixel, with plane i'th storing i'th bit from all
	70	macropixels.
	71
	72	Planes are located contiguously in memory.
	73
	74	- FB_TYPE_INTERLEAVED_PLANES
	75
	76	Macropixels are split across multiple planes. The number of planes is equal to
	77	the number of bits per macropixel, with plane i'th storing i'th bit from all
	78	macropixels.
	79
	80	Planes are interleaved in memory. The interleave factor, defined as the
	81	distance in bytes between the beginning of two consecutive interleaved blocks
	82	belonging to different planes, is stored in the fixed screen information
	83	type_aux field.
	84
	85	- FB_TYPE_FOURCC
	86
	87	Macropixels are stored in memory as described by the format FOURCC identifier
	88	stored in the variable screen information grayscale field.
	89
	90	- FB_VISUAL_MONO01
	91
	92	Pixels are black or white and stored on a number of bits (typically one)
	93	specified by the variable screen information bpp field.
	94
	95	Black pixels are represented by all bits set to 1 and white pixels by all bits
	96	set to 0. When the number of bits per pixel is smaller than 8, several pixels
	97	are packed together in a byte.
	98
	99	FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only.
	100
	101	- FB_VISUAL_MONO10
	102
	103	Pixels are black or white and stored on a number of bits (typically one)
	104	specified by the variable screen information bpp field.
	105
	106	Black pixels are represented by all bits set to 0 and white pixels by all bits
	107	set to 1. When the number of bits per pixel is smaller than 8, several pixels
	108	are packed together in a byte.
	109
	110	FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only.
	111
	112	- FB_VISUAL_TRUECOLOR
	113
	114	Pixels are broken into red, green and blue components, and each component
	115	indexes a read-only lookup table for the corresponding value. Lookup tables
	116	are device-dependent, and provide linear or non-linear ramps.
	117
	118	Each component is stored in a macropixel according to the variable screen
	119	information red, green, blue and transp fields.
	120
	121	- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR
	122
	123	Pixel values are encoded as indices into a colormap that stores red, green and
	124	blue components. The colormap is read-only for FB_VISUAL_STATIC_PSEUDOCOLOR
	125	and read-write for FB_VISUAL_PSEUDOCOLOR.
	126
	127	Each pixel value is stored in the number of bits reported by the variable
	128	screen information bits_per_pixel field.
	129
	130	- FB_VISUAL_DIRECTCOLOR
	131
	132	Pixels are broken into red, green and blue components, and each component
	133	indexes a programmable lookup table for the corresponding value.
	134
	135	Each component is stored in a macropixel according to the variable screen
	136	information red, green, blue and transp fields.
	137
	138	- FB_VISUAL_FOURCC
	139
	140	Pixels are encoded and interpreted as described by the format FOURCC
	141	identifier stored in the variable screen information grayscale field.
	142
	143
	144	3. Screen information
	145	---------------------
	146
	147	Screen information are queried by applications using the FBIOGET_FSCREENINFO
	148	and FBIOGET_VSCREENINFO ioctls. Those ioctls take a pointer to a
	149	fb_fix_screeninfo and fb_var_screeninfo structure respectively.
	150
	151	struct fb_fix_screeninfo stores device independent unchangeable information
	152	about the frame buffer device and the current format. Those information can't
	153	be directly modified by applications, but can be changed by the driver when an
	154	application modifies the format::
	155
	156	struct fb_fix_screeninfo {
	157	char id[16]; /* identification string eg "TT Builtin" */
	158	unsigned long smem_start; /* Start of frame buffer mem */
	159	/* (physical address) */
	160	__u32 smem_len; /* Length of frame buffer mem */
	161	__u32 type; /* see FB_TYPE_* */
	162	__u32 type_aux; /* Interleave for interleaved Planes */
	163	__u32 visual; /* see FB_VISUAL_* */
	164	__u16 xpanstep; /* zero if no hardware panning */
	165	__u16 ypanstep; /* zero if no hardware panning */
	166	__u16 ywrapstep; /* zero if no hardware ywrap */
	167	__u32 line_length; /* length of a line in bytes */
	168	unsigned long mmio_start; /* Start of Memory Mapped I/O */
	169	/* (physical address) */
	170	__u32 mmio_len; /* Length of Memory Mapped I/O */
	171	__u32 accel; /* Indicate to driver which */
	172	/* specific chip/card we have */
	173	__u16 capabilities; /* see FB_CAP_* */
	174	__u16 reserved[2]; /* Reserved for future compatibility */
	175	};
	176
	177	struct fb_var_screeninfo stores device independent changeable information
	178	about a frame buffer device, its current format and video mode, as well as
	179	other miscellaneous parameters::
	180
	181	struct fb_var_screeninfo {
	182	__u32 xres; /* visible resolution */
	183	__u32 yres;
	184	__u32 xres_virtual; /* virtual resolution */
	185	__u32 yres_virtual;
	186	__u32 xoffset; /* offset from virtual to visible */
	187	__u32 yoffset; /* resolution */
	188
	189	__u32 bits_per_pixel; /* guess what */
	190	__u32 grayscale; /* 0 = color, 1 = grayscale, */
	191	/* >1 = FOURCC */
	192	struct fb_bitfield red; /* bitfield in fb mem if true color, */
	193	struct fb_bitfield green; /* else only length is significant */
	194	struct fb_bitfield blue;
	195	struct fb_bitfield transp; /* transparency */
	196
	197	__u32 nonstd; /* != 0 Non standard pixel format */
	198
	199	__u32 activate; /* see FB_ACTIVATE_* */
	200
	201	__u32 height; /* height of picture in mm */
	202	__u32 width; /* width of picture in mm */
	203
	204	__u32 accel_flags; /* (OBSOLETE) see fb_info.flags */
	205
	206	/* Timing: All values in pixclocks, except pixclock (of course) */
	207	__u32 pixclock; /* pixel clock in ps (pico seconds) */
	208	__u32 left_margin; /* time from sync to picture */
	209	__u32 right_margin; /* time from picture to sync */
	210	__u32 upper_margin; /* time from sync to picture */
	211	__u32 lower_margin;
	212	__u32 hsync_len; /* length of horizontal sync */
	213	__u32 vsync_len; /* length of vertical sync */
	214	__u32 sync; /* see FB_SYNC_* */
	215	__u32 vmode; /* see FB_VMODE_* */
	216	__u32 rotate; /* angle we rotate counter clockwise */
	217	__u32 colorspace; /* colorspace for FOURCC-based modes */
	218	__u32 reserved[4]; /* Reserved for future compatibility */
	219	};
	220
	221	To modify variable information, applications call the FBIOPUT_VSCREENINFO
	222	ioctl with a pointer to a fb_var_screeninfo structure. If the call is
	223	successful, the driver will update the fixed screen information accordingly.
	224
	225	Instead of filling the complete fb_var_screeninfo structure manually,
	226	applications should call the FBIOGET_VSCREENINFO ioctl and modify only the
	227	fields they care about.
	228
	229
	230	4. Format configuration
	231	-----------------------
	232
	233	Frame buffer devices offer two ways to configure the frame buffer format: the
	234	legacy API and the FOURCC-based API.
	235
	236
	237	The legacy API has been the only frame buffer format configuration API for a
	238	long time and is thus widely used by application. It is the recommended API
	239	for applications when using RGB and grayscale formats, as well as legacy
	240	non-standard formats.
	241
	242	To select a format, applications set the fb_var_screeninfo bits_per_pixel field
	243	to the desired frame buffer depth. Values up to 8 will usually map to
	244	monochrome, grayscale or pseudocolor visuals, although this is not required.
	245
	246	- For grayscale formats, applications set the grayscale field to one. The red,
	247	blue, green and transp fields must be set to 0 by applications and ignored by
	248	drivers. Drivers must fill the red, blue and green offsets to 0 and lengths
	249	to the bits_per_pixel value.
	250
	251	- For pseudocolor formats, applications set the grayscale field to zero. The
	252	red, blue, green and transp fields must be set to 0 by applications and
	253	ignored by drivers. Drivers must fill the red, blue and green offsets to 0
	254	and lengths to the bits_per_pixel value.
	255
	256	- For truecolor and directcolor formats, applications set the grayscale field
	257	to zero, and the red, blue, green and transp fields to describe the layout of
	258	color components in memory::
	259
	260	struct fb_bitfield {
	261	__u32 offset; /* beginning of bitfield */
	262	__u32 length; /* length of bitfield */
	263	__u32 msb_right; /* != 0 : Most significant bit is */
	264	/* right */
	265	};
	266
	267	Pixel values are bits_per_pixel wide and are split in non-overlapping red,
	268	green, blue and alpha (transparency) components. Location and size of each
	269	component in the pixel value are described by the fb_bitfield offset and
	270	length fields. Offset are computed from the right.
	271
	272	Pixels are always stored in an integer number of bytes. If the number of
	273	bits per pixel is not a multiple of 8, pixel values are padded to the next
	274	multiple of 8 bits.
	275
	276	Upon successful format configuration, drivers update the fb_fix_screeninfo
	277	type, visual and line_length fields depending on the selected format.
	278
	279
	280	The FOURCC-based API replaces format descriptions by four character codes
	281	(FOURCC). FOURCCs are abstract identifiers that uniquely define a format
	282	without explicitly describing it. This is the only API that supports YUV
	283	formats. Drivers are also encouraged to implement the FOURCC-based API for RGB
	284	and grayscale formats.
	285
	286	Drivers that support the FOURCC-based API report this capability by setting
	287	the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field.
	288
	289	FOURCC definitions are located in the linux/videodev2.h header. However, and
	290	despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to V4L2
	291	and don't require usage of the V4L2 subsystem. FOURCC documentation is
	292	available in Documentation/media/uapi/v4l/pixfmt.rst.
	293
	294	To select a format, applications set the grayscale field to the desired FOURCC.
	295	For YUV formats, they should also select the appropriate colorspace by setting
	296	the colorspace field to one of the colorspaces listed in linux/videodev2.h and
	297	documented in Documentation/media/uapi/v4l/colorspaces.rst.
	298
	299	The red, green, blue and transp fields are not used with the FOURCC-based API.
	300	For forward compatibility reasons applications must zero those fields, and
	301	drivers must ignore them. Values other than 0 may get a meaning in future
	302	extensions.
	303
	304	Upon successful format configuration, drivers update the fb_fix_screeninfo
	305	type, visual and line_length fields depending on the selected format. The type
	306	and visual fields are set to FB_TYPE_FOURCC and FB_VISUAL_FOURCC respectively.

-306

~~debian/doc/kernel-doc/api.txt~~ less more

0		The Frame Buffer Device API
1		---------------------------
2
3		Last revised: June 21, 2011
4
5
6		0. Introduction
7		---------------
8
9		This document describes the frame buffer API used by applications to interact
10		with frame buffer devices. In-kernel APIs between device drivers and the frame
11		buffer core are not described.
12
13		Due to a lack of documentation in the original frame buffer API, drivers
14		behaviours differ in subtle (and not so subtle) ways. This document describes
15		the recommended API implementation, but applications should be prepared to
16		deal with different behaviours.
17
18
19		1. Capabilities
20		---------------
21
22		Device and driver capabilities are reported in the fixed screen information
23		capabilities field.
24
25		struct fb_fix_screeninfo {
26		...
27		__u16 capabilities; /* see FB_CAP_* */
28		...
29		};
30
31		Application should use those capabilities to find out what features they can
32		expect from the device and driver.
33
34		- FB_CAP_FOURCC
35
36		The driver supports the four character code (FOURCC) based format setting API.
37		When supported, formats are configured using a FOURCC instead of manually
38		specifying color components layout.
39
40
41		2. Types and visuals
42		--------------------
43
44		Pixels are stored in memory in hardware-dependent formats. Applications need
45		to be aware of the pixel storage format in order to write image data to the
46		frame buffer memory in the format expected by the hardware.
47
48		Formats are described by frame buffer types and visuals. Some visuals require
49		additional information, which are stored in the variable screen information
50		bits_per_pixel, grayscale, red, green, blue and transp fields.
51
52		Visuals describe how color information is encoded and assembled to create
53		macropixels. Types describe how macropixels are stored in memory. The following
54		types and visuals are supported.
55
56		- FB_TYPE_PACKED_PIXELS
57
58		Macropixels are stored contiguously in a single plane. If the number of bits
59		per macropixel is not a multiple of 8, whether macropixels are padded to the
60		next multiple of 8 bits or packed together into bytes depends on the visual.
61
62		Padding at end of lines may be present and is then reported through the fixed
63		screen information line_length field.
64
65		- FB_TYPE_PLANES
66
67		Macropixels are split across multiple planes. The number of planes is equal to
68		the number of bits per macropixel, with plane i'th storing i'th bit from all
69		macropixels.
70
71		Planes are located contiguously in memory.
72
73		- FB_TYPE_INTERLEAVED_PLANES
74
75		Macropixels are split across multiple planes. The number of planes is equal to
76		the number of bits per macropixel, with plane i'th storing i'th bit from all
77		macropixels.
78
79		Planes are interleaved in memory. The interleave factor, defined as the
80		distance in bytes between the beginning of two consecutive interleaved blocks
81		belonging to different planes, is stored in the fixed screen information
82		type_aux field.
83
84		- FB_TYPE_FOURCC
85
86		Macropixels are stored in memory as described by the format FOURCC identifier
87		stored in the variable screen information grayscale field.
88
89		- FB_VISUAL_MONO01
90
91		Pixels are black or white and stored on a number of bits (typically one)
92		specified by the variable screen information bpp field.
93
94		Black pixels are represented by all bits set to 1 and white pixels by all bits
95		set to 0. When the number of bits per pixel is smaller than 8, several pixels
96		are packed together in a byte.
97
98		FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only.
99
100		- FB_VISUAL_MONO10
101
102		Pixels are black or white and stored on a number of bits (typically one)
103		specified by the variable screen information bpp field.
104
105		Black pixels are represented by all bits set to 0 and white pixels by all bits
106		set to 1. When the number of bits per pixel is smaller than 8, several pixels
107		are packed together in a byte.
108
109		FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only.
110
111		- FB_VISUAL_TRUECOLOR
112
113		Pixels are broken into red, green and blue components, and each component
114		indexes a read-only lookup table for the corresponding value. Lookup tables
115		are device-dependent, and provide linear or non-linear ramps.
116
117		Each component is stored in a macropixel according to the variable screen
118		information red, green, blue and transp fields.
119
120		- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR
121
122		Pixel values are encoded as indices into a colormap that stores red, green and
123		blue components. The colormap is read-only for FB_VISUAL_STATIC_PSEUDOCOLOR
124		and read-write for FB_VISUAL_PSEUDOCOLOR.
125
126		Each pixel value is stored in the number of bits reported by the variable
127		screen information bits_per_pixel field.
128
129		- FB_VISUAL_DIRECTCOLOR
130
131		Pixels are broken into red, green and blue components, and each component
132		indexes a programmable lookup table for the corresponding value.
133
134		Each component is stored in a macropixel according to the variable screen
135		information red, green, blue and transp fields.
136
137		- FB_VISUAL_FOURCC
138
139		Pixels are encoded and interpreted as described by the format FOURCC
140		identifier stored in the variable screen information grayscale field.
141
142
143		3. Screen information
144		---------------------
145
146		Screen information are queried by applications using the FBIOGET_FSCREENINFO
147		and FBIOGET_VSCREENINFO ioctls. Those ioctls take a pointer to a
148		fb_fix_screeninfo and fb_var_screeninfo structure respectively.
149
150		struct fb_fix_screeninfo stores device independent unchangeable information
151		about the frame buffer device and the current format. Those information can't
152		be directly modified by applications, but can be changed by the driver when an
153		application modifies the format.
154
155		struct fb_fix_screeninfo {
156		char id[16]; /* identification string eg "TT Builtin" */
157		unsigned long smem_start; /* Start of frame buffer mem */
158		/* (physical address) */
159		__u32 smem_len; /* Length of frame buffer mem */
160		__u32 type; /* see FB_TYPE_* */
161		__u32 type_aux; /* Interleave for interleaved Planes */
162		__u32 visual; /* see FB_VISUAL_* */
163		__u16 xpanstep; /* zero if no hardware panning */
164		__u16 ypanstep; /* zero if no hardware panning */
165		__u16 ywrapstep; /* zero if no hardware ywrap */
166		__u32 line_length; /* length of a line in bytes */
167		unsigned long mmio_start; /* Start of Memory Mapped I/O */
168		/* (physical address) */
169		__u32 mmio_len; /* Length of Memory Mapped I/O */
170		__u32 accel; /* Indicate to driver which */
171		/* specific chip/card we have */
172		__u16 capabilities; /* see FB_CAP_* */
173		__u16 reserved[2]; /* Reserved for future compatibility */
174		};
175
176		struct fb_var_screeninfo stores device independent changeable information
177		about a frame buffer device, its current format and video mode, as well as
178		other miscellaneous parameters.
179
180		struct fb_var_screeninfo {
181		__u32 xres; /* visible resolution */
182		__u32 yres;
183		__u32 xres_virtual; /* virtual resolution */
184		__u32 yres_virtual;
185		__u32 xoffset; /* offset from virtual to visible */
186		__u32 yoffset; /* resolution */
187
188		__u32 bits_per_pixel; /* guess what */
189		__u32 grayscale; /* 0 = color, 1 = grayscale, */
190		/* >1 = FOURCC */
191		struct fb_bitfield red; /* bitfield in fb mem if true color, */
192		struct fb_bitfield green; /* else only length is significant */
193		struct fb_bitfield blue;
194		struct fb_bitfield transp; /* transparency */
195
196		__u32 nonstd; /* != 0 Non standard pixel format */
197
198		__u32 activate; /* see FB_ACTIVATE_* */
199
200		__u32 height; /* height of picture in mm */
201		__u32 width; /* width of picture in mm */
202
203		__u32 accel_flags; /* (OBSOLETE) see fb_info.flags */
204
205		/* Timing: All values in pixclocks, except pixclock (of course) */
206		__u32 pixclock; /* pixel clock in ps (pico seconds) */
207		__u32 left_margin; /* time from sync to picture */
208		__u32 right_margin; /* time from picture to sync */
209		__u32 upper_margin; /* time from sync to picture */
210		__u32 lower_margin;
211		__u32 hsync_len; /* length of horizontal sync */
212		__u32 vsync_len; /* length of vertical sync */
213		__u32 sync; /* see FB_SYNC_* */
214		__u32 vmode; /* see FB_VMODE_* */
215		__u32 rotate; /* angle we rotate counter clockwise */
216		__u32 colorspace; /* colorspace for FOURCC-based modes */
217		__u32 reserved[4]; /* Reserved for future compatibility */
218		};
219
220		To modify variable information, applications call the FBIOPUT_VSCREENINFO
221		ioctl with a pointer to a fb_var_screeninfo structure. If the call is
222		successful, the driver will update the fixed screen information accordingly.
223
224		Instead of filling the complete fb_var_screeninfo structure manually,
225		applications should call the FBIOGET_VSCREENINFO ioctl and modify only the
226		fields they care about.
227
228
229		4. Format configuration
230		-----------------------
231
232		Frame buffer devices offer two ways to configure the frame buffer format: the
233		legacy API and the FOURCC-based API.
234
235
236		The legacy API has been the only frame buffer format configuration API for a
237		long time and is thus widely used by application. It is the recommended API
238		for applications when using RGB and grayscale formats, as well as legacy
239		non-standard formats.
240
241		To select a format, applications set the fb_var_screeninfo bits_per_pixel field
242		to the desired frame buffer depth. Values up to 8 will usually map to
243		monochrome, grayscale or pseudocolor visuals, although this is not required.
244
245		- For grayscale formats, applications set the grayscale field to one. The red,
246		blue, green and transp fields must be set to 0 by applications and ignored by
247		drivers. Drivers must fill the red, blue and green offsets to 0 and lengths
248		to the bits_per_pixel value.
249
250		- For pseudocolor formats, applications set the grayscale field to zero. The
251		red, blue, green and transp fields must be set to 0 by applications and
252		ignored by drivers. Drivers must fill the red, blue and green offsets to 0
253		and lengths to the bits_per_pixel value.
254
255		- For truecolor and directcolor formats, applications set the grayscale field
256		to zero, and the red, blue, green and transp fields to describe the layout of
257		color components in memory.
258
259		struct fb_bitfield {
260		__u32 offset; /* beginning of bitfield */
261		__u32 length; /* length of bitfield */
262		__u32 msb_right; /* != 0 : Most significant bit is */
263		/* right */
264		};
265
266		Pixel values are bits_per_pixel wide and are split in non-overlapping red,
267		green, blue and alpha (transparency) components. Location and size of each
268		component in the pixel value are described by the fb_bitfield offset and
269		length fields. Offset are computed from the right.
270
271		Pixels are always stored in an integer number of bytes. If the number of
272		bits per pixel is not a multiple of 8, pixel values are padded to the next
273		multiple of 8 bits.
274
275		Upon successful format configuration, drivers update the fb_fix_screeninfo
276		type, visual and line_length fields depending on the selected format.
277
278
279		The FOURCC-based API replaces format descriptions by four character codes
280		(FOURCC). FOURCCs are abstract identifiers that uniquely define a format
281		without explicitly describing it. This is the only API that supports YUV
282		formats. Drivers are also encouraged to implement the FOURCC-based API for RGB
283		and grayscale formats.
284
285		Drivers that support the FOURCC-based API report this capability by setting
286		the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field.
287
288		FOURCC definitions are located in the linux/videodev2.h header. However, and
289		despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to V4L2
290		and don't require usage of the V4L2 subsystem. FOURCC documentation is
291		available in Documentation/DocBook/v4l/pixfmt.xml.
292
293		To select a format, applications set the grayscale field to the desired FOURCC.
294		For YUV formats, they should also select the appropriate colorspace by setting
295		the colorspace field to one of the colorspaces listed in linux/videodev2.h and
296		documented in Documentation/DocBook/v4l/colorspaces.xml.
297
298		The red, green, blue and transp fields are not used with the FOURCC-based API.
299		For forward compatibility reasons applications must zero those fields, and
300		drivers must ignore them. Values other than 0 may get a meaning in future
301		extensions.
302
303		Upon successful format configuration, drivers update the fb_fix_screeninfo
304		type, visual and line_length fields depending on the selected format. The type
305		and visual fields are set to FB_TYPE_FOURCC and FB_VISUAL_FOURCC respectively.

+68

-0

debian/doc/kernel-doc/arkfb.rst less more

	0	========================================
	1	arkfb - fbdev driver for ARK Logic chips
	2	========================================
	3
	4
	5	Supported Hardware
	6	==================
	7
	8	ARK 2000PV chip
	9	ICS 5342 ramdac
	10
	11	- only BIOS initialized VGA devices supported
	12	- probably not working on big endian
	13
	14
	15	Supported Features
	16	==================
	17
	18	* 4 bpp pseudocolor modes (with 18bit palette, two variants)
	19	* 8 bpp pseudocolor mode (with 18bit palette)
	20	* 16 bpp truecolor modes (RGB 555 and RGB 565)
	21	* 24 bpp truecolor mode (RGB 888)
	22	* 32 bpp truecolor mode (RGB 888)
	23	* text mode (activated by bpp = 0)
	24	* doublescan mode variant (not available in text mode)
	25	* panning in both directions
	26	* suspend/resume support
	27
	28	Text mode is supported even in higher resolutions, but there is limitation to
	29	lower pixclocks (i got maximum about 70 MHz, it is dependent on specific
	30	hardware). This limitation is not enforced by driver. Text mode supports 8bit
	31	wide fonts only (hardware limitation) and 16bit tall fonts (driver
	32	limitation). Unfortunately character attributes (like color) in text mode are
	33	broken for unknown reason, so its usefulness is limited.
	34
	35	There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
	36	packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
	37	with interleaved planes (1 byte interleave), MSB first. Both modes support
	38	8bit wide fonts only (driver limitation).
	39
	40	Suspend/resume works on systems that initialize video card during resume and
	41	if device is active (for example used by fbcon).
	42
	43
	44	Missing Features
	45	================
	46	(alias TODO list)
	47
	48	* secondary (not initialized by BIOS) device support
	49	* big endian support
	50	* DPMS support
	51	* MMIO support
	52	* interlaced mode variant
	53	* support for fontwidths != 8 in 4 bpp modes
	54	* support for fontheight != 16 in text mode
	55	* hardware cursor
	56	* vsync synchronization
	57	* feature connector support
	58	* acceleration support (8514-like 2D)
	59
	60
	61	Known bugs
	62	==========
	63
	64	* character attributes (and cursor) in text mode are broken
	65
	66	--
	67	Ondrej Zajicek <santiago@crfreenet.org>

-68

~~debian/doc/kernel-doc/arkfb.txt~~ less more

0
1		arkfb - fbdev driver for ARK Logic chips
2		========================================
3
4
5		Supported Hardware
6		==================
7
8		ARK 2000PV chip
9		ICS 5342 ramdac
10
11		- only BIOS initialized VGA devices supported
12		- probably not working on big endian
13
14
15		Supported Features
16		==================
17
18		* 4 bpp pseudocolor modes (with 18bit palette, two variants)
19		* 8 bpp pseudocolor mode (with 18bit palette)
20		* 16 bpp truecolor modes (RGB 555 and RGB 565)
21		* 24 bpp truecolor mode (RGB 888)
22		* 32 bpp truecolor mode (RGB 888)
23		* text mode (activated by bpp = 0)
24		* doublescan mode variant (not available in text mode)
25		* panning in both directions
26		* suspend/resume support
27
28		Text mode is supported even in higher resolutions, but there is limitation to
29		lower pixclocks (i got maximum about 70 MHz, it is dependent on specific
30		hardware). This limitation is not enforced by driver. Text mode supports 8bit
31		wide fonts only (hardware limitation) and 16bit tall fonts (driver
32		limitation). Unfortunately character attributes (like color) in text mode are
33		broken for unknown reason, so its usefulness is limited.
34
35		There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
36		packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
37		with interleaved planes (1 byte interleave), MSB first. Both modes support
38		8bit wide fonts only (driver limitation).
39
40		Suspend/resume works on systems that initialize video card during resume and
41		if device is active (for example used by fbcon).
42
43
44		Missing Features
45		================
46		(alias TODO list)
47
48		* secondary (not initialized by BIOS) device support
49		* big endian support
50		* DPMS support
51		* MMIO support
52		* interlaced mode variant
53		* support for fontwidths != 8 in 4 bpp modes
54		* support for fontheight != 16 in text mode
55		* hardware cursor
56		* vsync synchronization
57		* feature connector support
58		* acceleration support (8514-like 2D)
59
60
61		Known bugs
62		==========
63
64		* character attributes (and cursor) in text mode are broken
65
66		--
67		Ondrej Zajicek <santiago@crfreenet.org>

+75

-0

debian/doc/kernel-doc/aty128fb.rst less more

	0	=================
	1	What is aty128fb?
	2	=================
	3
	4	.. [This file is cloned from VesaFB/matroxfb]
	5
	6	This is a driver for a graphic framebuffer for ATI Rage128 based devices
	7	on Intel and PPC boxes.
	8
	9	Advantages:
	10
	11	* It provides a nice large console (128 cols + 48 lines with 1024x768)
	12	without using tiny, unreadable fonts.
	13	* You can run XF68_FBDev on top of /dev/fb0
	14	* Most important: boot logo :-)
	15
	16	Disadvantages:
	17
	18	* graphic mode is slower than text mode... but you should not notice
	19	if you use same resolution as you used in textmode.
	20	* still experimental.
	21
	22
	23	How to use it?
	24	==============
	25
	26	Switching modes is done using the video=aty128fb:<resolution>... modedb
	27	boot parameter or using `fbset` program.
	28
	29	See Documentation/fb/modedb.rst for more information on modedb
	30	resolutions.
	31
	32	You should compile in both vgacon (to boot if you remove your Rage128 from
	33	box) and aty128fb (for graphics mode). You should not compile-in vesafb
	34	unless you have primary display on non-Rage128 VBE2.0 device (see
	35	Documentation/fb/vesafb.rst for details).
	36
	37
	38	X11
	39	===
	40
	41	XF68_FBDev should generally work fine, but it is non-accelerated. As of
	42	this document, 8 and 32bpp works fine. There have been palette issues
	43	when switching from X to console and back to X. You will have to restart
	44	X to fix this.
	45
	46
	47	Configuration
	48	=============
	49
	50	You can pass kernel command line options to vesafb with
	51	`video=aty128fb:option1,option2:value2,option3` (multiple options should
	52	be separated by comma, values are separated from options by `:`).
	53	Accepted options:
	54
	55	========= =======================================================
	56	noaccel do not use acceleration engine. It is default.
	57	accel use acceleration engine. Not finished.
	58	vmode:x chooses PowerMacintosh video mode <x>. Deprecated.
	59	cmode:x chooses PowerMacintosh colour mode <x>. Deprecated.
	60	<XxX@X> selects startup videomode. See modedb.txt for detailed
	61	explanation. Default is 640x480x8bpp.
	62	========= =======================================================
	63
	64
	65	Limitations
	66	===========
	67
	68	There are known and unknown bugs, features and misfeatures.
	69	Currently there are following known bugs:
	70
	71	- This driver is still experimental and is not finished. Too many
	72	bugs/errata to list here.
	73
	74	Brad Douglas <brad@neruo.com>

-72

~~debian/doc/kernel-doc/aty128fb.txt~~ less more

0		[This file is cloned from VesaFB/matroxfb]
1
2		What is aty128fb?
3		=================
4
5		This is a driver for a graphic framebuffer for ATI Rage128 based devices
6		on Intel and PPC boxes.
7
8		Advantages:
9
10		* It provides a nice large console (128 cols + 48 lines with 1024x768)
11		without using tiny, unreadable fonts.
12		* You can run XF68_FBDev on top of /dev/fb0
13		* Most important: boot logo :-)
14
15		Disadvantages:
16
17		* graphic mode is slower than text mode... but you should not notice
18		if you use same resolution as you used in textmode.
19		* still experimental.
20
21
22		How to use it?
23		==============
24
25		Switching modes is done using the video=aty128fb:<resolution>... modedb
26		boot parameter or using `fbset' program.
27
28		See Documentation/fb/modedb.txt for more information on modedb
29		resolutions.
30
31		You should compile in both vgacon (to boot if you remove your Rage128 from
32		box) and aty128fb (for graphics mode). You should not compile-in vesafb
33		unless you have primary display on non-Rage128 VBE2.0 device (see
34		Documentation/fb/vesafb.txt for details).
35
36
37		X11
38		===
39
40		XF68_FBDev should generally work fine, but it is non-accelerated. As of
41		this document, 8 and 32bpp works fine. There have been palette issues
42		when switching from X to console and back to X. You will have to restart
43		X to fix this.
44
45
46		Configuration
47		=============
48
49		You can pass kernel command line options to vesafb with
50		`video=aty128fb:option1,option2:value2,option3' (multiple options should
51		be separated by comma, values are separated from options by `:').
52		Accepted options:
53
54		noaccel - do not use acceleration engine. It is default.
55		accel - use acceleration engine. Not finished.
56		vmode:x - chooses PowerMacintosh video mode <x>. Deprecated.
57		cmode:x - chooses PowerMacintosh colour mode <x>. Deprecated.
58		<XxX@X> - selects startup videomode. See modedb.txt for detailed
59		explanation. Default is 640x480x8bpp.
60
61
62		Limitations
63		===========
64
65		There are known and unknown bugs, features and misfeatures.
66		Currently there are following known bugs:
67		+ This driver is still experimental and is not finished. Too many
68		bugs/errata to list here.
69
70		--
71		Brad Douglas <brad@neruo.com>

+94

-0

debian/doc/kernel-doc/cirrusfb.rst less more

	0	============================================
	1	Framebuffer driver for Cirrus Logic chipsets
	2	============================================
	3
	4	Copyright 1999 Jeff Garzik <jgarzik@pobox.com>
	5
	6
	7	.. just a little something to get people going; contributors welcome!
	8
	9
	10	Chip families supported:
	11	- SD64
	12	- Piccolo
	13	- Picasso
	14	- Spectrum
	15	- Alpine (GD-543x/4x)
	16	- Picasso4 (GD-5446)
	17	- GD-5480
	18	- Laguna (GD-546x)
	19
	20	Bus's supported:
	21	- PCI
	22	- Zorro
	23
	24	Architectures supported:
	25	- i386
	26	- Alpha
	27	- PPC (Motorola Powerstack)
	28	- m68k (Amiga)
	29
	30
	31
	32	Default video modes
	33	-------------------
	34	At the moment, there are two kernel command line arguments supported:
	35
	36	- mode:640x480
	37	- mode:800x600
	38	- mode:1024x768
	39
	40	Full support for startup video modes (modedb) will be integrated soon.
	41
	42	Version 1.9.9.1
	43	---------------
	44	* Fix memory detection for 512kB case
	45	* 800x600 mode
	46	* Fixed timings
	47	* Hint for AXP: Use -accel false -vyres -1 when changing resolution
	48
	49
	50	Version 1.9.4.4
	51	---------------
	52	* Preliminary Laguna support
	53	* Overhaul color register routines.
	54	* Associated with the above, console colors are now obtained from a LUT
	55	called 'palette' instead of from the VGA registers. This code was
	56	modelled after that in atyfb and matroxfb.
	57	* Code cleanup, add comments.
	58	* Overhaul SR07 handling.
	59	* Bug fixes.
	60
	61
	62	Version 1.9.4.3
	63	---------------
	64	* Correctly set default startup video mode.
	65	* Do not override ram size setting. Define
	66	CLGEN_USE_HARDCODED_RAM_SETTINGS if you _do_ want to override the RAM
	67	setting.
	68	* Compile fixes related to new 2.3.x IORESOURCE_IO[PORT] symbol changes.
	69	* Use new 2.3.x resource allocation.
	70	* Some code cleanup.
	71
	72
	73	Version 1.9.4.2
	74	---------------
	75	* Casting fixes.
	76	* Assertions no longer cause an oops on purpose.
	77	* Bug fixes.
	78
	79
	80	Version 1.9.4.1
	81	---------------
	82	* Add compatibility support. Now requires a 2.1.x, 2.2.x or 2.3.x kernel.
	83
	84
	85	Version 1.9.4
	86	-------------
	87	* Several enhancements, smaller memory footprint, a few bugfixes.
	88	* Requires kernel 2.3.14-pre1 or later.
	89
	90
	91	Version 1.9.3
	92	-------------
	93	* Bundled with kernel 2.3.14-pre1 or later.

-97

~~debian/doc/kernel-doc/cirrusfb.txt~~ less more

0
1		Framebuffer driver for Cirrus Logic chipsets
2		Copyright 1999 Jeff Garzik <jgarzik@pobox.com>
3
4
5
6		{ just a little something to get people going; contributors welcome! }
7
8
9
10		Chip families supported:
11		SD64
12		Piccolo
13		Picasso
14		Spectrum
15		Alpine (GD-543x/4x)
16		Picasso4 (GD-5446)
17		GD-5480
18		Laguna (GD-546x)
19
20		Bus's supported:
21		PCI
22		Zorro
23
24		Architectures supported:
25		i386
26		Alpha
27		PPC (Motorola Powerstack)
28		m68k (Amiga)
29
30
31
32		Default video modes
33		-------------------
34		At the moment, there are two kernel command line arguments supported:
35
36		mode:640x480
37		mode:800x600
38		or
39		mode:1024x768
40
41		Full support for startup video modes (modedb) will be integrated soon.
42
43		Version 1.9.9.1
44		---------------
45		* Fix memory detection for 512kB case
46		* 800x600 mode
47		* Fixed timings
48		* Hint for AXP: Use -accel false -vyres -1 when changing resolution
49
50
51		Version 1.9.4.4
52		---------------
53		* Preliminary Laguna support
54		* Overhaul color register routines.
55		* Associated with the above, console colors are now obtained from a LUT
56		called 'palette' instead of from the VGA registers. This code was
57		modelled after that in atyfb and matroxfb.
58		* Code cleanup, add comments.
59		* Overhaul SR07 handling.
60		* Bug fixes.
61
62
63		Version 1.9.4.3
64		---------------
65		* Correctly set default startup video mode.
66		* Do not override ram size setting. Define
67		CLGEN_USE_HARDCODED_RAM_SETTINGS if you _do_ want to override the RAM
68		setting.
69		* Compile fixes related to new 2.3.x IORESOURCE_IO[PORT] symbol changes.
70		* Use new 2.3.x resource allocation.
71		* Some code cleanup.
72
73
74		Version 1.9.4.2
75		---------------
76		* Casting fixes.
77		* Assertions no longer cause an oops on purpose.
78		* Bug fixes.
79
80
81		Version 1.9.4.1
82		---------------
83		* Add compatibility support. Now requires a 2.1.x, 2.2.x or 2.3.x kernel.
84
85
86		Version 1.9.4
87		-------------
88		* Several enhancements, smaller memory footprint, a few bugfixes.
89		* Requires kernel 2.3.14-pre1 or later.
90
91
92		Version 1.9.3
93		-------------
94		* Bundled with kernel 2.3.14-pre1 or later.
95
96

+56

-0

debian/doc/kernel-doc/cmap_xfbdev.rst less more

	0	==========================
	1	Understanding fbdev's cmap
	2	==========================
	3
	4	These notes explain how X's dix layer uses fbdev's cmap structures.
	5
	6	- example of relevant structures in fbdev as used for a 3-bit grayscale cmap::
	7
	8	struct fb_var_screeninfo {
	9	.bits_per_pixel = 8,
	10	.grayscale = 1,
	11	.red = { 4, 3, 0 },
	12	.green = { 0, 0, 0 },
	13	.blue = { 0, 0, 0 },
	14	}
	15	struct fb_fix_screeninfo {
	16	.visual = FB_VISUAL_STATIC_PSEUDOCOLOR,
	17	}
	18	for (i = 0; i < 8; i++)
	19	info->cmap.red[i] = (((2i)+1)(0xFFFF))/16;
	20	memcpy(info->cmap.green, info->cmap.red, sizeof(u16)*8);
	21	memcpy(info->cmap.blue, info->cmap.red, sizeof(u16)*8);
	22
	23	- X11 apps do something like the following when trying to use grayscale::
	24
	25	for (i=0; i < 8; i++) {
	26	char colorspec[64];
	27	memset(colorspec,0,64);
	28	sprintf(colorspec, "rgb:%x/%x/%x", i36,i36,i*36);
	29	if (!XParseColor(outputDisplay, testColormap, colorspec, &wantedColor))
	30	printf("Can't get color %s\n",colorspec);
	31	XAllocColor(outputDisplay, testColormap, &wantedColor);
	32	grays[i] = wantedColor;
	33	}
	34
	35	There's also named equivalents like gray1..x provided you have an rgb.txt.
	36
	37	Somewhere in X's callchain, this results in a call to X code that handles the
	38	colormap. For example, Xfbdev hits the following:
	39
	40	xc-011010/programs/Xserver/dix/colormap.c::
	41
	42	FindBestPixel(pentFirst, size, prgb, channel)
	43
	44	dr = (long) pent->co.local.red - prgb->red;
	45	dg = (long) pent->co.local.green - prgb->green;
	46	db = (long) pent->co.local.blue - prgb->blue;
	47	sq = dr * dr;
	48	UnsignedToBigNum (sq, &sum);
	49	BigNumAdd (&sum, &temp, &sum);
	50
	51	co.local.red are entries that were brought in through FBIOGETCMAP which come
	52	directly from the info->cmap.red that was listed above. The prgb is the rgb
	53	that the app wants to match to. The above code is doing what looks like a least
	54	squares matching function. That's why the cmap entries can't be set to the left
	55	hand side boundaries of a color range.

-53

~~debian/doc/kernel-doc/cmap_xfbdev.txt~~ less more

0		Understanding fbdev's cmap
1		--------------------------
2
3		These notes explain how X's dix layer uses fbdev's cmap structures.
4
5		*. example of relevant structures in fbdev as used for a 3-bit grayscale cmap
6		struct fb_var_screeninfo {
7		.bits_per_pixel = 8,
8		.grayscale = 1,
9		.red = { 4, 3, 0 },
10		.green = { 0, 0, 0 },
11		.blue = { 0, 0, 0 },
12		}
13		struct fb_fix_screeninfo {
14		.visual = FB_VISUAL_STATIC_PSEUDOCOLOR,
15		}
16		for (i = 0; i < 8; i++)
17		info->cmap.red[i] = (((2i)+1)(0xFFFF))/16;
18		memcpy(info->cmap.green, info->cmap.red, sizeof(u16)*8);
19		memcpy(info->cmap.blue, info->cmap.red, sizeof(u16)*8);
20
21		*. X11 apps do something like the following when trying to use grayscale.
22		for (i=0; i < 8; i++) {
23		char colorspec[64];
24		memset(colorspec,0,64);
25		sprintf(colorspec, "rgb:%x/%x/%x", i36,i36,i*36);
26		if (!XParseColor(outputDisplay, testColormap, colorspec, &wantedColor))
27		printf("Can't get color %s\n",colorspec);
28		XAllocColor(outputDisplay, testColormap, &wantedColor);
29		grays[i] = wantedColor;
30		}
31		There's also named equivalents like gray1..x provided you have an rgb.txt.
32
33		Somewhere in X's callchain, this results in a call to X code that handles the
34		colormap. For example, Xfbdev hits the following:
35
36		xc-011010/programs/Xserver/dix/colormap.c:
37
38		FindBestPixel(pentFirst, size, prgb, channel)
39
40		dr = (long) pent->co.local.red - prgb->red;
41		dg = (long) pent->co.local.green - prgb->green;
42		db = (long) pent->co.local.blue - prgb->blue;
43		sq = dr * dr;
44		UnsignedToBigNum (sq, &sum);
45		BigNumAdd (&sum, &temp, &sum);
46
47		co.local.red are entries that were brought in through FBIOGETCMAP which come
48		directly from the info->cmap.red that was listed above. The prgb is the rgb
49		that the app wants to match to. The above code is doing what looks like a least
50		squares matching function. That's why the cmap entries can't be set to the left
51		hand side boundaries of a color range.
52

+79

-0

debian/doc/kernel-doc/deferred_io.rst less more

	0	===========
	1	Deferred IO
	2	===========
	3
	4	Deferred IO is a way to delay and repurpose IO. It uses host memory as a
	5	buffer and the MMU pagefault as a pretrigger for when to perform the device
	6	IO. The following example may be a useful explanation of how one such setup
	7	works:
	8
	9	- userspace app like Xfbdev mmaps framebuffer
	10	- deferred IO and driver sets up fault and page_mkwrite handlers
	11	- userspace app tries to write to mmaped vaddress
	12	- we get pagefault and reach fault handler
	13	- fault handler finds and returns physical page
	14	- we get page_mkwrite where we add this page to a list
	15	- schedule a workqueue task to be run after a delay
	16	- app continues writing to that page with no additional cost. this is
	17	the key benefit.
	18	- the workqueue task comes in and mkcleans the pages on the list, then
	19	completes the work associated with updating the framebuffer. this is
	20	the real work talking to the device.
	21	- app tries to write to the address (that has now been mkcleaned)
	22	- get pagefault and the above sequence occurs again
	23
	24	As can be seen from above, one benefit is roughly to allow bursty framebuffer
	25	writes to occur at minimum cost. Then after some time when hopefully things
	26	have gone quiet, we go and really update the framebuffer which would be
	27	a relatively more expensive operation.
	28
	29	For some types of nonvolatile high latency displays, the desired image is
	30	the final image rather than the intermediate stages which is why it's okay
	31	to not update for each write that is occurring.
	32
	33	It may be the case that this is useful in other scenarios as well. Paul Mundt
	34	has mentioned a case where it is beneficial to use the page count to decide
	35	whether to coalesce and issue SG DMA or to do memory bursts.
	36
	37	Another one may be if one has a device framebuffer that is in an usual format,
	38	say diagonally shifting RGB, this may then be a mechanism for you to allow
	39	apps to pretend to have a normal framebuffer but reswizzle for the device
	40	framebuffer at vsync time based on the touched pagelist.
	41
	42	How to use it: (for applications)
	43	---------------------------------
	44	No changes needed. mmap the framebuffer like normal and just use it.
	45
	46	How to use it: (for fbdev drivers)
	47	----------------------------------
	48	The following example may be helpful.
	49
	50	1. Setup your structure. Eg::
	51
	52	static struct fb_deferred_io hecubafb_defio = {
	53	.delay = HZ,
	54	.deferred_io = hecubafb_dpy_deferred_io,
	55	};
	56
	57	The delay is the minimum delay between when the page_mkwrite trigger occurs
	58	and when the deferred_io callback is called. The deferred_io callback is
	59	explained below.
	60
	61	2. Setup your deferred IO callback. Eg::
	62
	63	static void hecubafb_dpy_deferred_io(struct fb_info *info,
	64	struct list_head *pagelist)
	65
	66	The deferred_io callback is where you would perform all your IO to the display
	67	device. You receive the pagelist which is the list of pages that were written
	68	to during the delay. You must not modify this list. This callback is called
	69	from a workqueue.
	70
	71	3. Call init::
	72
	73	info->fbdefio = &hecubafb_defio;
	74	fb_deferred_io_init(info);
	75
	76	4. Call cleanup::
	77
	78	fb_deferred_io_cleanup(info);

-75

~~debian/doc/kernel-doc/deferred_io.txt~~ less more

0		Deferred IO
1		-----------
2
3		Deferred IO is a way to delay and repurpose IO. It uses host memory as a
4		buffer and the MMU pagefault as a pretrigger for when to perform the device
5		IO. The following example may be a useful explanation of how one such setup
6		works:
7
8		- userspace app like Xfbdev mmaps framebuffer
9		- deferred IO and driver sets up fault and page_mkwrite handlers
10		- userspace app tries to write to mmaped vaddress
11		- we get pagefault and reach fault handler
12		- fault handler finds and returns physical page
13		- we get page_mkwrite where we add this page to a list
14		- schedule a workqueue task to be run after a delay
15		- app continues writing to that page with no additional cost. this is
16		the key benefit.
17		- the workqueue task comes in and mkcleans the pages on the list, then
18		completes the work associated with updating the framebuffer. this is
19		the real work talking to the device.
20		- app tries to write to the address (that has now been mkcleaned)
21		- get pagefault and the above sequence occurs again
22
23		As can be seen from above, one benefit is roughly to allow bursty framebuffer
24		writes to occur at minimum cost. Then after some time when hopefully things
25		have gone quiet, we go and really update the framebuffer which would be
26		a relatively more expensive operation.
27
28		For some types of nonvolatile high latency displays, the desired image is
29		the final image rather than the intermediate stages which is why it's okay
30		to not update for each write that is occurring.
31
32		It may be the case that this is useful in other scenarios as well. Paul Mundt
33		has mentioned a case where it is beneficial to use the page count to decide
34		whether to coalesce and issue SG DMA or to do memory bursts.
35
36		Another one may be if one has a device framebuffer that is in an usual format,
37		say diagonally shifting RGB, this may then be a mechanism for you to allow
38		apps to pretend to have a normal framebuffer but reswizzle for the device
39		framebuffer at vsync time based on the touched pagelist.
40
41		How to use it: (for applications)
42		---------------------------------
43		No changes needed. mmap the framebuffer like normal and just use it.
44
45		How to use it: (for fbdev drivers)
46		----------------------------------
47		The following example may be helpful.
48
49		1. Setup your structure. Eg:
50
51		static struct fb_deferred_io hecubafb_defio = {
52		.delay = HZ,
53		.deferred_io = hecubafb_dpy_deferred_io,
54		};
55
56		The delay is the minimum delay between when the page_mkwrite trigger occurs
57		and when the deferred_io callback is called. The deferred_io callback is
58		explained below.
59
60		2. Setup your deferred IO callback. Eg:
61		static void hecubafb_dpy_deferred_io(struct fb_info *info,
62		struct list_head *pagelist)
63
64		The deferred_io callback is where you would perform all your IO to the display
65		device. You receive the pagelist which is the list of pages that were written
66		to during the delay. You must not modify this list. This callback is called
67		from a workqueue.
68
69		3. Call init
70		info->fbdefio = &hecubafb_defio;
71		fb_deferred_io_init(info);
72
73		4. Call cleanup
74		fb_deferred_io_cleanup(info);

+39

-0

debian/doc/kernel-doc/efifb.rst less more

	0	==============
	1	What is efifb?
	2	==============
	3
	4	This is a generic EFI platform driver for Intel based Apple computers.
	5	efifb is only for EFI booted Intel Macs.
	6
	7	Supported Hardware
	8	==================
	9
	10	- iMac 17"/20"
	11	- Macbook
	12	- Macbook Pro 15"/17"
	13	- MacMini
	14
	15	How to use it?
	16	==============
	17
	18	efifb does not have any kind of autodetection of your machine.
	19	You have to add the following kernel parameters in your elilo.conf::
	20
	21	Macbook :
	22	video=efifb:macbook
	23	MacMini :
	24	video=efifb:mini
	25	Macbook Pro 15", iMac 17" :
	26	video=efifb:i17
	27	Macbook Pro 17", iMac 20" :
	28	video=efifb:i20
	29
	30	Accepted options:
	31
	32	======= ===========================================================
	33	nowc Don't map the framebuffer write combined. This can be used
	34	to workaround side-effects and slowdowns on other CPU cores
	35	when large amounts of console data are written.
	36	======= ===========================================================
	37
	38	Edgar Hucek <gimli@dark-green.com>

-31

~~debian/doc/kernel-doc/efifb.txt~~ less more

0
1		What is efifb?
2		===============
3
4		This is a generic EFI platform driver for Intel based Apple computers.
5		efifb is only for EFI booted Intel Macs.
6
7		Supported Hardware
8		==================
9
10		iMac 17"/20"
11		Macbook
12		Macbook Pro 15"/17"
13		MacMini
14
15		How to use it?
16		==============
17
18		efifb does not have any kind of autodetection of your machine.
19		You have to add the following kernel parameters in your elilo.conf:
20		Macbook :
21		video=efifb:macbook
22		MacMini :
23		video=efifb:mini
24		Macbook Pro 15", iMac 17" :
25		video=efifb:i17
26		Macbook Pro 17", iMac 20" :
27		video=efifb:i20
28
29		--
30		Edgar Hucek <gimli@dark-green.com>

+140

-0

debian/doc/kernel-doc/ep93xx-fb.rst less more

	0	================================
	1	Driver for EP93xx LCD controller
	2	================================
	3
	4	The EP93xx LCD controller can drive both standard desktop monitors and
	5	embedded LCD displays. If you have a standard desktop monitor then you
	6	can use the standard Linux video mode database. In your board file::
	7
	8	static struct ep93xxfb_mach_info some_board_fb_info = {
	9	.num_modes = EP93XXFB_USE_MODEDB,
	10	.bpp = 16,
	11	};
	12
	13	If you have an embedded LCD display then you need to define a video
	14	mode for it as follows::
	15
	16	static struct fb_videomode some_board_video_modes[] = {
	17	{
	18	.name = "some_lcd_name",
	19	/* Pixel clock, porches, etc */
	20	},
	21	};
	22
	23	Note that the pixel clock value is in pico-seconds. You can use the
	24	KHZ2PICOS macro to convert the pixel clock value. Most other values
	25	are in pixel clocks. See Documentation/fb/framebuffer.rst for further
	26	details.
	27
	28	The ep93xxfb_mach_info structure for your board should look like the
	29	following::
	30
	31	static struct ep93xxfb_mach_info some_board_fb_info = {
	32	.num_modes = ARRAY_SIZE(some_board_video_modes),
	33	.modes = some_board_video_modes,
	34	.default_mode = &some_board_video_modes[0],
	35	.bpp = 16,
	36	};
	37
	38	The framebuffer device can be registered by adding the following to
	39	your board initialisation function::
	40
	41	ep93xx_register_fb(&some_board_fb_info);
	42
	43	=====================
	44	Video Attribute Flags
	45	=====================
	46
	47	The ep93xxfb_mach_info structure has a flags field which can be used
	48	to configure the controller. The video attributes flags are fully
	49	documented in section 7 of the EP93xx users' guide. The following
	50	flags are available:
	51
	52	=============================== ==========================================
	53	EP93XXFB_PCLK_FALLING Clock data on the falling edge of the
	54	pixel clock. The default is to clock
	55	data on the rising edge.
	56
	57	EP93XXFB_SYNC_BLANK_HIGH Blank signal is active high. By
	58	default the blank signal is active low.
	59
	60	EP93XXFB_SYNC_HORIZ_HIGH Horizontal sync is active high. By
	61	default the horizontal sync is active low.
	62
	63	EP93XXFB_SYNC_VERT_HIGH Vertical sync is active high. By
	64	default the vertical sync is active high.
	65	=============================== ==========================================
	66
	67	The physical address of the framebuffer can be controlled using the
	68	following flags:
	69
	70	=============================== ======================================
	71	EP93XXFB_USE_SDCSN0 Use SDCSn[0] for the framebuffer. This
	72	is the default setting.
	73
	74	EP93XXFB_USE_SDCSN1 Use SDCSn[1] for the framebuffer.
	75
	76	EP93XXFB_USE_SDCSN2 Use SDCSn[2] for the framebuffer.
	77
	78	EP93XXFB_USE_SDCSN3 Use SDCSn[3] for the framebuffer.
	79	=============================== ======================================
	80
	81	==================
	82	Platform callbacks
	83	==================
	84
	85	The EP93xx framebuffer driver supports three optional platform
	86	callbacks: setup, teardown and blank. The setup and teardown functions
	87	are called when the framebuffer driver is installed and removed
	88	respectively. The blank function is called whenever the display is
	89	blanked or unblanked.
	90
	91	The setup and teardown devices pass the platform_device structure as
	92	an argument. The fb_info and ep93xxfb_mach_info structures can be
	93	obtained as follows::
	94
	95	static int some_board_fb_setup(struct platform_device *pdev)
	96	{
	97	struct ep93xxfb_mach_info *mach_info = pdev->dev.platform_data;
	98	struct fb_info *fb_info = platform_get_drvdata(pdev);
	99
	100	/* Board specific framebuffer setup */
	101	}
	102
	103	======================
	104	Setting the video mode
	105	======================
	106
	107	The video mode is set using the following syntax::
	108
	109	video=XRESxYRES[-BPP][@REFRESH]
	110
	111	If the EP93xx video driver is built-in then the video mode is set on
	112	the Linux kernel command line, for example::
	113
	114	video=ep93xx-fb:800x600-16@60
	115
	116	If the EP93xx video driver is built as a module then the video mode is
	117	set when the module is installed::
	118
	119	modprobe ep93xx-fb video=320x240
	120
	121	==============
	122	Screenpage bug
	123	==============
	124
	125	At least on the EP9315 there is a silicon bug which causes bit 27 of
	126	the VIDSCRNPAGE (framebuffer physical offset) to be tied low. There is
	127	an unofficial errata for this bug at::
	128
	129	http://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2
	130
	131	By default the EP93xx framebuffer driver checks if the allocated physical
	132	address has bit 27 set. If it does, then the memory is freed and an
	133	error is returned. The check can be disabled by adding the following
	134	option when loading the driver::
	135
	136	ep93xx-fb.check_screenpage_bug=0
	137
	138	In some cases it may be possible to reconfigure your SDRAM layout to
	139	avoid this bug. See section 13 of the EP93xx users' guide for details.

-135

~~debian/doc/kernel-doc/ep93xx-fb.txt~~ less more

0		================================
1		Driver for EP93xx LCD controller
2		================================
3
4		The EP93xx LCD controller can drive both standard desktop monitors and
5		embedded LCD displays. If you have a standard desktop monitor then you
6		can use the standard Linux video mode database. In your board file:
7
8		static struct ep93xxfb_mach_info some_board_fb_info = {
9		.num_modes = EP93XXFB_USE_MODEDB,
10		.bpp = 16,
11		};
12
13		If you have an embedded LCD display then you need to define a video
14		mode for it as follows:
15
16		static struct fb_videomode some_board_video_modes[] = {
17		{
18		.name = "some_lcd_name",
19		/* Pixel clock, porches, etc */
20		},
21		};
22
23		Note that the pixel clock value is in pico-seconds. You can use the
24		KHZ2PICOS macro to convert the pixel clock value. Most other values
25		are in pixel clocks. See Documentation/fb/framebuffer.txt for further
26		details.
27
28		The ep93xxfb_mach_info structure for your board should look like the
29		following:
30
31		static struct ep93xxfb_mach_info some_board_fb_info = {
32		.num_modes = ARRAY_SIZE(some_board_video_modes),
33		.modes = some_board_video_modes,
34		.default_mode = &some_board_video_modes[0],
35		.bpp = 16,
36		};
37
38		The framebuffer device can be registered by adding the following to
39		your board initialisation function:
40
41		ep93xx_register_fb(&some_board_fb_info);
42
43		=====================
44		Video Attribute Flags
45		=====================
46
47		The ep93xxfb_mach_info structure has a flags field which can be used
48		to configure the controller. The video attributes flags are fully
49		documented in section 7 of the EP93xx users' guide. The following
50		flags are available:
51
52		EP93XXFB_PCLK_FALLING Clock data on the falling edge of the
53		pixel clock. The default is to clock
54		data on the rising edge.
55
56		EP93XXFB_SYNC_BLANK_HIGH Blank signal is active high. By
57		default the blank signal is active low.
58
59		EP93XXFB_SYNC_HORIZ_HIGH Horizontal sync is active high. By
60		default the horizontal sync is active low.
61
62		EP93XXFB_SYNC_VERT_HIGH Vertical sync is active high. By
63		default the vertical sync is active high.
64
65		The physical address of the framebuffer can be controlled using the
66		following flags:
67
68		EP93XXFB_USE_SDCSN0 Use SDCSn[0] for the framebuffer. This
69		is the default setting.
70
71		EP93XXFB_USE_SDCSN1 Use SDCSn[1] for the framebuffer.
72
73		EP93XXFB_USE_SDCSN2 Use SDCSn[2] for the framebuffer.
74
75		EP93XXFB_USE_SDCSN3 Use SDCSn[3] for the framebuffer.
76
77		==================
78		Platform callbacks
79		==================
80
81		The EP93xx framebuffer driver supports three optional platform
82		callbacks: setup, teardown and blank. The setup and teardown functions
83		are called when the framebuffer driver is installed and removed
84		respectively. The blank function is called whenever the display is
85		blanked or unblanked.
86
87		The setup and teardown devices pass the platform_device structure as
88		an argument. The fb_info and ep93xxfb_mach_info structures can be
89		obtained as follows:
90
91		static int some_board_fb_setup(struct platform_device *pdev)
92		{
93		struct ep93xxfb_mach_info *mach_info = pdev->dev.platform_data;
94		struct fb_info *fb_info = platform_get_drvdata(pdev);
95
96		/* Board specific framebuffer setup */
97		}
98
99		======================
100		Setting the video mode
101		======================
102
103		The video mode is set using the following syntax:
104
105		video=XRESxYRES[-BPP][@REFRESH]
106
107		If the EP93xx video driver is built-in then the video mode is set on
108		the Linux kernel command line, for example:
109
110		video=ep93xx-fb:800x600-16@60
111
112		If the EP93xx video driver is built as a module then the video mode is
113		set when the module is installed:
114
115		modprobe ep93xx-fb video=320x240
116
117		==============
118		Screenpage bug
119		==============
120
121		At least on the EP9315 there is a silicon bug which causes bit 27 of
122		the VIDSCRNPAGE (framebuffer physical offset) to be tied low. There is
123		an unofficial errata for this bug at:
124		http://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2
125
126		By default the EP93xx framebuffer driver checks if the allocated physical
127		address has bit 27 set. If it does, then the memory is freed and an
128		error is returned. The check can be disabled by adding the following
129		option when loading the driver:
130
131		ep93xx-fb.check_screenpage_bug=0
132
133		In some cases it may be possible to reconfigure your SDRAM layout to
134		avoid this bug. See section 13 of the EP93xx users' guide for details.

+350

-0

debian/doc/kernel-doc/fbcon.rst less more

	0	=======================
	1	The Framebuffer Console
	2	=======================
	3
	4	The framebuffer console (fbcon), as its name implies, is a text
	5	console running on top of the framebuffer device. It has the functionality of
	6	any standard text console driver, such as the VGA console, with the added
	7	features that can be attributed to the graphical nature of the framebuffer.
	8
	9	In the x86 architecture, the framebuffer console is optional, and
	10	some even treat it as a toy. For other architectures, it is the only available
	11	display device, text or graphical.
	12
	13	What are the features of fbcon? The framebuffer console supports
	14	high resolutions, varying font types, display rotation, primitive multihead,
	15	etc. Theoretically, multi-colored fonts, blending, aliasing, and any feature
	16	made available by the underlying graphics card are also possible.
	17
	18	A. Configuration
	19	================
	20
	21	The framebuffer console can be enabled by using your favorite kernel
	22	configuration tool. It is under Device Drivers->Graphics Support->Frame
	23	buffer Devices->Console display driver support->Framebuffer Console Support.
	24	Select 'y' to compile support statically or 'm' for module support. The
	25	module will be fbcon.
	26
	27	In order for fbcon to activate, at least one framebuffer driver is
	28	required, so choose from any of the numerous drivers available. For x86
	29	systems, they almost universally have VGA cards, so vga16fb and vesafb will
	30	always be available. However, using a chipset-specific driver will give you
	31	more speed and features, such as the ability to change the video mode
	32	dynamically.
	33
	34	To display the penguin logo, choose any logo available in Graphics
	35	support->Bootup logo.
	36
	37	Also, you will need to select at least one compiled-in font, but if
	38	you don't do anything, the kernel configuration tool will select one for you,
	39	usually an 8x16 font.
	40
	41	GOTCHA: A common bug report is enabling the framebuffer without enabling the
	42	framebuffer console. Depending on the driver, you may get a blanked or
	43	garbled display, but the system still boots to completion. If you are
	44	fortunate to have a driver that does not alter the graphics chip, then you
	45	will still get a VGA console.
	46
	47	B. Loading
	48	==========
	49
	50	Possible scenarios:
	51
	52	1. Driver and fbcon are compiled statically
	53
	54	Usually, fbcon will automatically take over your console. The notable
	55	exception is vesafb. It needs to be explicitly activated with the
	56	vga= boot option parameter.
	57
	58	2. Driver is compiled statically, fbcon is compiled as a module
	59
	60	Depending on the driver, you either get a standard console, or a
	61	garbled display, as mentioned above. To get a framebuffer console,
	62	do a 'modprobe fbcon'.
	63
	64	3. Driver is compiled as a module, fbcon is compiled statically
	65
	66	You get your standard console. Once the driver is loaded with
	67	'modprobe xxxfb', fbcon automatically takes over the console with
	68	the possible exception of using the fbcon=map:n option. See below.
	69
	70	4. Driver and fbcon are compiled as a module.
	71
	72	You can load them in any order. Once both are loaded, fbcon will take
	73	over the console.
	74
	75	C. Boot options
	76
	77	The framebuffer console has several, largely unknown, boot options
	78	that can change its behavior.
	79
	80	1. fbcon=font:<name>
	81
	82	Select the initial font to use. The value 'name' can be any of the
	83	compiled-in fonts: 10x18, 6x10, 7x14, Acorn8x8, MINI4x6,
	84	PEARL8x8, ProFont6x11, SUN12x22, SUN8x16, TER16x32, VGA8x16, VGA8x8.
	85
	86	Note, not all drivers can handle font with widths not divisible by 8,
	87	such as vga16fb.
	88
	89	2. fbcon=scrollback:<value>[k]
	90
	91	The scrollback buffer is memory that is used to preserve display
	92	contents that has already scrolled past your view. This is accessed
	93	by using the Shift-PageUp key combination. The value 'value' is any
	94	integer. It defaults to 32KB. The 'k' suffix is optional, and will
	95	multiply the 'value' by 1024.
	96
	97	3. fbcon=map:<0123>
	98
	99	This is an interesting option. It tells which driver gets mapped to
	100	which console. The value '0123' is a sequence that gets repeated until
	101	the total length is 64 which is the number of consoles available. In
	102	the above example, it is expanded to 012301230123... and the mapping
	103	will be::
	104
	105	tty \| 1 2 3 4 5 6 7 8 9 ...
	106	fb \| 0 1 2 3 0 1 2 3 0 ...
	107
	108	('cat /proc/fb' should tell you what the fb numbers are)
	109
	110	One side effect that may be useful is using a map value that exceeds
	111	the number of loaded fb drivers. For example, if only one driver is
	112	available, fb0, adding fbcon=map:1 tells fbcon not to take over the
	113	console.
	114
	115	Later on, when you want to map the console the to the framebuffer
	116	device, you can use the con2fbmap utility.
	117
	118	4. fbcon=vc:<n1>-<n2>
	119
	120	This option tells fbcon to take over only a range of consoles as
	121	specified by the values 'n1' and 'n2'. The rest of the consoles
	122	outside the given range will still be controlled by the standard
	123	console driver.
	124
	125	NOTE: For x86 machines, the standard console is the VGA console which
	126	is typically located on the same video card. Thus, the consoles that
	127	are controlled by the VGA console will be garbled.
	128
	129	4. fbcon=rotate:<n>
	130
	131	This option changes the orientation angle of the console display. The
	132	value 'n' accepts the following:
	133
	134	- 0 - normal orientation (0 degree)
	135	- 1 - clockwise orientation (90 degrees)
	136	- 2 - upside down orientation (180 degrees)
	137	- 3 - counterclockwise orientation (270 degrees)
	138
	139	The angle can be changed anytime afterwards by 'echoing' the same
	140	numbers to any one of the 2 attributes found in
	141	/sys/class/graphics/fbcon:
	142
	143	- rotate - rotate the display of the active console
	144	- rotate_all - rotate the display of all consoles
	145
	146	Console rotation will only become available if Framebuffer Console
	147	Rotation support is compiled in your kernel.
	148
	149	NOTE: This is purely console rotation. Any other applications that
	150	use the framebuffer will remain at their 'normal' orientation.
	151	Actually, the underlying fb driver is totally ignorant of console
	152	rotation.
	153
	154	5. fbcon=margin:<color>
	155
	156	This option specifies the color of the margins. The margins are the
	157	leftover area at the right and the bottom of the screen that are not
	158	used by text. By default, this area will be black. The 'color' value
	159	is an integer number that depends on the framebuffer driver being used.
	160
	161	6. fbcon=nodefer
	162
	163	If the kernel is compiled with deferred fbcon takeover support, normally
	164	the framebuffer contents, left in place by the firmware/bootloader, will
	165	be preserved until there actually is some text is output to the console.
	166	This option causes fbcon to bind immediately to the fbdev device.
	167
	168	7. fbcon=logo-pos:<location>
	169
	170	The only possible 'location' is 'center' (without quotes), and when
	171	given, the bootup logo is moved from the default top-left corner
	172	location to the center of the framebuffer. If more than one logo is
	173	displayed due to multiple CPUs, the collected line of logos is moved
	174	as a whole.
	175
	176	C. Attaching, Detaching and Unloading
	177
	178	Before going on to how to attach, detach and unload the framebuffer console, an
	179	illustration of the dependencies may help.
	180
	181	The console layer, as with most subsystems, needs a driver that interfaces with
	182	the hardware. Thus, in a VGA console::
	183
	184	console ---> VGA driver ---> hardware.
	185
	186	Assuming the VGA driver can be unloaded, one must first unbind the VGA driver
	187	from the console layer before unloading the driver. The VGA driver cannot be
	188	unloaded if it is still bound to the console layer. (See
	189	Documentation/driver-api/console.rst for more information).
	190
	191	This is more complicated in the case of the framebuffer console (fbcon),
	192	because fbcon is an intermediate layer between the console and the drivers::
	193
	194	console ---> fbcon ---> fbdev drivers ---> hardware
	195
	196	The fbdev drivers cannot be unloaded if bound to fbcon, and fbcon cannot
	197	be unloaded if it's bound to the console layer.
	198
	199	So to unload the fbdev drivers, one must first unbind fbcon from the console,
	200	then unbind the fbdev drivers from fbcon. Fortunately, unbinding fbcon from
	201	the console layer will automatically unbind framebuffer drivers from
	202	fbcon. Thus, there is no need to explicitly unbind the fbdev drivers from
	203	fbcon.
	204
	205	So, how do we unbind fbcon from the console? Part of the answer is in
	206	Documentation/driver-api/console.rst. To summarize:
	207
	208	Echo a value to the bind file that represents the framebuffer console
	209	driver. So assuming vtcon1 represents fbcon, then::
	210
	211	echo 1 > sys/class/vtconsole/vtcon1/bind - attach framebuffer console to
	212	console layer
	213	echo 0 > sys/class/vtconsole/vtcon1/bind - detach framebuffer console from
	214	console layer
	215
	216	If fbcon is detached from the console layer, your boot console driver (which is
	217	usually VGA text mode) will take over. A few drivers (rivafb and i810fb) will
	218	restore VGA text mode for you. With the rest, before detaching fbcon, you
	219	must take a few additional steps to make sure that your VGA text mode is
	220	restored properly. The following is one of the several methods that you can do:
	221
	222	1. Download or install vbetool. This utility is included with most
	223	distributions nowadays, and is usually part of the suspend/resume tool.
	224
	225	2. In your kernel configuration, ensure that CONFIG_FRAMEBUFFER_CONSOLE is set
	226	to 'y' or 'm'. Enable one or more of your favorite framebuffer drivers.
	227
	228	3. Boot into text mode and as root run::
	229
	230	vbetool vbestate save > <vga state file>
	231
	232	The above command saves the register contents of your graphics
	233	hardware to <vga state file>. You need to do this step only once as
	234	the state file can be reused.
	235
	236	4. If fbcon is compiled as a module, load fbcon by doing::
	237
	238	modprobe fbcon
	239
	240	5. Now to detach fbcon::
	241
	242	vbetool vbestate restore < <vga state file> && \
	243	echo 0 > /sys/class/vtconsole/vtcon1/bind
	244
	245	6. That's it, you're back to VGA mode. And if you compiled fbcon as a module,
	246	you can unload it by 'rmmod fbcon'.
	247
	248	7. To reattach fbcon::
	249
	250	echo 1 > /sys/class/vtconsole/vtcon1/bind
	251
	252	8. Once fbcon is unbound, all drivers registered to the system will also
	253	become unbound. This means that fbcon and individual framebuffer drivers
	254	can be unloaded or reloaded at will. Reloading the drivers or fbcon will
	255	automatically bind the console, fbcon and the drivers together. Unloading
	256	all the drivers without unloading fbcon will make it impossible for the
	257	console to bind fbcon.
	258
	259	Notes for vesafb users:
	260	=======================
	261
	262	Unfortunately, if your bootline includes a vga=xxx parameter that sets the
	263	hardware in graphics mode, such as when loading vesafb, vgacon will not load.
	264	Instead, vgacon will replace the default boot console with dummycon, and you
	265	won't get any display after detaching fbcon. Your machine is still alive, so
	266	you can reattach vesafb. However, to reattach vesafb, you need to do one of
	267	the following:
	268
	269	Variation 1:
	270
	271	a. Before detaching fbcon, do::
	272
	273	vbetool vbemode save > <vesa state file> # do once for each vesafb mode,
	274	# the file can be reused
	275
	276	b. Detach fbcon as in step 5.
	277
	278	c. Attach fbcon::
	279
	280	vbetool vbestate restore < <vesa state file> && \
	281	echo 1 > /sys/class/vtconsole/vtcon1/bind
	282
	283	Variation 2:
	284
	285	a. Before detaching fbcon, do::
	286
	287	echo <ID> > /sys/class/tty/console/bind
	288
	289	vbetool vbemode get
	290
	291	b. Take note of the mode number
	292
	293	b. Detach fbcon as in step 5.
	294
	295	c. Attach fbcon::
	296
	297	vbetool vbemode set <mode number> && \
	298	echo 1 > /sys/class/vtconsole/vtcon1/bind
	299
	300	Samples:
	301	========
	302
	303	Here are 2 sample bash scripts that you can use to bind or unbind the
	304	framebuffer console driver if you are on an X86 box::
	305
	306	#!/bin/bash
	307	# Unbind fbcon
	308
	309	# Change this to where your actual vgastate file is located
	310	# Or Use VGASTATE=$1 to indicate the state file at runtime
	311	VGASTATE=/tmp/vgastate
	312
	313	# path to vbetool
	314	VBETOOL=/usr/local/bin
	315
	316
	317	for (( i = 0; i < 16; i++))
	318	do
	319	if test -x /sys/class/vtconsole/vtcon$i; then
	320	if [ `cat /sys/class/vtconsole/vtcon$i/name \| grep -c "frame buffer"` \
	321	= 1 ]; then
	322	if test -x $VBETOOL/vbetool; then
	323	echo Unbinding vtcon$i
	324	$VBETOOL/vbetool vbestate restore < $VGASTATE
	325	echo 0 > /sys/class/vtconsole/vtcon$i/bind
	326	fi
	327	fi
	328	fi
	329	done
	330
	331	---------------------------------------------------------------------------
	332
	333	::
	334
	335	#!/bin/bash
	336	# Bind fbcon
	337
	338	for (( i = 0; i < 16; i++))
	339	do
	340	if test -x /sys/class/vtconsole/vtcon$i; then
	341	if [ `cat /sys/class/vtconsole/vtcon$i/name \| grep -c "frame buffer"` \
	342	= 1 ]; then
	343	echo Unbinding vtcon$i
	344	echo 1 > /sys/class/vtconsole/vtcon$i/bind
	345	fi
	346	fi
	347	done
	348
	349	Antonino Daplas <adaplas@pol.net>

-324

~~debian/doc/kernel-doc/fbcon.txt~~ less more

0		The Framebuffer Console
1		=======================
2
3		The framebuffer console (fbcon), as its name implies, is a text
4		console running on top of the framebuffer device. It has the functionality of
5		any standard text console driver, such as the VGA console, with the added
6		features that can be attributed to the graphical nature of the framebuffer.
7
8		In the x86 architecture, the framebuffer console is optional, and
9		some even treat it as a toy. For other architectures, it is the only available
10		display device, text or graphical.
11
12		What are the features of fbcon? The framebuffer console supports
13		high resolutions, varying font types, display rotation, primitive multihead,
14		etc. Theoretically, multi-colored fonts, blending, aliasing, and any feature
15		made available by the underlying graphics card are also possible.
16
17		A. Configuration
18
19		The framebuffer console can be enabled by using your favorite kernel
20		configuration tool. It is under Device Drivers->Graphics Support->Support for
21		framebuffer devices->Framebuffer Console Support. Select 'y' to compile
22		support statically, or 'm' for module support. The module will be fbcon.
23
24		In order for fbcon to activate, at least one framebuffer driver is
25		required, so choose from any of the numerous drivers available. For x86
26		systems, they almost universally have VGA cards, so vga16fb and vesafb will
27		always be available. However, using a chipset-specific driver will give you
28		more speed and features, such as the ability to change the video mode
29		dynamically.
30
31		To display the penguin logo, choose any logo available in Logo
32		Configuration->Boot up logo.
33
34		Also, you will need to select at least one compiled-in fonts, but if
35		you don't do anything, the kernel configuration tool will select one for you,
36		usually an 8x16 font.
37
38		GOTCHA: A common bug report is enabling the framebuffer without enabling the
39		framebuffer console. Depending on the driver, you may get a blanked or
40		garbled display, but the system still boots to completion. If you are
41		fortunate to have a driver that does not alter the graphics chip, then you
42		will still get a VGA console.
43
44		B. Loading
45
46		Possible scenarios:
47
48		1. Driver and fbcon are compiled statically
49
50		Usually, fbcon will automatically take over your console. The notable
51		exception is vesafb. It needs to be explicitly activated with the
52		vga= boot option parameter.
53
54		2. Driver is compiled statically, fbcon is compiled as a module
55
56		Depending on the driver, you either get a standard console, or a
57		garbled display, as mentioned above. To get a framebuffer console,
58		do a 'modprobe fbcon'.
59
60		3. Driver is compiled as a module, fbcon is compiled statically
61
62		You get your standard console. Once the driver is loaded with
63		'modprobe xxxfb', fbcon automatically takes over the console with
64		the possible exception of using the fbcon=map:n option. See below.
65
66		4. Driver and fbcon are compiled as a module.
67
68		You can load them in any order. Once both are loaded, fbcon will take
69		over the console.
70
71		C. Boot options
72
73		The framebuffer console has several, largely unknown, boot options
74		that can change its behavior.
75
76		1. fbcon=font:<name>
77
78		Select the initial font to use. The value 'name' can be any of the
79		compiled-in fonts: VGA8x16, 7x14, 10x18, VGA8x8, MINI4x6, RomanLarge,
80		SUN8x16, SUN12x22, ProFont6x11, Acorn8x8, PEARL8x8.
81
82		Note, not all drivers can handle font with widths not divisible by 8,
83		such as vga16fb.
84
85		2. fbcon=scrollback:<value>[k]
86
87		The scrollback buffer is memory that is used to preserve display
88		contents that has already scrolled past your view. This is accessed
89		by using the Shift-PageUp key combination. The value 'value' is any
90		integer. It defaults to 32KB. The 'k' suffix is optional, and will
91		multiply the 'value' by 1024.
92
93		3. fbcon=map:<0123>
94
95		This is an interesting option. It tells which driver gets mapped to
96		which console. The value '0123' is a sequence that gets repeated until
97		the total length is 64 which is the number of consoles available. In
98		the above example, it is expanded to 012301230123... and the mapping
99		will be:
100
101		tty \| 1 2 3 4 5 6 7 8 9 ...
102		fb \| 0 1 2 3 0 1 2 3 0 ...
103
104		('cat /proc/fb' should tell you what the fb numbers are)
105
106		One side effect that may be useful is using a map value that exceeds
107		the number of loaded fb drivers. For example, if only one driver is
108		available, fb0, adding fbcon=map:1 tells fbcon not to take over the
109		console.
110
111		Later on, when you want to map the console the to the framebuffer
112		device, you can use the con2fbmap utility.
113
114		4. fbcon=vc:<n1>-<n2>
115
116		This option tells fbcon to take over only a range of consoles as
117		specified by the values 'n1' and 'n2'. The rest of the consoles
118		outside the given range will still be controlled by the standard
119		console driver.
120
121		NOTE: For x86 machines, the standard console is the VGA console which
122		is typically located on the same video card. Thus, the consoles that
123		are controlled by the VGA console will be garbled.
124
125		4. fbcon=rotate:<n>
126
127		This option changes the orientation angle of the console display. The
128		value 'n' accepts the following:
129
130		0 - normal orientation (0 degree)
131		1 - clockwise orientation (90 degrees)
132		2 - upside down orientation (180 degrees)
133		3 - counterclockwise orientation (270 degrees)
134
135		The angle can be changed anytime afterwards by 'echoing' the same
136		numbers to any one of the 2 attributes found in
137		/sys/class/graphics/fbcon
138
139		rotate - rotate the display of the active console
140		rotate_all - rotate the display of all consoles
141
142		Console rotation will only become available if Console Rotation
143		Support is compiled in your kernel.
144
145		NOTE: This is purely console rotation. Any other applications that
146		use the framebuffer will remain at their 'normal'orientation.
147		Actually, the underlying fb driver is totally ignorant of console
148		rotation.
149
150		C. Attaching, Detaching and Unloading
151
152		Before going on how to attach, detach and unload the framebuffer console, an
153		illustration of the dependencies may help.
154
155		The console layer, as with most subsystems, needs a driver that interfaces with
156		the hardware. Thus, in a VGA console:
157
158		console ---> VGA driver ---> hardware.
159
160		Assuming the VGA driver can be unloaded, one must first unbind the VGA driver
161		from the console layer before unloading the driver. The VGA driver cannot be
162		unloaded if it is still bound to the console layer. (See
163		Documentation/console/console.txt for more information).
164
165		This is more complicated in the case of the framebuffer console (fbcon),
166		because fbcon is an intermediate layer between the console and the drivers:
167
168		console ---> fbcon ---> fbdev drivers ---> hardware
169
170		The fbdev drivers cannot be unloaded if it's bound to fbcon, and fbcon cannot
171		be unloaded if it's bound to the console layer.
172
173		So to unload the fbdev drivers, one must first unbind fbcon from the console,
174		then unbind the fbdev drivers from fbcon. Fortunately, unbinding fbcon from
175		the console layer will automatically unbind framebuffer drivers from
176		fbcon. Thus, there is no need to explicitly unbind the fbdev drivers from
177		fbcon.
178
179		So, how do we unbind fbcon from the console? Part of the answer is in
180		Documentation/console/console.txt. To summarize:
181
182		Echo a value to the bind file that represents the framebuffer console
183		driver. So assuming vtcon1 represents fbcon, then:
184
185		echo 1 > sys/class/vtconsole/vtcon1/bind - attach framebuffer console to
186		console layer
187		echo 0 > sys/class/vtconsole/vtcon1/bind - detach framebuffer console from
188		console layer
189
190		If fbcon is detached from the console layer, your boot console driver (which is
191		usually VGA text mode) will take over. A few drivers (rivafb and i810fb) will
192		restore VGA text mode for you. With the rest, before detaching fbcon, you
193		must take a few additional steps to make sure that your VGA text mode is
194		restored properly. The following is one of the several methods that you can do:
195
196		1. Download or install vbetool. This utility is included with most
197		distributions nowadays, and is usually part of the suspend/resume tool.
198
199		2. In your kernel configuration, ensure that CONFIG_FRAMEBUFFER_CONSOLE is set
200		to 'y' or 'm'. Enable one or more of your favorite framebuffer drivers.
201
202		3. Boot into text mode and as root run:
203
204		vbetool vbestate save > <vga state file>
205
206		The above command saves the register contents of your graphics
207		hardware to <vga state file>. You need to do this step only once as
208		the state file can be reused.
209
210		4. If fbcon is compiled as a module, load fbcon by doing:
211
212		modprobe fbcon
213
214		5. Now to detach fbcon:
215
216		vbetool vbestate restore < <vga state file> && \
217		echo 0 > /sys/class/vtconsole/vtcon1/bind
218
219		6. That's it, you're back to VGA mode. And if you compiled fbcon as a module,
220		you can unload it by 'rmmod fbcon'
221
222		7. To reattach fbcon:
223
224		echo 1 > /sys/class/vtconsole/vtcon1/bind
225
226		8. Once fbcon is unbound, all drivers registered to the system will also
227		become unbound. This means that fbcon and individual framebuffer drivers
228		can be unloaded or reloaded at will. Reloading the drivers or fbcon will
229		automatically bind the console, fbcon and the drivers together. Unloading
230		all the drivers without unloading fbcon will make it impossible for the
231		console to bind fbcon.
232
233		Notes for vesafb users:
234		=======================
235
236		Unfortunately, if your bootline includes a vga=xxx parameter that sets the
237		hardware in graphics mode, such as when loading vesafb, vgacon will not load.
238		Instead, vgacon will replace the default boot console with dummycon, and you
239		won't get any display after detaching fbcon. Your machine is still alive, so
240		you can reattach vesafb. However, to reattach vesafb, you need to do one of
241		the following:
242
243		Variation 1:
244
245		a. Before detaching fbcon, do
246
247		vbetool vbemode save > <vesa state file> # do once for each vesafb mode,
248		# the file can be reused
249
250		b. Detach fbcon as in step 5.
251
252		c. Attach fbcon
253
254		vbetool vbestate restore < <vesa state file> && \
255		echo 1 > /sys/class/vtconsole/vtcon1/bind
256
257		Variation 2:
258
259		a. Before detaching fbcon, do:
260		echo <ID> > /sys/class/tty/console/bind
261
262
263		vbetool vbemode get
264
265		b. Take note of the mode number
266
267		b. Detach fbcon as in step 5.
268
269		c. Attach fbcon:
270
271		vbetool vbemode set <mode number> && \
272		echo 1 > /sys/class/vtconsole/vtcon1/bind
273
274		Samples:
275		========
276
277		Here are 2 sample bash scripts that you can use to bind or unbind the
278		framebuffer console driver if you are in an X86 box:
279
280		---------------------------------------------------------------------------
281		#!/bin/bash
282		# Unbind fbcon
283
284		# Change this to where your actual vgastate file is located
285		# Or Use VGASTATE=$1 to indicate the state file at runtime
286		VGASTATE=/tmp/vgastate
287
288		# path to vbetool
289		VBETOOL=/usr/local/bin
290
291
292		for (( i = 0; i < 16; i++))
293		do
294		if test -x /sys/class/vtconsole/vtcon$i; then
295		if [ `cat /sys/class/vtconsole/vtcon$i/name \| grep -c "frame buffer"` \
296		= 1 ]; then
297		if test -x $VBETOOL/vbetool; then
298		echo Unbinding vtcon$i
299		$VBETOOL/vbetool vbestate restore < $VGASTATE
300		echo 0 > /sys/class/vtconsole/vtcon$i/bind
301		fi
302		fi
303		fi
304		done
305
306		---------------------------------------------------------------------------
307		#!/bin/bash
308		# Bind fbcon
309
310		for (( i = 0; i < 16; i++))
311		do
312		if test -x /sys/class/vtconsole/vtcon$i; then
313		if [ `cat /sys/class/vtconsole/vtcon$i/name \| grep -c "frame buffer"` \
314		= 1 ]; then
315		echo Unbinding vtcon$i
316		echo 1 > /sys/class/vtconsole/vtcon$i/bind
317		fi
318		fi
319		done
320		---------------------------------------------------------------------------
321
322		--
323		Antonino Daplas <adaplas@pol.net>

+353

-0

debian/doc/kernel-doc/framebuffer.rst less more

	0	=======================
	1	The Frame Buffer Device
	2	=======================
	3
	4	Last revised: May 10, 2001
	5
	6
	7	0. Introduction
	8	---------------
	9
	10	The frame buffer device provides an abstraction for the graphics hardware. It
	11	represents the frame buffer of some video hardware and allows application
	12	software to access the graphics hardware through a well-defined interface, so
	13	the software doesn't need to know anything about the low-level (hardware
	14	register) stuff.
	15
	16	The device is accessed through special device nodes, usually located in the
	17	/dev directory, i.e. /dev/fb*.
	18
	19
	20	1. User's View of /dev/fb*
	21	--------------------------
	22
	23	From the user's point of view, the frame buffer device looks just like any
	24	other device in /dev. It's a character device using major 29; the minor
	25	specifies the frame buffer number.
	26
	27	By convention, the following device nodes are used (numbers indicate the device
	28	minor numbers)::
	29
	30	0 = /dev/fb0 First frame buffer
	31	1 = /dev/fb1 Second frame buffer
	32	...
	33	31 = /dev/fb31 32nd frame buffer
	34
	35	For backwards compatibility, you may want to create the following symbolic
	36	links::
	37
	38	/dev/fb0current -> fb0
	39	/dev/fb1current -> fb1
	40
	41	and so on...
	42
	43	The frame buffer devices are also `normal` memory devices, this means, you can
	44	read and write their contents. You can, for example, make a screen snapshot by::
	45
	46	cp /dev/fb0 myfile
	47
	48	There also can be more than one frame buffer at a time, e.g. if you have a
	49	graphics card in addition to the built-in hardware. The corresponding frame
	50	buffer devices (/dev/fb0 and /dev/fb1 etc.) work independently.
	51
	52	Application software that uses the frame buffer device (e.g. the X server) will
	53	use /dev/fb0 by default (older software uses /dev/fb0current). You can specify
	54	an alternative frame buffer device by setting the environment variable
	55	$FRAMEBUFFER to the path name of a frame buffer device, e.g. (for sh/bash
	56	users)::
	57
	58	export FRAMEBUFFER=/dev/fb1
	59
	60	or (for csh users)::
	61
	62	setenv FRAMEBUFFER /dev/fb1
	63
	64	After this the X server will use the second frame buffer.
	65
	66
	67	2. Programmer's View of /dev/fb*
	68	--------------------------------
	69
	70	As you already know, a frame buffer device is a memory device like /dev/mem and
	71	it has the same features. You can read it, write it, seek to some location in
	72	it and mmap() it (the main usage). The difference is just that the memory that
	73	appears in the special file is not the whole memory, but the frame buffer of
	74	some video hardware.
	75
	76	/dev/fb* also allows several ioctls on it, by which lots of information about
	77	the hardware can be queried and set. The color map handling works via ioctls,
	78	too. Look into <linux/fb.h> for more information on what ioctls exist and on
	79	which data structures they work. Here's just a brief overview:
	80
	81	- You can request unchangeable information about the hardware, like name,
	82	organization of the screen memory (planes, packed pixels, ...) and address
	83	and length of the screen memory.
	84
	85	- You can request and change variable information about the hardware, like
	86	visible and virtual geometry, depth, color map format, timing, and so on.
	87	If you try to change that information, the driver maybe will round up some
	88	values to meet the hardware's capabilities (or return EINVAL if that isn't
	89	possible).
	90
	91	- You can get and set parts of the color map. Communication is done with 16
	92	bits per color part (red, green, blue, transparency) to support all
	93	existing hardware. The driver does all the computations needed to apply
	94	it to the hardware (round it down to less bits, maybe throw away
	95	transparency).
	96
	97	All this hardware abstraction makes the implementation of application programs
	98	easier and more portable. E.g. the X server works completely on /dev/fb* and
	99	thus doesn't need to know, for example, how the color registers of the concrete
	100	hardware are organized. XF68_FBDev is a general X server for bitmapped,
	101	unaccelerated video hardware. The only thing that has to be built into
	102	application programs is the screen organization (bitplanes or chunky pixels
	103	etc.), because it works on the frame buffer image data directly.
	104
	105	For the future it is planned that frame buffer drivers for graphics cards and
	106	the like can be implemented as kernel modules that are loaded at runtime. Such
	107	a driver just has to call register_framebuffer() and supply some functions.
	108	Writing and distributing such drivers independently from the kernel will save
	109	much trouble...
	110
	111
	112	3. Frame Buffer Resolution Maintenance
	113	--------------------------------------
	114
	115	Frame buffer resolutions are maintained using the utility `fbset`. It can
	116	change the video mode properties of a frame buffer device. Its main usage is
	117	to change the current video mode, e.g. during boot up in one of your `/etc/rc.*`
	118	or `/etc/init.d/*` files.
	119
	120	Fbset uses a video mode database stored in a configuration file, so you can
	121	easily add your own modes and refer to them with a simple identifier.
	122
	123
	124	4. The X Server
	125	---------------
	126
	127	The X server (XF68_FBDev) is the most notable application program for the frame
	128	buffer device. Starting with XFree86 release 3.2, the X server is part of
	129	XFree86 and has 2 modes:
	130
	131	- If the `Display` subsection for the `fbdev` driver in the /etc/XF86Config
	132	file contains a::
	133
	134	Modes "default"
	135
	136	line, the X server will use the scheme discussed above, i.e. it will start
	137	up in the resolution determined by /dev/fb0 (or $FRAMEBUFFER, if set). You
	138	still have to specify the color depth (using the Depth keyword) and virtual
	139	resolution (using the Virtual keyword) though. This is the default for the
	140	configuration file supplied with XFree86. It's the most simple
	141	configuration, but it has some limitations.
	142
	143	- Therefore it's also possible to specify resolutions in the /etc/XF86Config
	144	file. This allows for on-the-fly resolution switching while retaining the
	145	same virtual desktop size. The frame buffer device that's used is still
	146	/dev/fb0current (or $FRAMEBUFFER), but the available resolutions are
	147	defined by /etc/XF86Config now. The disadvantage is that you have to
	148	specify the timings in a different format (but `fbset -x` may help).
	149
	150	To tune a video mode, you can use fbset or xvidtune. Note that xvidtune doesn't
	151	work 100% with XF68_FBDev: the reported clock values are always incorrect.
	152
	153
	154	5. Video Mode Timings
	155	---------------------
	156
	157	A monitor draws an image on the screen by using an electron beam (3 electron
	158	beams for color models, 1 electron beam for monochrome monitors). The front of
	159	the screen is covered by a pattern of colored phosphors (pixels). If a phosphor
	160	is hit by an electron, it emits a photon and thus becomes visible.
	161
	162	The electron beam draws horizontal lines (scanlines) from left to right, and
	163	from the top to the bottom of the screen. By modifying the intensity of the
	164	electron beam, pixels with various colors and intensities can be shown.
	165
	166	After each scanline the electron beam has to move back to the left side of the
	167	screen and to the next line: this is called the horizontal retrace. After the
	168	whole screen (frame) was painted, the beam moves back to the upper left corner:
	169	this is called the vertical retrace. During both the horizontal and vertical
	170	retrace, the electron beam is turned off (blanked).
	171
	172	The speed at which the electron beam paints the pixels is determined by the
	173	dotclock in the graphics board. For a dotclock of e.g. 28.37516 MHz (millions
	174	of cycles per second), each pixel is 35242 ps (picoseconds) long::
	175
	176	1/(28.37516E6 Hz) = 35.242E-9 s
	177
	178	If the screen resolution is 640x480, it will take::
	179
	180	640*35.242E-9 s = 22.555E-6 s
	181
	182	to paint the 640 (xres) pixels on one scanline. But the horizontal retrace
	183	also takes time (e.g. 272 `pixels`), so a full scanline takes::
	184
	185	(640+272)*35.242E-9 s = 32.141E-6 s
	186
	187	We'll say that the horizontal scanrate is about 31 kHz::
	188
	189	1/(32.141E-6 s) = 31.113E3 Hz
	190
	191	A full screen counts 480 (yres) lines, but we have to consider the vertical
	192	retrace too (e.g. 49 `lines`). So a full screen will take::
	193
	194	(480+49)*32.141E-6 s = 17.002E-3 s
	195
	196	The vertical scanrate is about 59 Hz::
	197
	198	1/(17.002E-3 s) = 58.815 Hz
	199
	200	This means the screen data is refreshed about 59 times per second. To have a
	201	stable picture without visible flicker, VESA recommends a vertical scanrate of
	202	at least 72 Hz. But the perceived flicker is very human dependent: some people
	203	can use 50 Hz without any trouble, while I'll notice if it's less than 80 Hz.
	204
	205	Since the monitor doesn't know when a new scanline starts, the graphics board
	206	will supply a synchronization pulse (horizontal sync or hsync) for each
	207	scanline. Similarly it supplies a synchronization pulse (vertical sync or
	208	vsync) for each new frame. The position of the image on the screen is
	209	influenced by the moments at which the synchronization pulses occur.
	210
	211	The following picture summarizes all timings. The horizontal retrace time is
	212	the sum of the left margin, the right margin and the hsync length, while the
	213	vertical retrace time is the sum of the upper margin, the lower margin and the
	214	vsync length::
	215
	216	+----------+---------------------------------------------+----------+-------+
	217	\| \| ↑ \| \| \|
	218	\| \| \|upper_margin \| \| \|
	219	\| \| ↓ \| \| \|
	220	+----------###############################################----------+-------+
	221	\| # ↑ # \| \|
	222	\| # \| # \| \|
	223	\| # \| # \| \|
	224	\| # \| # \| \|
	225	\| left # \| # right \| hsync \|
	226	\| margin # \| xres # margin \| len \|
	227	\|<-------->#<---------------+--------------------------->#<-------->\|<----->\|
	228	\| # \| # \| \|
	229	\| # \| # \| \|
	230	\| # \| # \| \|
	231	\| # \|yres # \| \|
	232	\| # \| # \| \|
	233	\| # \| # \| \|
	234	\| # \| # \| \|
	235	\| # \| # \| \|
	236	\| # \| # \| \|
	237	\| # \| # \| \|
	238	\| # \| # \| \|
	239	\| # \| # \| \|
	240	\| # ↓ # \| \|
	241	+----------###############################################----------+-------+
	242	\| \| ↑ \| \| \|
	243	\| \| \|lower_margin \| \| \|
	244	\| \| ↓ \| \| \|
	245	+----------+---------------------------------------------+----------+-------+
	246	\| \| ↑ \| \| \|
	247	\| \| \|vsync_len \| \| \|
	248	\| \| ↓ \| \| \|
	249	+----------+---------------------------------------------+----------+-------+
	250
	251	The frame buffer device expects all horizontal timings in number of dotclocks
	252	(in picoseconds, 1E-12 s), and vertical timings in number of scanlines.
	253
	254
	255	6. Converting XFree86 timing values info frame buffer device timings
	256	--------------------------------------------------------------------
	257
	258	An XFree86 mode line consists of the following fields::
	259
	260	"800x600" 50 800 856 976 1040 600 637 643 666
	261	< name > DCF HR SH1 SH2 HFL VR SV1 SV2 VFL
	262
	263	The frame buffer device uses the following fields:
	264
	265	- pixclock: pixel clock in ps (pico seconds)
	266	- left_margin: time from sync to picture
	267	- right_margin: time from picture to sync
	268	- upper_margin: time from sync to picture
	269	- lower_margin: time from picture to sync
	270	- hsync_len: length of horizontal sync
	271	- vsync_len: length of vertical sync
	272
	273	1) Pixelclock:
	274
	275	xfree: in MHz
	276
	277	fb: in picoseconds (ps)
	278
	279	pixclock = 1000000 / DCF
	280
	281	2) horizontal timings:
	282
	283	left_margin = HFL - SH2
	284
	285	right_margin = SH1 - HR
	286
	287	hsync_len = SH2 - SH1
	288
	289	3) vertical timings:
	290
	291	upper_margin = VFL - SV2
	292
	293	lower_margin = SV1 - VR
	294
	295	vsync_len = SV2 - SV1
	296
	297	Good examples for VESA timings can be found in the XFree86 source tree,
	298	under "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt".
	299
	300
	301	7. References
	302	-------------
	303
	304	For more specific information about the frame buffer device and its
	305	applications, please refer to the Linux-fbdev website:
	306
	307	http://linux-fbdev.sourceforge.net/
	308
	309	and to the following documentation:
	310
	311	- The manual pages for fbset: fbset(8), fb.modes(5)
	312	- The manual pages for XFree86: XF68_FBDev(1), XF86Config(4/5)
	313	- The mighty kernel sources:
	314
	315	- linux/drivers/video/
	316	- linux/include/linux/fb.h
	317	- linux/include/video/
	318
	319
	320
	321	8. Mailing list
	322	---------------
	323
	324	There is a frame buffer device related mailing list at kernel.org:
	325	linux-fbdev@vger.kernel.org.
	326
	327	Point your web browser to http://sourceforge.net/projects/linux-fbdev/ for
	328	subscription information and archive browsing.
	329
	330
	331	9. Downloading
	332	--------------
	333
	334	All necessary files can be found at
	335
	336	ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/680x0/
	337
	338	and on its mirrors.
	339
	340	The latest version of fbset can be found at
	341
	342	http://www.linux-fbdev.org/
	343
	344
	345	10. Credits
	346	-----------
	347
	348	This readme was written by Geert Uytterhoeven, partly based on the original
	349	`X-framebuffer.README` by Roman Hodek and Martin Schaller. Section 6 was
	350	provided by Frank Neumann.
	351
	352	The frame buffer device abstraction was designed by Martin Schaller.

-343

~~debian/doc/kernel-doc/framebuffer.txt~~ less more

0		The Frame Buffer Device
1		-----------------------
2
3		Maintained by Geert Uytterhoeven <geert@linux-m68k.org>
4		Last revised: May 10, 2001
5
6
7		0. Introduction
8		---------------
9
10		The frame buffer device provides an abstraction for the graphics hardware. It
11		represents the frame buffer of some video hardware and allows application
12		software to access the graphics hardware through a well-defined interface, so
13		the software doesn't need to know anything about the low-level (hardware
14		register) stuff.
15
16		The device is accessed through special device nodes, usually located in the
17		/dev directory, i.e. /dev/fb*.
18
19
20		1. User's View of /dev/fb*
21		--------------------------
22
23		From the user's point of view, the frame buffer device looks just like any
24		other device in /dev. It's a character device using major 29; the minor
25		specifies the frame buffer number.
26
27		By convention, the following device nodes are used (numbers indicate the device
28		minor numbers):
29
30		0 = /dev/fb0 First frame buffer
31		1 = /dev/fb1 Second frame buffer
32		...
33		31 = /dev/fb31 32nd frame buffer
34
35		For backwards compatibility, you may want to create the following symbolic
36		links:
37
38		/dev/fb0current -> fb0
39		/dev/fb1current -> fb1
40
41		and so on...
42
43		The frame buffer devices are also `normal' memory devices, this means, you can
44		read and write their contents. You can, for example, make a screen snapshot by
45
46		cp /dev/fb0 myfile
47
48		There also can be more than one frame buffer at a time, e.g. if you have a
49		graphics card in addition to the built-in hardware. The corresponding frame
50		buffer devices (/dev/fb0 and /dev/fb1 etc.) work independently.
51
52		Application software that uses the frame buffer device (e.g. the X server) will
53		use /dev/fb0 by default (older software uses /dev/fb0current). You can specify
54		an alternative frame buffer device by setting the environment variable
55		$FRAMEBUFFER to the path name of a frame buffer device, e.g. (for sh/bash
56		users):
57
58		export FRAMEBUFFER=/dev/fb1
59
60		or (for csh users):
61
62		setenv FRAMEBUFFER /dev/fb1
63
64		After this the X server will use the second frame buffer.
65
66
67		2. Programmer's View of /dev/fb*
68		--------------------------------
69
70		As you already know, a frame buffer device is a memory device like /dev/mem and
71		it has the same features. You can read it, write it, seek to some location in
72		it and mmap() it (the main usage). The difference is just that the memory that
73		appears in the special file is not the whole memory, but the frame buffer of
74		some video hardware.
75
76		/dev/fb* also allows several ioctls on it, by which lots of information about
77		the hardware can be queried and set. The color map handling works via ioctls,
78		too. Look into <linux/fb.h> for more information on what ioctls exist and on
79		which data structures they work. Here's just a brief overview:
80
81		- You can request unchangeable information about the hardware, like name,
82		organization of the screen memory (planes, packed pixels, ...) and address
83		and length of the screen memory.
84
85		- You can request and change variable information about the hardware, like
86		visible and virtual geometry, depth, color map format, timing, and so on.
87		If you try to change that information, the driver maybe will round up some
88		values to meet the hardware's capabilities (or return EINVAL if that isn't
89		possible).
90
91		- You can get and set parts of the color map. Communication is done with 16
92		bits per color part (red, green, blue, transparency) to support all
93		existing hardware. The driver does all the computations needed to apply
94		it to the hardware (round it down to less bits, maybe throw away
95		transparency).
96
97		All this hardware abstraction makes the implementation of application programs
98		easier and more portable. E.g. the X server works completely on /dev/fb* and
99		thus doesn't need to know, for example, how the color registers of the concrete
100		hardware are organized. XF68_FBDev is a general X server for bitmapped,
101		unaccelerated video hardware. The only thing that has to be built into
102		application programs is the screen organization (bitplanes or chunky pixels
103		etc.), because it works on the frame buffer image data directly.
104
105		For the future it is planned that frame buffer drivers for graphics cards and
106		the like can be implemented as kernel modules that are loaded at runtime. Such
107		a driver just has to call register_framebuffer() and supply some functions.
108		Writing and distributing such drivers independently from the kernel will save
109		much trouble...
110
111
112		3. Frame Buffer Resolution Maintenance
113		--------------------------------------
114
115		Frame buffer resolutions are maintained using the utility `fbset'. It can
116		change the video mode properties of a frame buffer device. Its main usage is
117		to change the current video mode, e.g. during boot up in one of your /etc/rc.*
118		or /etc/init.d/* files.
119
120		Fbset uses a video mode database stored in a configuration file, so you can
121		easily add your own modes and refer to them with a simple identifier.
122
123
124		4. The X Server
125		---------------
126
127		The X server (XF68_FBDev) is the most notable application program for the frame
128		buffer device. Starting with XFree86 release 3.2, the X server is part of
129		XFree86 and has 2 modes:
130
131		- If the `Display' subsection for the `fbdev' driver in the /etc/XF86Config
132		file contains a
133
134		Modes "default"
135
136		line, the X server will use the scheme discussed above, i.e. it will start
137		up in the resolution determined by /dev/fb0 (or $FRAMEBUFFER, if set). You
138		still have to specify the color depth (using the Depth keyword) and virtual
139		resolution (using the Virtual keyword) though. This is the default for the
140		configuration file supplied with XFree86. It's the most simple
141		configuration, but it has some limitations.
142
143		- Therefore it's also possible to specify resolutions in the /etc/XF86Config
144		file. This allows for on-the-fly resolution switching while retaining the
145		same virtual desktop size. The frame buffer device that's used is still
146		/dev/fb0current (or $FRAMEBUFFER), but the available resolutions are
147		defined by /etc/XF86Config now. The disadvantage is that you have to
148		specify the timings in a different format (but `fbset -x' may help).
149
150		To tune a video mode, you can use fbset or xvidtune. Note that xvidtune doesn't
151		work 100% with XF68_FBDev: the reported clock values are always incorrect.
152
153
154		5. Video Mode Timings
155		---------------------
156
157		A monitor draws an image on the screen by using an electron beam (3 electron
158		beams for color models, 1 electron beam for monochrome monitors). The front of
159		the screen is covered by a pattern of colored phosphors (pixels). If a phosphor
160		is hit by an electron, it emits a photon and thus becomes visible.
161
162		The electron beam draws horizontal lines (scanlines) from left to right, and
163		from the top to the bottom of the screen. By modifying the intensity of the
164		electron beam, pixels with various colors and intensities can be shown.
165
166		After each scanline the electron beam has to move back to the left side of the
167		screen and to the next line: this is called the horizontal retrace. After the
168		whole screen (frame) was painted, the beam moves back to the upper left corner:
169		this is called the vertical retrace. During both the horizontal and vertical
170		retrace, the electron beam is turned off (blanked).
171
172		The speed at which the electron beam paints the pixels is determined by the
173		dotclock in the graphics board. For a dotclock of e.g. 28.37516 MHz (millions
174		of cycles per second), each pixel is 35242 ps (picoseconds) long:
175
176		1/(28.37516E6 Hz) = 35.242E-9 s
177
178		If the screen resolution is 640x480, it will take
179
180		640*35.242E-9 s = 22.555E-6 s
181
182		to paint the 640 (xres) pixels on one scanline. But the horizontal retrace
183		also takes time (e.g. 272 `pixels'), so a full scanline takes
184
185		(640+272)*35.242E-9 s = 32.141E-6 s
186
187		We'll say that the horizontal scanrate is about 31 kHz:
188
189		1/(32.141E-6 s) = 31.113E3 Hz
190
191		A full screen counts 480 (yres) lines, but we have to consider the vertical
192		retrace too (e.g. 49 `lines'). So a full screen will take
193
194		(480+49)*32.141E-6 s = 17.002E-3 s
195
196		The vertical scanrate is about 59 Hz:
197
198		1/(17.002E-3 s) = 58.815 Hz
199
200		This means the screen data is refreshed about 59 times per second. To have a
201		stable picture without visible flicker, VESA recommends a vertical scanrate of
202		at least 72 Hz. But the perceived flicker is very human dependent: some people
203		can use 50 Hz without any trouble, while I'll notice if it's less than 80 Hz.
204
205		Since the monitor doesn't know when a new scanline starts, the graphics board
206		will supply a synchronization pulse (horizontal sync or hsync) for each
207		scanline. Similarly it supplies a synchronization pulse (vertical sync or
208		vsync) for each new frame. The position of the image on the screen is
209		influenced by the moments at which the synchronization pulses occur.
210
211		The following picture summarizes all timings. The horizontal retrace time is
212		the sum of the left margin, the right margin and the hsync length, while the
213		vertical retrace time is the sum of the upper margin, the lower margin and the
214		vsync length.
215
216		+----------+---------------------------------------------+----------+-------+
217		\| \| ↑ \| \| \|
218		\| \| \|upper_margin \| \| \|
219		\| \| ↓ \| \| \|
220		+----------###############################################----------+-------+
221		\| # ↑ # \| \|
222		\| # \| # \| \|
223		\| # \| # \| \|
224		\| # \| # \| \|
225		\| left # \| # right \| hsync \|
226		\| margin # \| xres # margin \| len \|
227		\|<-------->#<---------------+--------------------------->#<-------->\|<----->\|
228		\| # \| # \| \|
229		\| # \| # \| \|
230		\| # \| # \| \|
231		\| # \|yres # \| \|
232		\| # \| # \| \|
233		\| # \| # \| \|
234		\| # \| # \| \|
235		\| # \| # \| \|
236		\| # \| # \| \|
237		\| # \| # \| \|
238		\| # \| # \| \|
239		\| # \| # \| \|
240		\| # ↓ # \| \|
241		+----------###############################################----------+-------+
242		\| \| ↑ \| \| \|
243		\| \| \|lower_margin \| \| \|
244		\| \| ↓ \| \| \|
245		+----------+---------------------------------------------+----------+-------+
246		\| \| ↑ \| \| \|
247		\| \| \|vsync_len \| \| \|
248		\| \| ↓ \| \| \|
249		+----------+---------------------------------------------+----------+-------+
250
251		The frame buffer device expects all horizontal timings in number of dotclocks
252		(in picoseconds, 1E-12 s), and vertical timings in number of scanlines.
253
254
255		6. Converting XFree86 timing values info frame buffer device timings
256		--------------------------------------------------------------------
257
258		An XFree86 mode line consists of the following fields:
259		"800x600" 50 800 856 976 1040 600 637 643 666
260		< name > DCF HR SH1 SH2 HFL VR SV1 SV2 VFL
261
262		The frame buffer device uses the following fields:
263
264		- pixclock: pixel clock in ps (pico seconds)
265		- left_margin: time from sync to picture
266		- right_margin: time from picture to sync
267		- upper_margin: time from sync to picture
268		- lower_margin: time from picture to sync
269		- hsync_len: length of horizontal sync
270		- vsync_len: length of vertical sync
271
272		1) Pixelclock:
273		xfree: in MHz
274		fb: in picoseconds (ps)
275
276		pixclock = 1000000 / DCF
277
278		2) horizontal timings:
279		left_margin = HFL - SH2
280		right_margin = SH1 - HR
281		hsync_len = SH2 - SH1
282
283		3) vertical timings:
284		upper_margin = VFL - SV2
285		lower_margin = SV1 - VR
286		vsync_len = SV2 - SV1
287
288		Good examples for VESA timings can be found in the XFree86 source tree,
289		under "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt".
290
291
292		7. References
293		-------------
294
295		For more specific information about the frame buffer device and its
296		applications, please refer to the Linux-fbdev website:
297
298		http://linux-fbdev.sourceforge.net/
299
300		and to the following documentation:
301
302		- The manual pages for fbset: fbset(8), fb.modes(5)
303		- The manual pages for XFree86: XF68_FBDev(1), XF86Config(4/5)
304		- The mighty kernel sources:
305		o linux/drivers/video/
306		o linux/include/linux/fb.h
307		o linux/include/video/
308
309
310
311		8. Mailing list
312		---------------
313
314		There is a frame buffer device related mailing list at kernel.org:
315		linux-fbdev@vger.kernel.org.
316
317		Point your web browser to http://sourceforge.net/projects/linux-fbdev/ for
318		subscription information and archive browsing.
319
320
321		9. Downloading
322		--------------
323
324		All necessary files can be found at
325
326		ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/680x0/
327
328		and on its mirrors.
329
330		The latest version of fbset can be found at
331
332		http://www.linux-fbdev.org/
333
334
335		10. Credits
336		----------
337
338		This readme was written by Geert Uytterhoeven, partly based on the original
339		`X-framebuffer.README' by Roman Hodek and Martin Schaller. Section 6 was
340		provided by Frank Neumann.
341
342		The frame buffer device abstraction was designed by Martin Schaller.

+54

-0

debian/doc/kernel-doc/gxfb.rst less more

	0	=============
	1	What is gxfb?
	2	=============
	3
	4	.. [This file is cloned from VesaFB/aty128fb]
	5
	6	This is a graphics framebuffer driver for AMD Geode GX2 based processors.
	7
	8	Advantages:
	9
	10	* No need to use AMD's VSA code (or other VESA emulation layer) in the
	11	BIOS.
	12	* It provides a nice large console (128 cols + 48 lines with 1024x768)
	13	without using tiny, unreadable fonts.
	14	* You can run XF68_FBDev on top of /dev/fb0
	15	* Most important: boot logo :-)
	16
	17	Disadvantages:
	18
	19	* graphic mode is slower than text mode...
	20
	21
	22	How to use it?
	23	==============
	24
	25	Switching modes is done using gxfb.mode_option=<resolution>... boot
	26	parameter or using `fbset` program.
	27
	28	See Documentation/fb/modedb.rst for more information on modedb
	29	resolutions.
	30
	31
	32	X11
	33	===
	34
	35	XF68_FBDev should generally work fine, but it is non-accelerated.
	36
	37
	38	Configuration
	39	=============
	40
	41	You can pass kernel command line options to gxfb with gxfb.<option>.
	42	For example, gxfb.mode_option=800x600@75.
	43	Accepted options:
	44
	45	================ ==================================================
	46	mode_option specify the video mode. Of the form
	47	<x>x<y>[-<bpp>][@<refresh>]
	48	vram size of video ram (normally auto-detected)
	49	vt_switch enable vt switching during suspend/resume. The vt
	50	switch is slow, but harmless.
	51	================ ==================================================
	52
	53	Andres Salomon <dilinger@debian.org>

-52

~~debian/doc/kernel-doc/gxfb.txt~~ less more

0		[This file is cloned from VesaFB/aty128fb]
1
2		What is gxfb?
3		=================
4
5		This is a graphics framebuffer driver for AMD Geode GX2 based processors.
6
7		Advantages:
8
9		* No need to use AMD's VSA code (or other VESA emulation layer) in the
10		BIOS.
11		* It provides a nice large console (128 cols + 48 lines with 1024x768)
12		without using tiny, unreadable fonts.
13		* You can run XF68_FBDev on top of /dev/fb0
14		* Most important: boot logo :-)
15
16		Disadvantages:
17
18		* graphic mode is slower than text mode...
19
20
21		How to use it?
22		==============
23
24		Switching modes is done using gxfb.mode_option=<resolution>... boot
25		parameter or using `fbset' program.
26
27		See Documentation/fb/modedb.txt for more information on modedb
28		resolutions.
29
30
31		X11
32		===
33
34		XF68_FBDev should generally work fine, but it is non-accelerated.
35
36
37		Configuration
38		=============
39
40		You can pass kernel command line options to gxfb with gxfb.<option>.
41		For example, gxfb.mode_option=800x600@75.
42		Accepted options:
43
44		mode_option - specify the video mode. Of the form
45		<x>x<y>[-<bpp>][@<refresh>]
46		vram - size of video ram (normally auto-detected)
47		vt_switch - enable vt switching during suspend/resume. The vt
48		switch is slow, but harmless.
49
50		--
51		Andres Salomon <dilinger@debian.org>

-31

~~debian/doc/kernel-doc/imacfb.txt~~ less more

0
1		What is imacfb?
2		===============
3
4		This is a generic EFI platform driver for Intel based Apple computers.
5		Imacfb is only for EFI booted Intel Macs.
6
7		Supported Hardware
8		==================
9
10		iMac 17"/20"
11		Macbook
12		Macbook Pro 15"/17"
13		MacMini
14
15		How to use it?
16		==============
17
18		Imacfb does not have any kind of autodetection of your machine.
19		You have to add the following kernel parameters in your elilo.conf:
20		Macbook :
21		video=imacfb:macbook
22		MacMini :
23		video=imacfb:mini
24		Macbook Pro 15", iMac 17" :
25		video=imacfb:i17
26		Macbook Pro 17", iMac 20" :
27		video=imacfb:i20
28
29		--
30		Edgar Hucek <gimli@dark-green.com>

+287

-0

debian/doc/kernel-doc/intel810.rst less more

	0	================================
	1	Intel 810/815 Framebuffer driver
	2	================================
	3
	4	Tony Daplas <adaplas@pol.net>
	5
	6	http://i810fb.sourceforge.net
	7
	8	March 17, 2002
	9
	10	First Released: July 2001
	11	Last Update: September 12, 2005
	12
	13	A. Introduction
	14	===============
	15
	16	This is a framebuffer driver for various Intel 810/815 compatible
	17	graphics devices. These include:
	18
	19	- Intel 810
	20	- Intel 810E
	21	- Intel 810-DC100
	22	- Intel 815 Internal graphics only, 100Mhz FSB
	23	- Intel 815 Internal graphics only
	24	- Intel 815 Internal graphics and AGP
	25
	26	B. Features
	27	============
	28
	29	- Choice of using Discrete Video Timings, VESA Generalized Timing
	30	Formula, or a framebuffer specific database to set the video mode
	31
	32	- Supports a variable range of horizontal and vertical resolution and
	33	vertical refresh rates if the VESA Generalized Timing Formula is
	34	enabled.
	35
	36	- Supports color depths of 8, 16, 24 and 32 bits per pixel
	37
	38	- Supports pseudocolor, directcolor, or truecolor visuals
	39
	40	- Full and optimized hardware acceleration at 8, 16 and 24 bpp
	41
	42	- Robust video state save and restore
	43
	44	- MTRR support
	45
	46	- Utilizes user-entered monitor specifications to automatically
	47	calculate required video mode parameters.
	48
	49	- Can concurrently run with xfree86 running with native i810 drivers
	50
	51	- Hardware Cursor Support
	52
	53	- Supports EDID probing either by DDC/I2C or through the BIOS
	54
	55	C. List of available options
	56	=============================
	57
	58	a. "video=i810fb"
	59	enables the i810 driver
	60
	61	Recommendation: required
	62
	63	b. "xres:<value>"
	64	select horizontal resolution in pixels. (This parameter will be
	65	ignored if 'mode_option' is specified. See 'o' below).
	66
	67	Recommendation: user preference
	68	(default = 640)
	69
	70	c. "yres:<value>"
	71	select vertical resolution in scanlines. If Discrete Video Timings
	72	is enabled, this will be ignored and computed as 3*xres/4. (This
	73	parameter will be ignored if 'mode_option' is specified. See 'o'
	74	below)
	75
	76	Recommendation: user preference
	77	(default = 480)
	78
	79	d. "vyres:<value>"
	80	select virtual vertical resolution in scanlines. If (0) or none
	81	is specified, this will be computed against maximum available memory.
	82
	83	Recommendation: do not set
	84	(default = 480)
	85
	86	e. "vram:<value>"
	87	select amount of system RAM in MB to allocate for the video memory
	88
	89	Recommendation: 1 - 4 MB.
	90	(default = 4)
	91
	92	f. "bpp:<value>"
	93	select desired pixel depth
	94
	95	Recommendation: 8
	96	(default = 8)
	97
	98	g. "hsync1/hsync2:<value>"
	99	select the minimum and maximum Horizontal Sync Frequency of the
	100	monitor in kHz. If using a fixed frequency monitor, hsync1 must
	101	be equal to hsync2. If EDID probing is successful, these will be
	102	ignored and values will be taken from the EDID block.
	103
	104	Recommendation: check monitor manual for correct values
	105	(default = 29/30)
	106
	107	h. "vsync1/vsync2:<value>"
	108	select the minimum and maximum Vertical Sync Frequency of the monitor
	109	in Hz. You can also use this option to lock your monitor's refresh
	110	rate. If EDID probing is successful, these will be ignored and values
	111	will be taken from the EDID block.
	112
	113	Recommendation: check monitor manual for correct values
	114	(default = 60/60)
	115
	116	IMPORTANT: If you need to clamp your timings, try to give some
	117	leeway for computational errors (over/underflows). Example: if
	118	using vsync1/vsync2 = 60/60, make sure hsync1/hsync2 has at least
	119	a 1 unit difference, and vice versa.
	120
	121	i. "voffset:<value>"
	122	select at what offset in MB of the logical memory to allocate the
	123	framebuffer memory. The intent is to avoid the memory blocks
	124	used by standard graphics applications (XFree86). The default
	125	offset (16 MB for a 64 MB aperture, 8 MB for a 32 MB aperture) will
	126	avoid XFree86's usage and allows up to 7 MB/15 MB of framebuffer
	127	memory. Depending on your usage, adjust the value up or down
	128	(0 for maximum usage, 31/63 MB for the least amount). Note, an
	129	arbitrary setting may conflict with XFree86.
	130
	131	Recommendation: do not set
	132	(default = 8 or 16 MB)
	133
	134	j. "accel"
	135	enable text acceleration. This can be enabled/reenabled anytime
	136	by using 'fbset -accel true/false'.
	137
	138	Recommendation: enable
	139	(default = not set)
	140
	141	k. "mtrr"
	142	enable MTRR. This allows data transfers to the framebuffer memory
	143	to occur in bursts which can significantly increase performance.
	144	Not very helpful with the i810/i815 because of 'shared memory'.
	145
	146	Recommendation: do not set
	147	(default = not set)
	148
	149	l. "extvga"
	150	if specified, secondary/external VGA output will always be enabled.
	151	Useful if the BIOS turns off the VGA port when no monitor is attached.
	152	The external VGA monitor can then be attached without rebooting.
	153
	154	Recommendation: do not set
	155	(default = not set)
	156
	157	m. "sync"
	158	Forces the hardware engine to do a "sync" or wait for the hardware
	159	to finish before starting another instruction. This will produce a
	160	more stable setup, but will be slower.
	161
	162	Recommendation: do not set
	163	(default = not set)
	164
	165	n. "dcolor"
	166	Use directcolor visual instead of truecolor for pixel depths greater
	167	than 8 bpp. Useful for color tuning, such as gamma control.
	168
	169	Recommendation: do not set
	170	(default = not set)
	171
	172	o. <xres>x<yres>[-<bpp>][@<refresh>]
	173	The driver will now accept specification of boot mode option. If this
	174	is specified, the options 'xres' and 'yres' will be ignored. See
	175	Documentation/fb/modedb.rst for usage.
	176
	177	D. Kernel booting
	178	=================
	179
	180	Separate each option/option-pair by commas (,) and the option from its value
	181	with a colon (:) as in the following::
	182
	183	video=i810fb:option1,option2:value2
	184
	185	Sample Usage
	186	------------
	187
	188	In /etc/lilo.conf, add the line::
	189
	190	append="video=i810fb:vram:2,xres:1024,yres:768,bpp:8,hsync1:30,hsync2:55, \
	191	vsync1:50,vsync2:85,accel,mtrr"
	192
	193	This will initialize the framebuffer to 1024x768 at 8bpp. The framebuffer
	194	will use 2 MB of System RAM. MTRR support will be enabled. The refresh rate
	195	will be computed based on the hsync1/hsync2 and vsync1/vsync2 values.
	196
	197	IMPORTANT:
	198	You must include hsync1, hsync2, vsync1 and vsync2 to enable video modes
	199	better than 640x480 at 60Hz. HOWEVER, if your chipset/display combination
	200	supports I2C and has an EDID block, you can safely exclude hsync1, hsync2,
	201	vsync1 and vsync2 parameters. These parameters will be taken from the EDID
	202	block.
	203
	204	E. Module options
	205	==================
	206
	207	The module parameters are essentially similar to the kernel
	208	parameters. The main difference is that you need to include a Boolean value
	209	(1 for TRUE, and 0 for FALSE) for those options which don't need a value.
	210
	211	Example, to enable MTRR, include "mtrr=1".
	212
	213	Sample Usage
	214	------------
	215
	216	Using the same setup as described above, load the module like this::
	217
	218	modprobe i810fb vram=2 xres=1024 bpp=8 hsync1=30 hsync2=55 vsync1=50 \
	219	vsync2=85 accel=1 mtrr=1
	220
	221	Or just add the following to a configuration file in /etc/modprobe.d/::
	222
	223	options i810fb vram=2 xres=1024 bpp=16 hsync1=30 hsync2=55 vsync1=50 \
	224	vsync2=85 accel=1 mtrr=1
	225
	226	and just do a::
	227
	228	modprobe i810fb
	229
	230
	231	F. Setup
	232	=========
	233
	234	a. Do your usual method of configuring the kernel
	235
	236	make menuconfig/xconfig/config
	237
	238	b. Under "Code maturity level options" enable "Prompt for development
	239	and/or incomplete code/drivers".
	240
	241	c. Enable agpgart support for the Intel 810/815 on-board graphics.
	242	This is required. The option is under "Character Devices".
	243
	244	d. Under "Graphics Support", select "Intel 810/815" either statically
	245	or as a module. Choose "use VESA Generalized Timing Formula" if
	246	you need to maximize the capability of your display. To be on the
	247	safe side, you can leave this unselected.
	248
	249	e. If you want support for DDC/I2C probing (Plug and Play Displays),
	250	set 'Enable DDC Support' to 'y'. To make this option appear, set
	251	'use VESA Generalized Timing Formula' to 'y'.
	252
	253	f. If you want a framebuffer console, enable it under "Console
	254	Drivers".
	255
	256	g. Compile your kernel.
	257
	258	h. Load the driver as described in sections D and E.
	259
	260	i. Try the DirectFB (http://www.directfb.org) + the i810 gfxdriver
	261	patch to see the chipset in action (or inaction :-).
	262
	263	G. Acknowledgment:
	264	===================
	265
	266	1. Geert Uytterhoeven - his excellent howto and the virtual
	267	framebuffer driver code made this possible.
	268
	269	2. Jeff Hartmann for his agpgart code.
	270
	271	3. The X developers. Insights were provided just by reading the
	272	XFree86 source code.
	273
	274	4. Intel(c). For this value-oriented chipset driver and for
	275	providing documentation.
	276
	277	5. Matt Sottek. His inputs and ideas helped in making some
	278	optimizations possible.
	279
	280	H. Home Page:
	281	==============
	282
	283	A more complete, and probably updated information is provided at
	284	http://i810fb.sourceforge.net.
	285
	286	Tony

-278

~~debian/doc/kernel-doc/intel810.txt~~ less more

0		Intel 810/815 Framebuffer driver
1		Tony Daplas <adaplas@pol.net>
2		http://i810fb.sourceforge.net
3
4		March 17, 2002
5
6		First Released: July 2001
7		Last Update: September 12, 2005
8		================================================================
9
10		A. Introduction
11
12		This is a framebuffer driver for various Intel 810/815 compatible
13		graphics devices. These include:
14
15		Intel 810
16		Intel 810E
17		Intel 810-DC100
18		Intel 815 Internal graphics only, 100Mhz FSB
19		Intel 815 Internal graphics only
20		Intel 815 Internal graphics and AGP
21
22		B. Features
23
24		- Choice of using Discrete Video Timings, VESA Generalized Timing
25		Formula, or a framebuffer specific database to set the video mode
26
27		- Supports a variable range of horizontal and vertical resolution and
28		vertical refresh rates if the VESA Generalized Timing Formula is
29		enabled.
30
31		- Supports color depths of 8, 16, 24 and 32 bits per pixel
32
33		- Supports pseudocolor, directcolor, or truecolor visuals
34
35		- Full and optimized hardware acceleration at 8, 16 and 24 bpp
36
37		- Robust video state save and restore
38
39		- MTRR support
40
41		- Utilizes user-entered monitor specifications to automatically
42		calculate required video mode parameters.
43
44		- Can concurrently run with xfree86 running with native i810 drivers
45
46		- Hardware Cursor Support
47
48		- Supports EDID probing either by DDC/I2C or through the BIOS
49
50		C. List of available options
51
52		a. "video=i810fb"
53		enables the i810 driver
54
55		Recommendation: required
56
57		b. "xres:<value>"
58		select horizontal resolution in pixels. (This parameter will be
59		ignored if 'mode_option' is specified. See 'o' below).
60
61		Recommendation: user preference
62		(default = 640)
63
64		c. "yres:<value>"
65		select vertical resolution in scanlines. If Discrete Video Timings
66		is enabled, this will be ignored and computed as 3*xres/4. (This
67		parameter will be ignored if 'mode_option' is specified. See 'o'
68		below)
69
70		Recommendation: user preference
71		(default = 480)
72
73		d. "vyres:<value>"
74		select virtual vertical resolution in scanlines. If (0) or none
75		is specified, this will be computed against maximum available memory.
76
77		Recommendation: do not set
78		(default = 480)
79
80		e. "vram:<value>"
81		select amount of system RAM in MB to allocate for the video memory
82
83		Recommendation: 1 - 4 MB.
84		(default = 4)
85
86		f. "bpp:<value>"
87		select desired pixel depth
88
89		Recommendation: 8
90		(default = 8)
91
92		g. "hsync1/hsync2:<value>"
93		select the minimum and maximum Horizontal Sync Frequency of the
94		monitor in kHz. If using a fixed frequency monitor, hsync1 must
95		be equal to hsync2. If EDID probing is successful, these will be
96		ignored and values will be taken from the EDID block.
97
98		Recommendation: check monitor manual for correct values
99		(default = 29/30)
100
101		h. "vsync1/vsync2:<value>"
102		select the minimum and maximum Vertical Sync Frequency of the monitor
103		in Hz. You can also use this option to lock your monitor's refresh
104		rate. If EDID probing is successful, these will be ignored and values
105		will be taken from the EDID block.
106
107		Recommendation: check monitor manual for correct values
108		(default = 60/60)
109
110		IMPORTANT: If you need to clamp your timings, try to give some
111		leeway for computational errors (over/underflows). Example: if
112		using vsync1/vsync2 = 60/60, make sure hsync1/hsync2 has at least
113		a 1 unit difference, and vice versa.
114
115		i. "voffset:<value>"
116		select at what offset in MB of the logical memory to allocate the
117		framebuffer memory. The intent is to avoid the memory blocks
118		used by standard graphics applications (XFree86). The default
119		offset (16 MB for a 64 MB aperture, 8 MB for a 32 MB aperture) will
120		avoid XFree86's usage and allows up to 7 MB/15 MB of framebuffer
121		memory. Depending on your usage, adjust the value up or down
122		(0 for maximum usage, 31/63 MB for the least amount). Note, an
123		arbitrary setting may conflict with XFree86.
124
125		Recommendation: do not set
126		(default = 8 or 16 MB)
127
128		j. "accel"
129		enable text acceleration. This can be enabled/reenabled anytime
130		by using 'fbset -accel true/false'.
131
132		Recommendation: enable
133		(default = not set)
134
135		k. "mtrr"
136		enable MTRR. This allows data transfers to the framebuffer memory
137		to occur in bursts which can significantly increase performance.
138		Not very helpful with the i810/i815 because of 'shared memory'.
139
140		Recommendation: do not set
141		(default = not set)
142
143		l. "extvga"
144		if specified, secondary/external VGA output will always be enabled.
145		Useful if the BIOS turns off the VGA port when no monitor is attached.
146		The external VGA monitor can then be attached without rebooting.
147
148		Recommendation: do not set
149		(default = not set)
150
151		m. "sync"
152		Forces the hardware engine to do a "sync" or wait for the hardware
153		to finish before starting another instruction. This will produce a
154		more stable setup, but will be slower.
155
156		Recommendation: do not set
157		(default = not set)
158
159		n. "dcolor"
160		Use directcolor visual instead of truecolor for pixel depths greater
161		than 8 bpp. Useful for color tuning, such as gamma control.
162
163		Recommendation: do not set
164		(default = not set)
165
166		o. <xres>x<yres>[-<bpp>][@<refresh>]
167		The driver will now accept specification of boot mode option. If this
168		is specified, the options 'xres' and 'yres' will be ignored. See
169		Documentation/fb/modedb.txt for usage.
170
171		D. Kernel booting
172
173		Separate each option/option-pair by commas (,) and the option from its value
174		with a colon (:) as in the following:
175
176		video=i810fb:option1,option2:value2
177
178		Sample Usage
179		------------
180
181		In /etc/lilo.conf, add the line:
182
183		append="video=i810fb:vram:2,xres:1024,yres:768,bpp:8,hsync1:30,hsync2:55, \
184		vsync1:50,vsync2:85,accel,mtrr"
185
186		This will initialize the framebuffer to 1024x768 at 8bpp. The framebuffer
187		will use 2 MB of System RAM. MTRR support will be enabled. The refresh rate
188		will be computed based on the hsync1/hsync2 and vsync1/vsync2 values.
189
190		IMPORTANT:
191		You must include hsync1, hsync2, vsync1 and vsync2 to enable video modes
192		better than 640x480 at 60Hz. HOWEVER, if your chipset/display combination
193		supports I2C and has an EDID block, you can safely exclude hsync1, hsync2,
194		vsync1 and vsync2 parameters. These parameters will be taken from the EDID
195		block.
196
197		E. Module options
198
199		The module parameters are essentially similar to the kernel
200		parameters. The main difference is that you need to include a Boolean value
201		(1 for TRUE, and 0 for FALSE) for those options which don't need a value.
202
203		Example, to enable MTRR, include "mtrr=1".
204
205		Sample Usage
206		------------
207
208		Using the same setup as described above, load the module like this:
209
210		modprobe i810fb vram=2 xres=1024 bpp=8 hsync1=30 hsync2=55 vsync1=50 \
211		vsync2=85 accel=1 mtrr=1
212
213		Or just add the following to a configuration file in /etc/modprobe.d/
214
215		options i810fb vram=2 xres=1024 bpp=16 hsync1=30 hsync2=55 vsync1=50 \
216		vsync2=85 accel=1 mtrr=1
217
218		and just do a
219
220		modprobe i810fb
221
222
223		F. Setup
224
225		a. Do your usual method of configuring the kernel.
226
227		make menuconfig/xconfig/config
228
229		b. Under "Code maturity level options" enable "Prompt for development
230		and/or incomplete code/drivers".
231
232		c. Enable agpgart support for the Intel 810/815 on-board graphics.
233		This is required. The option is under "Character Devices".
234
235		d. Under "Graphics Support", select "Intel 810/815" either statically
236		or as a module. Choose "use VESA Generalized Timing Formula" if
237		you need to maximize the capability of your display. To be on the
238		safe side, you can leave this unselected.
239
240		e. If you want support for DDC/I2C probing (Plug and Play Displays),
241		set 'Enable DDC Support' to 'y'. To make this option appear, set
242		'use VESA Generalized Timing Formula' to 'y'.
243
244		f. If you want a framebuffer console, enable it under "Console
245		Drivers".
246
247		g. Compile your kernel.
248
249		h. Load the driver as described in sections D and E.
250
251		i. Try the DirectFB (http://www.directfb.org) + the i810 gfxdriver
252		patch to see the chipset in action (or inaction :-).
253
254		G. Acknowledgment:
255
256		1. Geert Uytterhoeven - his excellent howto and the virtual
257		framebuffer driver code made this possible.
258
259		2. Jeff Hartmann for his agpgart code.
260
261		3. The X developers. Insights were provided just by reading the
262		XFree86 source code.
263
264		4. Intel(c). For this value-oriented chipset driver and for
265		providing documentation.
266
267		5. Matt Sottek. His inputs and ideas helped in making some
268		optimizations possible.
269
270		H. Home Page:
271
272		A more complete, and probably updated information is provided at
273		http://i810fb.sourceforge.net.
274
275		###########################
276		Tony
277

+155

-0

debian/doc/kernel-doc/intelfb.rst less more

	0	=============================================================
	1	Intel 830M/845G/852GM/855GM/865G/915G/945G Framebuffer driver
	2	=============================================================
	3
	4	A. Introduction
	5	===============
	6
	7	This is a framebuffer driver for various Intel 8xx/9xx compatible
	8	graphics devices. These would include:
	9
	10	- Intel 830M
	11	- Intel 845G
	12	- Intel 852GM
	13	- Intel 855GM
	14	- Intel 865G
	15	- Intel 915G
	16	- Intel 915GM
	17	- Intel 945G
	18	- Intel 945GM
	19	- Intel 945GME
	20	- Intel 965G
	21	- Intel 965GM
	22
	23	B. List of available options
	24	=============================
	25
	26	a. "video=intelfb"
	27	enables the intelfb driver
	28
	29	Recommendation: required
	30
	31	b. "mode=<xres>x<yres>[-<bpp>][@<refresh>]"
	32	select mode
	33
	34	Recommendation: user preference
	35	(default = 1024x768-32@70)
	36
	37	c. "vram=<value>"
	38	select amount of system RAM in MB to allocate for the video memory
	39	if not enough RAM was already allocated by the BIOS.
	40
	41	Recommendation: 1 - 4 MB.
	42	(default = 4 MB)
	43
	44	d. "voffset=<value>"
	45	select at what offset in MB of the logical memory to allocate the
	46	framebuffer memory. The intent is to avoid the memory blocks
	47	used by standard graphics applications (XFree86). Depending on your
	48	usage, adjust the value up or down, (0 for maximum usage, 63/127 MB
	49	for the least amount). Note, an arbitrary setting may conflict
	50	with XFree86.
	51
	52	Recommendation: do not set
	53	(default = 48 MB)
	54
	55	e. "accel"
	56	enable text acceleration. This can be enabled/reenabled anytime
	57	by using 'fbset -accel true/false'.
	58
	59	Recommendation: enable
	60	(default = set)
	61
	62	f. "hwcursor"
	63	enable cursor acceleration.
	64
	65	Recommendation: enable
	66	(default = set)
	67
	68	g. "mtrr"
	69	enable MTRR. This allows data transfers to the framebuffer memory
	70	to occur in bursts which can significantly increase performance.
	71	Not very helpful with the intel chips because of 'shared memory'.
	72
	73	Recommendation: set
	74	(default = set)
	75
	76	h. "fixed"
	77	disable mode switching.
	78
	79	Recommendation: do not set
	80	(default = not set)
	81
	82	The binary parameters can be unset with a "no" prefix, example "noaccel".
	83	The default parameter (not named) is the mode.
	84
	85	C. Kernel booting
	86	=================
	87
	88	Separate each option/option-pair by commas (,) and the option from its value
	89	with an equals sign (=) as in the following::
	90
	91	video=intelfb:option1,option2=value2
	92
	93	Sample Usage
	94	------------
	95
	96	In /etc/lilo.conf, add the line::
	97
	98	append="video=intelfb:mode=800x600-32@75,accel,hwcursor,vram=8"
	99
	100	This will initialize the framebuffer to 800x600 at 32bpp and 75Hz. The
	101	framebuffer will use 8 MB of System RAM. hw acceleration of text and cursor
	102	will be enabled.
	103
	104	Remarks
	105	-------
	106
	107	If setting this parameter doesn't work (you stay in a 80x25 text-mode),
	108	you might need to set the "vga=<mode>" parameter too - see vesafb.txt
	109	in this directory.
	110
	111
	112	D. Module options
	113	==================
	114
	115	The module parameters are essentially similar to the kernel
	116	parameters. The main difference is that you need to include a Boolean value
	117	(1 for TRUE, and 0 for FALSE) for those options which don't need a value.
	118
	119	Example, to enable MTRR, include "mtrr=1".
	120
	121	Sample Usage
	122	------------
	123
	124	Using the same setup as described above, load the module like this::
	125
	126	modprobe intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
	127
	128	Or just add the following to a configuration file in /etc/modprobe.d/::
	129
	130	options intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
	131
	132	and just do a::
	133
	134	modprobe intelfb
	135
	136
	137	E. Acknowledgment:
	138	===================
	139
	140	1. Geert Uytterhoeven - his excellent howto and the virtual
	141	framebuffer driver code made this possible.
	142
	143	2. Jeff Hartmann for his agpgart code.
	144
	145	3. David Dawes for his original kernel 2.4 code.
	146
	147	4. The X developers. Insights were provided just by reading the
	148	XFree86 source code.
	149
	150	5. Antonino A. Daplas for his inspiring i810fb driver.
	151
	152	6. Andrew Morton for his kernel patches maintenance.
	153
	154	Sylvain

-149

~~debian/doc/kernel-doc/intelfb.txt~~ less more

0		Intel 830M/845G/852GM/855GM/865G/915G/945G Framebuffer driver
1		================================================================
2
3		A. Introduction
4		This is a framebuffer driver for various Intel 8xx/9xx compatible
5		graphics devices. These would include:
6
7		Intel 830M
8		Intel 845G
9		Intel 852GM
10		Intel 855GM
11		Intel 865G
12		Intel 915G
13		Intel 915GM
14		Intel 945G
15		Intel 945GM
16		Intel 945GME
17		Intel 965G
18		Intel 965GM
19
20		B. List of available options
21
22		a. "video=intelfb"
23		enables the intelfb driver
24
25		Recommendation: required
26
27		b. "mode=<xres>x<yres>[-<bpp>][@<refresh>]"
28		select mode
29
30		Recommendation: user preference
31		(default = 1024x768-32@70)
32
33		c. "vram=<value>"
34		select amount of system RAM in MB to allocate for the video memory
35		if not enough RAM was already allocated by the BIOS.
36
37		Recommendation: 1 - 4 MB.
38		(default = 4 MB)
39
40		d. "voffset=<value>"
41		select at what offset in MB of the logical memory to allocate the
42		framebuffer memory. The intent is to avoid the memory blocks
43		used by standard graphics applications (XFree86). Depending on your
44		usage, adjust the value up or down, (0 for maximum usage, 63/127 MB
45		for the least amount). Note, an arbitrary setting may conflict
46		with XFree86.
47
48		Recommendation: do not set
49		(default = 48 MB)
50
51		e. "accel"
52		enable text acceleration. This can be enabled/reenabled anytime
53		by using 'fbset -accel true/false'.
54
55		Recommendation: enable
56		(default = set)
57
58		f. "hwcursor"
59		enable cursor acceleration.
60
61		Recommendation: enable
62		(default = set)
63
64		g. "mtrr"
65		enable MTRR. This allows data transfers to the framebuffer memory
66		to occur in bursts which can significantly increase performance.
67		Not very helpful with the intel chips because of 'shared memory'.
68
69		Recommendation: set
70		(default = set)
71
72		h. "fixed"
73		disable mode switching.
74
75		Recommendation: do not set
76		(default = not set)
77
78		The binary parameters can be unset with a "no" prefix, example "noaccel".
79		The default parameter (not named) is the mode.
80
81		C. Kernel booting
82
83		Separate each option/option-pair by commas (,) and the option from its value
84		with an equals sign (=) as in the following:
85
86		video=intelfb:option1,option2=value2
87
88		Sample Usage
89		------------
90
91		In /etc/lilo.conf, add the line:
92
93		append="video=intelfb:mode=800x600-32@75,accel,hwcursor,vram=8"
94
95		This will initialize the framebuffer to 800x600 at 32bpp and 75Hz. The
96		framebuffer will use 8 MB of System RAM. hw acceleration of text and cursor
97		will be enabled.
98
99		Remarks
100		-------
101
102		If setting this parameter doesn't work (you stay in a 80x25 text-mode),
103		you might need to set the "vga=<mode>" parameter too - see vesafb.txt
104		in this directory.
105
106
107		D. Module options
108
109		The module parameters are essentially similar to the kernel
110		parameters. The main difference is that you need to include a Boolean value
111		(1 for TRUE, and 0 for FALSE) for those options which don't need a value.
112
113		Example, to enable MTRR, include "mtrr=1".
114
115		Sample Usage
116		------------
117
118		Using the same setup as described above, load the module like this:
119
120		modprobe intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
121
122		Or just add the following to a configuration file in /etc/modprobe.d/
123
124		options intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
125
126		and just do a
127
128		modprobe intelfb
129
130
131		E. Acknowledgment:
132
133		1. Geert Uytterhoeven - his excellent howto and the virtual
134		framebuffer driver code made this possible.
135
136		2. Jeff Hartmann for his agpgart code.
137
138		3. David Dawes for his original kernel 2.4 code.
139
140		4. The X developers. Insights were provided just by reading the
141		XFree86 source code.
142
143		5. Antonino A. Daplas for his inspiring i810fb driver.
144
145		6. Andrew Morton for his kernel patches maintenance.
146
147		###########################
148		Sylvain

+86

-0

debian/doc/kernel-doc/internals.rst less more

	0	=============================
	1	Frame Buffer device internals
	2	=============================
	3
	4	This is a first start for some documentation about frame buffer device
	5	internals.
	6
	7	Authors:
	8
	9	- Geert Uytterhoeven <geert@linux-m68k.org>, 21 July 1998
	10	- James Simmons <jsimmons@user.sf.net>, Nov 26 2002
	11
	12	--------------------------------------------------------------------------------
	13
	14	Structures used by the frame buffer device API
	15	==============================================
	16
	17	The following structures play a role in the game of frame buffer devices. They
	18	are defined in <linux/fb.h>.
	19
	20	1. Outside the kernel (user space)
	21
	22	- struct fb_fix_screeninfo
	23
	24	Device independent unchangeable information about a frame buffer device and
	25	a specific video mode. This can be obtained using the FBIOGET_FSCREENINFO
	26	ioctl.
	27
	28	- struct fb_var_screeninfo
	29
	30	Device independent changeable information about a frame buffer device and a
	31	specific video mode. This can be obtained using the FBIOGET_VSCREENINFO
	32	ioctl, and updated with the FBIOPUT_VSCREENINFO ioctl. If you want to pan
	33	the screen only, you can use the FBIOPAN_DISPLAY ioctl.
	34
	35	- struct fb_cmap
	36
	37	Device independent colormap information. You can get and set the colormap
	38	using the FBIOGETCMAP and FBIOPUTCMAP ioctls.
	39
	40
	41	2. Inside the kernel
	42
	43	- struct fb_info
	44
	45	Generic information, API and low level information about a specific frame
	46	buffer device instance (slot number, board address, ...).
	47
	48	- struct `par`
	49
	50	Device dependent information that uniquely defines the video mode for this
	51	particular piece of hardware.
	52
	53
	54	Visuals used by the frame buffer device API
	55	===========================================
	56
	57
	58	Monochrome (FB_VISUAL_MONO01 and FB_VISUAL_MONO10)
	59	--------------------------------------------------
	60	Each pixel is either black or white.
	61
	62
	63	Pseudo color (FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR)
	64	---------------------------------------------------------------------
	65	The whole pixel value is fed through a programmable lookup table that has one
	66	color (including red, green, and blue intensities) for each possible pixel
	67	value, and that color is displayed.
	68
	69
	70	True color (FB_VISUAL_TRUECOLOR)
	71	--------------------------------
	72	The pixel value is broken up into red, green, and blue fields.
	73
	74
	75	Direct color (FB_VISUAL_DIRECTCOLOR)
	76	------------------------------------
	77	The pixel value is broken up into red, green, and blue fields, each of which
	78	are looked up in separate red, green, and blue lookup tables.
	79
	80
	81	Grayscale displays
	82	------------------
	83	Grayscale and static grayscale are special variants of pseudo color and static
	84	pseudo color, where the red, green and blue components are always equal to
	85	each other.

-82

~~debian/doc/kernel-doc/internals.txt~~ less more

0
1		This is a first start for some documentation about frame buffer device
2		internals.
3
4		Geert Uytterhoeven <geert@linux-m68k.org>, 21 July 1998
5		James Simmons <jsimmons@user.sf.net>, Nov 26 2002
6
7		--------------------------------------------------------------------------------
8
9		* STRUCTURES USED BY THE FRAME BUFFER DEVICE API *
10
11		The following structures play a role in the game of frame buffer devices. They
12		are defined in <linux/fb.h>.
13
14		1. Outside the kernel (user space)
15
16		- struct fb_fix_screeninfo
17
18		Device independent unchangeable information about a frame buffer device and
19		a specific video mode. This can be obtained using the FBIOGET_FSCREENINFO
20		ioctl.
21
22		- struct fb_var_screeninfo
23
24		Device independent changeable information about a frame buffer device and a
25		specific video mode. This can be obtained using the FBIOGET_VSCREENINFO
26		ioctl, and updated with the FBIOPUT_VSCREENINFO ioctl. If you want to pan
27		the screen only, you can use the FBIOPAN_DISPLAY ioctl.
28
29		- struct fb_cmap
30
31		Device independent colormap information. You can get and set the colormap
32		using the FBIOGETCMAP and FBIOPUTCMAP ioctls.
33
34
35		2. Inside the kernel
36
37		- struct fb_info
38
39		Generic information, API and low level information about a specific frame
40		buffer device instance (slot number, board address, ...).
41
42		- struct `par'
43
44		Device dependent information that uniquely defines the video mode for this
45		particular piece of hardware.
46
47
48		--------------------------------------------------------------------------------
49
50		* VISUALS USED BY THE FRAME BUFFER DEVICE API *
51
52
53		Monochrome (FB_VISUAL_MONO01 and FB_VISUAL_MONO10)
54		-------------------------------------------------
55		Each pixel is either black or white.
56
57
58		Pseudo color (FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR)
59		---------------------------------------------------------------------
60		The whole pixel value is fed through a programmable lookup table that has one
61		color (including red, green, and blue intensities) for each possible pixel
62		value, and that color is displayed.
63
64
65		True color (FB_VISUAL_TRUECOLOR)
66		--------------------------------
67		The pixel value is broken up into red, green, and blue fields.
68
69
70		Direct color (FB_VISUAL_DIRECTCOLOR)
71		------------------------------------
72		The pixel value is broken up into red, green, and blue fields, each of which
73		are looked up in separate red, green, and blue lookup tables.
74
75
76		Grayscale displays
77		------------------
78		Grayscale and static grayscale are special variants of pseudo color and static
79		pseudo color, where the red, green and blue components are always equal to
80		each other.
81

+55

-0

debian/doc/kernel-doc/lxfb.rst less more

	0	=============
	1	What is lxfb?
	2	=============
	3
	4	.. [This file is cloned from VesaFB/aty128fb]
	5
	6
	7	This is a graphics framebuffer driver for AMD Geode LX based processors.
	8
	9	Advantages:
	10
	11	* No need to use AMD's VSA code (or other VESA emulation layer) in the
	12	BIOS.
	13	* It provides a nice large console (128 cols + 48 lines with 1024x768)
	14	without using tiny, unreadable fonts.
	15	* You can run XF68_FBDev on top of /dev/fb0
	16	* Most important: boot logo :-)
	17
	18	Disadvantages:
	19
	20	* graphic mode is slower than text mode...
	21
	22
	23	How to use it?
	24	==============
	25
	26	Switching modes is done using lxfb.mode_option=<resolution>... boot
	27	parameter or using `fbset` program.
	28
	29	See Documentation/fb/modedb.rst for more information on modedb
	30	resolutions.
	31
	32
	33	X11
	34	===
	35
	36	XF68_FBDev should generally work fine, but it is non-accelerated.
	37
	38
	39	Configuration
	40	=============
	41
	42	You can pass kernel command line options to lxfb with lxfb.<option>.
	43	For example, lxfb.mode_option=800x600@75.
	44	Accepted options:
	45
	46	================ ==================================================
	47	mode_option specify the video mode. Of the form
	48	<x>x<y>[-<bpp>][@<refresh>]
	49	vram size of video ram (normally auto-detected)
	50	vt_switch enable vt switching during suspend/resume. The vt
	51	switch is slow, but harmless.
	52	================ ==================================================
	53
	54	Andres Salomon <dilinger@debian.org>

-52

~~debian/doc/kernel-doc/lxfb.txt~~ less more

0		[This file is cloned from VesaFB/aty128fb]
1
2		What is lxfb?
3		=================
4
5		This is a graphics framebuffer driver for AMD Geode LX based processors.
6
7		Advantages:
8
9		* No need to use AMD's VSA code (or other VESA emulation layer) in the
10		BIOS.
11		* It provides a nice large console (128 cols + 48 lines with 1024x768)
12		without using tiny, unreadable fonts.
13		* You can run XF68_FBDev on top of /dev/fb0
14		* Most important: boot logo :-)
15
16		Disadvantages:
17
18		* graphic mode is slower than text mode...
19
20
21		How to use it?
22		==============
23
24		Switching modes is done using lxfb.mode_option=<resolution>... boot
25		parameter or using `fbset' program.
26
27		See Documentation/fb/modedb.txt for more information on modedb
28		resolutions.
29
30
31		X11
32		===
33
34		XF68_FBDev should generally work fine, but it is non-accelerated.
35
36
37		Configuration
38		=============
39
40		You can pass kernel command line options to lxfb with lxfb.<option>.
41		For example, lxfb.mode_option=800x600@75.
42		Accepted options:
43
44		mode_option - specify the video mode. Of the form
45		<x>x<y>[-<bpp>][@<refresh>]
46		vram - size of video ram (normally auto-detected)
47		vt_switch - enable vt switching during suspend/resume. The vt
48		switch is slow, but harmless.
49
50		--
51		Andres Salomon <dilinger@debian.org>

+443

-0

debian/doc/kernel-doc/matroxfb.rst less more

	0	=================
	1	What is matroxfb?
	2	=================
	3
	4	.. [This file is cloned from VesaFB. Thanks go to Gerd Knorr]
	5
	6
	7	This is a driver for a graphic framebuffer for Matrox devices on
	8	Alpha, Intel and PPC boxes.
	9
	10	Advantages:
	11
	12	* It provides a nice large console (128 cols + 48 lines with 1024x768)
	13	without using tiny, unreadable fonts.
	14	* You can run XF{68,86}_FBDev or XFree86 fbdev driver on top of /dev/fb0
	15	* Most important: boot logo :-)
	16
	17	Disadvantages:
	18
	19	* graphic mode is slower than text mode... but you should not notice
	20	if you use same resolution as you used in textmode.
	21
	22
	23	How to use it?
	24	==============
	25
	26	Switching modes is done using the video=matroxfb:vesa:... boot parameter
	27	or using `fbset` program.
	28
	29	If you want, for example, enable a resolution of 1280x1024x24bpp you should
	30	pass to the kernel this command line: "video=matroxfb:vesa:0x1BB".
	31
	32	You should compile in both vgacon (to boot if you remove you Matrox from
	33	box) and matroxfb (for graphics mode). You should not compile-in vesafb
	34	unless you have primary display on non-Matrox VBE2.0 device (see
	35	Documentation/fb/vesafb.rst for details).
	36
	37	Currently supported video modes are (through vesa:... interface, PowerMac
	38	has [as addon] compatibility code):
	39
	40
	41	Graphic modes
	42	-------------
	43
	44	=== ======= ======= ======= ======= =======
	45	bpp 640x400 640x480 768x576 800x600 960x720
	46	=== ======= ======= ======= ======= =======
	47	4 0x12 0x102
	48	8 0x100 0x101 0x180 0x103 0x188
	49	15 0x110 0x181 0x113 0x189
	50	16 0x111 0x182 0x114 0x18A
	51	24 0x1B2 0x184 0x1B5 0x18C
	52	32 0x112 0x183 0x115 0x18B
	53	=== ======= ======= ======= ======= =======
	54
	55
	56	Graphic modes (continued)
	57	-------------------------
	58
	59	=== ======== ======== ========= ========= =========
	60	bpp 1024x768 1152x864 1280x1024 1408x1056 1600x1200
	61	=== ======== ======== ========= ========= =========
	62	4 0x104 0x106
	63	8 0x105 0x190 0x107 0x198 0x11C
	64	15 0x116 0x191 0x119 0x199 0x11D
	65	16 0x117 0x192 0x11A 0x19A 0x11E
	66	24 0x1B8 0x194 0x1BB 0x19C 0x1BF
	67	32 0x118 0x193 0x11B 0x19B
	68	=== ======== ======== ========= ========= =========
	69
	70
	71	Text modes
	72	----------
	73
	74	==== ======= ======= ======== ======== ========
	75	text 640x400 640x480 1056x344 1056x400 1056x480
	76	==== ======= ======= ======== ======== ========
	77	8x8 0x1C0 0x108 0x10A 0x10B 0x10C
	78	8x16 2, 3, 7 0x109
	79	==== ======= ======= ======== ======== ========
	80
	81	You can enter these number either hexadecimal (leading `0x`) or decimal
	82	(0x100 = 256). You can also use value + 512 to achieve compatibility
	83	with your old number passed to vesafb.
	84
	85	Non-listed number can be achieved by more complicated command-line, for
	86	example 1600x1200x32bpp can be specified by `video=matroxfb:vesa:0x11C,depth:32`.
	87
	88
	89	X11
	90	===
	91
	92	XF{68,86}_FBDev should work just fine, but it is non-accelerated. On non-intel
	93	architectures there are some glitches for 24bpp videomodes. 8, 16 and 32bpp
	94	works fine.
	95
	96	Running another (accelerated) X-Server like XF86_SVGA works too. But (at least)
	97	XFree servers have big troubles in multihead configurations (even on first
	98	head, not even talking about second). Running XFree86 4.x accelerated mga
	99	driver is possible, but you must not enable DRI - if you do, resolution and
	100	color depth of your X desktop must match resolution and color depths of your
	101	virtual consoles, otherwise X will corrupt accelerator settings.
	102
	103
	104	SVGALib
	105	=======
	106
	107	Driver contains SVGALib compatibility code. It is turned on by choosing textual
	108	mode for console. You can do it at boot time by using videomode
	109	2,3,7,0x108-0x10C or 0x1C0. At runtime, `fbset -depth 0` does this work.
	110	Unfortunately, after SVGALib application exits, screen contents is corrupted.
	111	Switching to another console and back fixes it. I hope that it is SVGALib's
	112	problem and not mine, but I'm not sure.
	113
	114
	115	Configuration
	116	=============
	117
	118	You can pass kernel command line options to matroxfb with
	119	`video=matroxfb:option1,option2:value2,option3` (multiple options should be
	120	separated by comma, values are separated from options by `:`).
	121	Accepted options:
	122
	123	============ ===================================================================
	124	mem:X size of memory (X can be in megabytes, kilobytes or bytes)
	125	You can only decrease value determined by driver because of
	126	it always probe for memory. Default is to use whole detected
	127	memory usable for on-screen display (i.e. max. 8 MB).
	128	disabled do not load driver; you can use also `off`, but `disabled`
	129	is here too.
	130	enabled load driver, if you have `video=matroxfb:disabled` in LILO
	131	configuration, you can override it by this (you cannot override
	132	`off`). It is default.
	133	noaccel do not use acceleration engine. It does not work on Alphas.
	134	accel use acceleration engine. It is default.
	135	nopan create initial consoles with vyres = yres, thus disabling virtual
	136	scrolling.
	137	pan create initial consoles as tall as possible (vyres = memory/vxres).
	138	It is default.
	139	nopciretry disable PCI retries. It is needed for some broken chipsets,
	140	it is autodetected for intel's 82437. In this case device does
	141	not comply to PCI 2.1 specs (it will not guarantee that every
	142	transaction terminate with success or retry in 32 PCLK).
	143	pciretry enable PCI retries. It is default, except for intel's 82437.
	144	novga disables VGA I/O ports. It is default if BIOS did not enable
	145	device. You should not use this option, some boards then do not
	146	restart without power off.
	147	vga preserve state of VGA I/O ports. It is default. Driver does not
	148	enable VGA I/O if BIOS did not it (it is not safe to enable it in
	149	most cases).
	150	nobios disables BIOS ROM. It is default if BIOS did not enable BIOS
	151	itself. You should not use this option, some boards then do not
	152	restart without power off.
	153	bios preserve state of BIOS ROM. It is default. Driver does not enable
	154	BIOS if BIOS was not enabled before.
	155	noinit tells driver, that devices were already initialized. You should use
	156	it if you have G100 and/or if driver cannot detect memory, you see
	157	strange pattern on screen and so on. Devices not enabled by BIOS
	158	are still initialized. It is default.
	159	init driver initializes every device it knows about.
	160	memtype specifies memory type, implies 'init'. This is valid only for G200
	161	and G400 and has following meaning:
	162
	163	G200:
	164	- 0 -> 2x128Kx32 chips, 2MB onboard, probably sgram
	165	- 1 -> 2x128Kx32 chips, 4MB onboard, probably sgram
	166	- 2 -> 2x256Kx32 chips, 4MB onboard, probably sgram
	167	- 3 -> 2x256Kx32 chips, 8MB onboard, probably sgram
	168	- 4 -> 2x512Kx16 chips, 8/16MB onboard, probably sdram only
	169	- 5 -> same as above
	170	- 6 -> 4x128Kx32 chips, 4MB onboard, probably sgram
	171	- 7 -> 4x128Kx32 chips, 8MB onboard, probably sgram
	172	G400:
	173	- 0 -> 2x512Kx16 SDRAM, 16/32MB
	174	- 2x512Kx32 SGRAM, 16/32MB
	175	- 1 -> 2x256Kx32 SGRAM, 8/16MB
	176	- 2 -> 4x128Kx32 SGRAM, 8/16MB
	177	- 3 -> 4x512Kx32 SDRAM, 32MB
	178	- 4 -> 4x256Kx32 SGRAM, 16/32MB
	179	- 5 -> 2x1Mx32 SDRAM, 32MB
	180	- 6 -> reserved
	181	- 7 -> reserved
	182
	183	You should use sdram or sgram parameter in addition to memtype
	184	parameter.
	185	nomtrr disables write combining on frame buffer. This slows down driver
	186	but there is reported minor incompatibility between GUS DMA and
	187	XFree under high loads if write combining is enabled (sound
	188	dropouts).
	189	mtrr enables write combining on frame buffer. It speeds up video
	190	accesses much. It is default. You must have MTRR support enabled
	191	in kernel and your CPU must have MTRR (f.e. Pentium II have them).
	192	sgram tells to driver that you have Gxx0 with SGRAM memory. It has no
	193	effect without `init`.
	194	sdram tells to driver that you have Gxx0 with SDRAM memory.
	195	It is a default.
	196	inv24 change timings parameters for 24bpp modes on Millennium and
	197	Millennium II. Specify this if you see strange color shadows
	198	around characters.
	199	noinv24 use standard timings. It is the default.
	200	inverse invert colors on screen (for LCD displays)
	201	noinverse show true colors on screen. It is default.
	202	dev:X bind driver to device X. Driver numbers device from 0 up to N,
	203	where device 0 is first `known` device found, 1 second and so on.
	204	lspci lists devices in this order.
	205	Default is `every` known device.
	206	nohwcursor disables hardware cursor (use software cursor instead).
	207	hwcursor enables hardware cursor. It is default. If you are using
	208	non-accelerated mode (`noaccel` or `fbset -accel false`), software
	209	cursor is used (except for text mode).
	210	noblink disables cursor blinking. Cursor in text mode always blinks (hw
	211	limitation).
	212	blink enables cursor blinking. It is default.
	213	nofastfont disables fastfont feature. It is default.
	214	fastfont:X enables fastfont feature. X specifies size of memory reserved for
	215	font data, it must be >= (fontwidthfontheightchars_in_font)/8.
	216	It is faster on Gx00 series, but slower on older cards.
	217	grayscale enable grayscale summing. It works in PSEUDOCOLOR modes (text,
	218	4bpp, 8bpp). In DIRECTCOLOR modes it is limited to characters
	219	displayed through putc/putcs. Direct accesses to framebuffer
	220	can paint colors.
	221	nograyscale disable grayscale summing. It is default.
	222	cross4MB enables that pixel line can cross 4MB boundary. It is default for
	223	non-Millennium.
	224	nocross4MB pixel line must not cross 4MB boundary. It is default for
	225	Millennium I or II, because of these devices have hardware
	226	limitations which do not allow this. But this option is
	227	incompatible with some (if not all yet released) versions of
	228	XF86_FBDev.
	229	dfp enables digital flat panel interface. This option is incompatible
	230	with secondary (TV) output - if DFP is active, TV output must be
	231	inactive and vice versa. DFP always uses same timing as primary
	232	(monitor) output.
	233	dfp:X use settings X for digital flat panel interface. X is number from
	234	0 to 0xFF, and meaning of each individual bit is described in
	235	G400 manual, in description of DAC register 0x1F. For normal
	236	operation you should set all bits to zero, except lowest bit. This
	237	lowest bit selects who is source of display clocks, whether G400,
	238	or panel. Default value is now read back from hardware - so you
	239	should specify this value only if you are also using `init`
	240	parameter.
	241	outputs:XYZ set mapping between CRTC and outputs. Each letter can have value
	242	of 0 (for no CRTC), 1 (CRTC1) or 2 (CRTC2), and first letter
	243	corresponds to primary analog output, second letter to the
	244	secondary analog output and third letter to the DVI output.
	245	Default setting is 100 for cards below G400 or G400 without DFP,
	246	101 for G400 with DFP, and 111 for G450 and G550. You can set
	247	mapping only on first card, use matroxset for setting up other
	248	devices.
	249	vesa:X selects startup videomode. X is number from 0 to 0x1FF, see table
	250	above for detailed explanation. Default is 640x480x8bpp if driver
	251	has 8bpp support. Otherwise first available of 640x350x4bpp,
	252	640x480x15bpp, 640x480x24bpp, 640x480x32bpp or 80x25 text
	253	(80x25 text is always available).
	254	============ ===================================================================
	255
	256	If you are not satisfied with videomode selected by `vesa` option, you
	257	can modify it with these options:
	258
	259	============ ===================================================================
	260	xres:X horizontal resolution, in pixels. Default is derived from `vesa`
	261	option.
	262	yres:X vertical resolution, in pixel lines. Default is derived from `vesa`
	263	option.
	264	upper:X top boundary: lines between end of VSYNC pulse and start of first
	265	pixel line of picture. Default is derived from `vesa` option.
	266	lower:X bottom boundary: lines between end of picture and start of VSYNC
	267	pulse. Default is derived from `vesa` option.
	268	vslen:X length of VSYNC pulse, in lines. Default is derived from `vesa`
	269	option.
	270	left:X left boundary: pixels between end of HSYNC pulse and first pixel.
	271	Default is derived from `vesa` option.
	272	right:X right boundary: pixels between end of picture and start of HSYNC
	273	pulse. Default is derived from `vesa` option.
	274	hslen:X length of HSYNC pulse, in pixels. Default is derived from `vesa`
	275	option.
	276	pixclock:X dotclocks, in ps (picoseconds). Default is derived from `vesa`
	277	option and from `fh` and `fv` options.
	278	sync:X sync. pulse - bit 0 inverts HSYNC polarity, bit 1 VSYNC polarity.
	279	If bit 3 (value 0x08) is set, composite sync instead of HSYNC is
	280	generated. If bit 5 (value 0x20) is set, sync on green is turned
	281	on. Do not forget that if you want sync on green, you also probably
	282	want composite sync.
	283	Default depends on `vesa`.
	284	depth:X Bits per pixel: 0=text, 4,8,15,16,24 or 32. Default depends on
	285	`vesa`.
	286	============ ===================================================================
	287
	288	If you know capabilities of your monitor, you can specify some (or all) of
	289	`maxclk`, `fh` and `fv`. In this case, `pixclock` is computed so that
	290	pixclock <= maxclk, real_fh <= fh and real_fv <= fv.
	291
	292	============ ==================================================================
	293	maxclk:X maximum dotclock. X can be specified in MHz, kHz or Hz. Default is
	294	`don`t care`.
	295	fh:X maximum horizontal synchronization frequency. X can be specified
	296	in kHz or Hz. Default is `don't care`.
	297	fv:X maximum vertical frequency. X must be specified in Hz. Default is
	298	70 for modes derived from `vesa` with yres <= 400, 60Hz for
	299	yres > 400.
	300	============ ==================================================================
	301
	302
	303	Limitations
	304	===========
	305
	306	There are known and unknown bugs, features and misfeatures.
	307	Currently there are following known bugs:
	308
	309	- SVGALib does not restore screen on exit
	310	- generic fbcon-cfbX procedures do not work on Alphas. Due to this,
	311	`noaccel` (and cfb4 accel) driver does not work on Alpha. So everyone
	312	with access to `/dev/fb*` on Alpha can hang machine (you should restrict
	313	access to `/dev/fb*` - everyone with access to this device can destroy
	314	your monitor, believe me...).
	315	- 24bpp does not support correctly XF-FBDev on big-endian architectures.
	316	- interlaced text mode is not supported; it looks like hardware limitation,
	317	but I'm not sure.
	318	- Gxx0 SGRAM/SDRAM is not autodetected.
	319	- If you are using more than one framebuffer device, you must boot kernel
	320	with 'video=scrollback:0'.
	321	- maybe more...
	322
	323	And following misfeatures:
	324
	325	- SVGALib does not restore screen on exit.
	326	- pixclock for text modes is limited by hardware to
	327
	328	- 83 MHz on G200
	329	- 66 MHz on Millennium I
	330	- 60 MHz on Millennium II
	331
	332	Because I have no access to other devices, I do not know specific
	333	frequencies for them. So driver does not check this and allows you to
	334	set frequency higher that this. It causes sparks, black holes and other
	335	pretty effects on screen. Device was not destroyed during tests. :-)
	336	- my Millennium G200 oscillator has frequency range from 35 MHz to 380 MHz
	337	(and it works with 8bpp on about 320 MHz dotclocks (and changed mclk)).
	338	But Matrox says on product sheet that VCO limit is 50-250 MHz, so I believe
	339	them (maybe that chip overheats, but it has a very big cooler (G100 has
	340	none), so it should work).
	341	- special mixed video/graphics videomodes of Mystique and Gx00 - 2G8V16 and
	342	G16V16 are not supported
	343	- color keying is not supported
	344	- feature connector of Mystique and Gx00 is set to VGA mode (it is disabled
	345	by BIOS)
	346	- DDC (monitor detection) is supported through dualhead driver
	347	- some check for input values are not so strict how it should be (you can
	348	specify vslen=4000 and so on).
	349	- maybe more...
	350
	351	And following features:
	352
	353	- 4bpp is available only on Millennium I and Millennium II. It is hardware
	354	limitation.
	355	- selection between 1:5:5:5 and 5:6:5 16bpp videomode is done by -rgba
	356	option of fbset: "fbset -depth 16 -rgba 5,5,5" selects 1:5:5:5, anything
	357	else selects 5:6:5 mode.
	358	- text mode uses 6 bit VGA palette instead of 8 bit (one of 262144 colors
	359	instead of one of 16M colors). It is due to hardware limitation of
	360	Millennium I/II and SVGALib compatibility.
	361
	362
	363	Benchmarks
	364	==========
	365	It is time to redraw whole screen 1000 times in 1024x768, 60Hz. It is
	366	time for draw 6144000 characters on screen through /dev/vcsa
	367	(for 32bpp it is about 3GB of data (exactly 3000 MB); for 8x16 font in
	368	16 seconds, i.e. 187 MBps).
	369	Times were obtained from one older version of driver, now they are about 3%
	370	faster, it is kernel-space only time on P-II/350 MHz, Millennium I in 33 MHz
	371	PCI slot, G200 in AGP 2x slot. I did not test vgacon::
	372
	373	NOACCEL
	374	8x16 12x22
	375	Millennium I G200 Millennium I G200
	376	8bpp 16.42 9.54 12.33 9.13
	377	16bpp 21.00 15.70 19.11 15.02
	378	24bpp 36.66 36.66 35.00 35.00
	379	32bpp 35.00 30.00 33.85 28.66
	380
	381	ACCEL, nofastfont
	382	8x16 12x22 6x11
	383	Millennium I G200 Millennium I G200 Millennium I G200
	384	8bpp 7.79 7.24 13.55 7.78 30.00 21.01
	385	16bpp 9.13 7.78 16.16 7.78 30.00 21.01
	386	24bpp 14.17 10.72 18.69 10.24 34.99 21.01
	387	32bpp 16.15 16.16 18.73 13.09 34.99 21.01
	388
	389	ACCEL, fastfont
	390	8x16 12x22 6x11
	391	Millennium I G200 Millennium I G200 Millennium I G200
	392	8bpp 8.41 6.01 6.54 4.37 16.00 10.51
	393	16bpp 9.54 9.12 8.76 6.17 17.52 14.01
	394	24bpp 15.00 12.36 11.67 10.00 22.01 18.32
	395	32bpp 16.18 18.29* 12.71 12.74 24.44 21.00
	396
	397	TEXT
	398	8x16
	399	Millennium I G200
	400	TEXT 3.29 1.50
	401
	402	* Yes, it is slower than Millennium I.
	403
	404
	405	Dualhead G400
	406	=============
	407	Driver supports dualhead G400 with some limitations:
	408	+ secondary head shares videomemory with primary head. It is not problem
	409	if you have 32MB of videoram, but if you have only 16MB, you may have
	410	to think twice before choosing videomode (for example twice 1880x1440x32bpp
	411	is not possible).
	412	+ due to hardware limitation, secondary head can use only 16 and 32bpp
	413	videomodes.
	414	+ secondary head is not accelerated. There were bad problems with accelerated
	415	XFree when secondary head used to use acceleration.
	416	+ secondary head always powerups in 640x480@60-32 videomode. You have to use
	417	fbset to change this mode.
	418	+ secondary head always powerups in monitor mode. You have to use fbmatroxset
	419	to change it to TV mode. Also, you must select at least 525 lines for
	420	NTSC output and 625 lines for PAL output.
	421	+ kernel is not fully multihead ready. So some things are impossible to do.
	422	+ if you compiled it as module, you must insert i2c-matroxfb, matroxfb_maven
	423	and matroxfb_crtc2 into kernel.
	424
	425
	426	Dualhead G450
	427	=============
	428	Driver supports dualhead G450 with some limitations:
	429	+ secondary head shares videomemory with primary head. It is not problem
	430	if you have 32MB of videoram, but if you have only 16MB, you may have
	431	to think twice before choosing videomode.
	432	+ due to hardware limitation, secondary head can use only 16 and 32bpp
	433	videomodes.
	434	+ secondary head is not accelerated.
	435	+ secondary head always powerups in 640x480@60-32 videomode. You have to use
	436	fbset to change this mode.
	437	+ TV output is not supported
	438	+ kernel is not fully multihead ready, so some things are impossible to do.
	439	+ if you compiled it as module, you must insert matroxfb_g450 and matroxfb_crtc2
	440	into kernel.
	441
	442	Petr Vandrovec <vandrove@vc.cvut.cz>

-413

~~debian/doc/kernel-doc/matroxfb.txt~~ less more

0		[This file is cloned from VesaFB. Thanks go to Gerd Knorr]
1
2		What is matroxfb?
3		=================
4
5		This is a driver for a graphic framebuffer for Matrox devices on
6		Alpha, Intel and PPC boxes.
7
8		Advantages:
9
10		* It provides a nice large console (128 cols + 48 lines with 1024x768)
11		without using tiny, unreadable fonts.
12		* You can run XF{68,86}_FBDev or XFree86 fbdev driver on top of /dev/fb0
13		* Most important: boot logo :-)
14
15		Disadvantages:
16
17		* graphic mode is slower than text mode... but you should not notice
18		if you use same resolution as you used in textmode.
19
20
21		How to use it?
22		==============
23
24		Switching modes is done using the video=matroxfb:vesa:... boot parameter
25		or using `fbset' program.
26
27		If you want, for example, enable a resolution of 1280x1024x24bpp you should
28		pass to the kernel this command line: "video=matroxfb:vesa:0x1BB".
29
30		You should compile in both vgacon (to boot if you remove you Matrox from
31		box) and matroxfb (for graphics mode). You should not compile-in vesafb
32		unless you have primary display on non-Matrox VBE2.0 device (see
33		Documentation/fb/vesafb.txt for details).
34
35		Currently supported video modes are (through vesa:... interface, PowerMac
36		has [as addon] compatibility code):
37
38
39		[Graphic modes]
40
41		bpp \| 640x400 640x480 768x576 800x600 960x720
42		----+--------------------------------------------
43		4 \| 0x12 0x102
44		8 \| 0x100 0x101 0x180 0x103 0x188
45		15 \| 0x110 0x181 0x113 0x189
46		16 \| 0x111 0x182 0x114 0x18A
47		24 \| 0x1B2 0x184 0x1B5 0x18C
48		32 \| 0x112 0x183 0x115 0x18B
49
50
51		[Graphic modes (continued)]
52
53		bpp \| 1024x768 1152x864 1280x1024 1408x1056 1600x1200
54		----+------------------------------------------------
55		4 \| 0x104 0x106
56		8 \| 0x105 0x190 0x107 0x198 0x11C
57		15 \| 0x116 0x191 0x119 0x199 0x11D
58		16 \| 0x117 0x192 0x11A 0x19A 0x11E
59		24 \| 0x1B8 0x194 0x1BB 0x19C 0x1BF
60		32 \| 0x118 0x193 0x11B 0x19B
61
62
63		[Text modes]
64
65		text \| 640x400 640x480 1056x344 1056x400 1056x480
66		-----+------------------------------------------------
67		8x8 \| 0x1C0 0x108 0x10A 0x10B 0x10C
68		8x16 \| 2, 3, 7 0x109
69
70		You can enter these number either hexadecimal (leading `0x') or decimal
71		(0x100 = 256). You can also use value + 512 to achieve compatibility
72		with your old number passed to vesafb.
73
74		Non-listed number can be achieved by more complicated command-line, for
75		example 1600x1200x32bpp can be specified by `video=matroxfb:vesa:0x11C,depth:32'.
76
77
78		X11
79		===
80
81		XF{68,86}_FBDev should work just fine, but it is non-accelerated. On non-intel
82		architectures there are some glitches for 24bpp videomodes. 8, 16 and 32bpp
83		works fine.
84
85		Running another (accelerated) X-Server like XF86_SVGA works too. But (at least)
86		XFree servers have big troubles in multihead configurations (even on first
87		head, not even talking about second). Running XFree86 4.x accelerated mga
88		driver is possible, but you must not enable DRI - if you do, resolution and
89		color depth of your X desktop must match resolution and color depths of your
90		virtual consoles, otherwise X will corrupt accelerator settings.
91
92
93		SVGALib
94		=======
95
96		Driver contains SVGALib compatibility code. It is turned on by choosing textual
97		mode for console. You can do it at boot time by using videomode
98		2,3,7,0x108-0x10C or 0x1C0. At runtime, `fbset -depth 0' does this work.
99		Unfortunately, after SVGALib application exits, screen contents is corrupted.
100		Switching to another console and back fixes it. I hope that it is SVGALib's
101		problem and not mine, but I'm not sure.
102
103
104		Configuration
105		=============
106
107		You can pass kernel command line options to matroxfb with
108		`video=matroxfb:option1,option2:value2,option3' (multiple options should be
109		separated by comma, values are separated from options by `:').
110		Accepted options:
111
112		mem:X - size of memory (X can be in megabytes, kilobytes or bytes)
113		You can only decrease value determined by driver because of
114		it always probe for memory. Default is to use whole detected
115		memory usable for on-screen display (i.e. max. 8 MB).
116		disabled - do not load driver; you can use also `off', but `disabled'
117		is here too.
118		enabled - load driver, if you have `video=matroxfb:disabled' in LILO
119		configuration, you can override it by this (you cannot override
120		`off'). It is default.
121		noaccel - do not use acceleration engine. It does not work on Alphas.
122		accel - use acceleration engine. It is default.
123		nopan - create initial consoles with vyres = yres, thus disabling virtual
124		scrolling.
125		pan - create initial consoles as tall as possible (vyres = memory/vxres).
126		It is default.
127		nopciretry - disable PCI retries. It is needed for some broken chipsets,
128		it is autodetected for intel's 82437. In this case device does
129		not comply to PCI 2.1 specs (it will not guarantee that every
130		transaction terminate with success or retry in 32 PCLK).
131		pciretry - enable PCI retries. It is default, except for intel's 82437.
132		novga - disables VGA I/O ports. It is default if BIOS did not enable device.
133		You should not use this option, some boards then do not restart
134		without power off.
135		vga - preserve state of VGA I/O ports. It is default. Driver does not
136		enable VGA I/O if BIOS did not it (it is not safe to enable it in
137		most cases).
138		nobios - disables BIOS ROM. It is default if BIOS did not enable BIOS itself.
139		You should not use this option, some boards then do not restart
140		without power off.
141		bios - preserve state of BIOS ROM. It is default. Driver does not enable
142		BIOS if BIOS was not enabled before.
143		noinit - tells driver, that devices were already initialized. You should use
144		it if you have G100 and/or if driver cannot detect memory, you see
145		strange pattern on screen and so on. Devices not enabled by BIOS
146		are still initialized. It is default.
147		init - driver initializes every device it knows about.
148		memtype - specifies memory type, implies 'init'. This is valid only for G200
149		and G400 and has following meaning:
150		G200: 0 -> 2x128Kx32 chips, 2MB onboard, probably sgram
151		1 -> 2x128Kx32 chips, 4MB onboard, probably sgram
152		2 -> 2x256Kx32 chips, 4MB onboard, probably sgram
153		3 -> 2x256Kx32 chips, 8MB onboard, probably sgram
154		4 -> 2x512Kx16 chips, 8/16MB onboard, probably sdram only
155		5 -> same as above
156		6 -> 4x128Kx32 chips, 4MB onboard, probably sgram
157		7 -> 4x128Kx32 chips, 8MB onboard, probably sgram
158		G400: 0 -> 2x512Kx16 SDRAM, 16/32MB
159		2x512Kx32 SGRAM, 16/32MB
160		1 -> 2x256Kx32 SGRAM, 8/16MB
161		2 -> 4x128Kx32 SGRAM, 8/16MB
162		3 -> 4x512Kx32 SDRAM, 32MB
163		4 -> 4x256Kx32 SGRAM, 16/32MB
164		5 -> 2x1Mx32 SDRAM, 32MB
165		6 -> reserved
166		7 -> reserved
167		You should use sdram or sgram parameter in addition to memtype
168		parameter.
169		nomtrr - disables write combining on frame buffer. This slows down driver but
170		there is reported minor incompatibility between GUS DMA and XFree
171		under high loads if write combining is enabled (sound dropouts).
172		mtrr - enables write combining on frame buffer. It speeds up video accesses
173		much. It is default. You must have MTRR support enabled in kernel
174		and your CPU must have MTRR (f.e. Pentium II have them).
175		sgram - tells to driver that you have Gxx0 with SGRAM memory. It has no
176		effect without `init'.
177		sdram - tells to driver that you have Gxx0 with SDRAM memory.
178		It is a default.
179		inv24 - change timings parameters for 24bpp modes on Millennium and
180		Millennium II. Specify this if you see strange color shadows around
181		characters.
182		noinv24 - use standard timings. It is the default.
183		inverse - invert colors on screen (for LCD displays)
184		noinverse - show true colors on screen. It is default.
185		dev:X - bind driver to device X. Driver numbers device from 0 up to N,
186		where device 0 is first `known' device found, 1 second and so on.
187		lspci lists devices in this order.
188		Default is `every' known device.
189		nohwcursor - disables hardware cursor (use software cursor instead).
190		hwcursor - enables hardware cursor. It is default. If you are using
191		non-accelerated mode (`noaccel' or `fbset -accel false'), software
192		cursor is used (except for text mode).
193		noblink - disables cursor blinking. Cursor in text mode always blinks (hw
194		limitation).
195		blink - enables cursor blinking. It is default.
196		nofastfont - disables fastfont feature. It is default.
197		fastfont:X - enables fastfont feature. X specifies size of memory reserved for
198		font data, it must be >= (fontwidthfontheightchars_in_font)/8.
199		It is faster on Gx00 series, but slower on older cards.
200		grayscale - enable grayscale summing. It works in PSEUDOCOLOR modes (text,
201		4bpp, 8bpp). In DIRECTCOLOR modes it is limited to characters
202		displayed through putc/putcs. Direct accesses to framebuffer
203		can paint colors.
204		nograyscale - disable grayscale summing. It is default.
205		cross4MB - enables that pixel line can cross 4MB boundary. It is default for
206		non-Millennium.
207		nocross4MB - pixel line must not cross 4MB boundary. It is default for
208		Millennium I or II, because of these devices have hardware
209		limitations which do not allow this. But this option is
210		incompatible with some (if not all yet released) versions of
211		XF86_FBDev.
212		dfp - enables digital flat panel interface. This option is incompatible with
213		secondary (TV) output - if DFP is active, TV output must be
214		inactive and vice versa. DFP always uses same timing as primary
215		(monitor) output.
216		dfp:X - use settings X for digital flat panel interface. X is number from
217		0 to 0xFF, and meaning of each individual bit is described in
218		G400 manual, in description of DAC register 0x1F. For normal operation
219		you should set all bits to zero, except lowest bit. This lowest bit
220		selects who is source of display clocks, whether G400, or panel.
221		Default value is now read back from hardware - so you should specify
222		this value only if you are also using `init' parameter.
223		outputs:XYZ - set mapping between CRTC and outputs. Each letter can have value
224		of 0 (for no CRTC), 1 (CRTC1) or 2 (CRTC2), and first letter corresponds
225		to primary analog output, second letter to the secondary analog output
226		and third letter to the DVI output. Default setting is 100 for
227		cards below G400 or G400 without DFP, 101 for G400 with DFP, and
228		111 for G450 and G550. You can set mapping only on first card,
229		use matroxset for setting up other devices.
230		vesa:X - selects startup videomode. X is number from 0 to 0x1FF, see table
231		above for detailed explanation. Default is 640x480x8bpp if driver
232		has 8bpp support. Otherwise first available of 640x350x4bpp,
233		640x480x15bpp, 640x480x24bpp, 640x480x32bpp or 80x25 text
234		(80x25 text is always available).
235
236		If you are not satisfied with videomode selected by `vesa' option, you
237		can modify it with these options:
238
239		xres:X - horizontal resolution, in pixels. Default is derived from `vesa'
240		option.
241		yres:X - vertical resolution, in pixel lines. Default is derived from `vesa'
242		option.
243		upper:X - top boundary: lines between end of VSYNC pulse and start of first
244		pixel line of picture. Default is derived from `vesa' option.
245		lower:X - bottom boundary: lines between end of picture and start of VSYNC
246		pulse. Default is derived from `vesa' option.
247		vslen:X - length of VSYNC pulse, in lines. Default is derived from `vesa'
248		option.
249		left:X - left boundary: pixels between end of HSYNC pulse and first pixel.
250		Default is derived from `vesa' option.
251		right:X - right boundary: pixels between end of picture and start of HSYNC
252		pulse. Default is derived from `vesa' option.
253		hslen:X - length of HSYNC pulse, in pixels. Default is derived from `vesa'
254		option.
255		pixclock:X - dotclocks, in ps (picoseconds). Default is derived from `vesa'
256		option and from `fh' and `fv' options.
257		sync:X - sync. pulse - bit 0 inverts HSYNC polarity, bit 1 VSYNC polarity.
258		If bit 3 (value 0x08) is set, composite sync instead of HSYNC is
259		generated. If bit 5 (value 0x20) is set, sync on green is turned on.
260		Do not forget that if you want sync on green, you also probably
261		want composite sync.
262		Default depends on `vesa'.
263		depth:X - Bits per pixel: 0=text, 4,8,15,16,24 or 32. Default depends on
264		`vesa'.
265
266		If you know capabilities of your monitor, you can specify some (or all) of
267		`maxclk', `fh' and `fv'. In this case, `pixclock' is computed so that
268		pixclock <= maxclk, real_fh <= fh and real_fv <= fv.
269
270		maxclk:X - maximum dotclock. X can be specified in MHz, kHz or Hz. Default is
271		`don't care'.
272		fh:X - maximum horizontal synchronization frequency. X can be specified
273		in kHz or Hz. Default is `don't care'.
274		fv:X - maximum vertical frequency. X must be specified in Hz. Default is
275		70 for modes derived from `vesa' with yres <= 400, 60Hz for
276		yres > 400.
277
278
279		Limitations
280		===========
281
282		There are known and unknown bugs, features and misfeatures.
283		Currently there are following known bugs:
284		+ SVGALib does not restore screen on exit
285		+ generic fbcon-cfbX procedures do not work on Alphas. Due to this,
286		`noaccel' (and cfb4 accel) driver does not work on Alpha. So everyone
287		with access to /dev/fb* on Alpha can hang machine (you should restrict
288		access to /dev/fb* - everyone with access to this device can destroy
289		your monitor, believe me...).
290		+ 24bpp does not support correctly XF-FBDev on big-endian architectures.
291		+ interlaced text mode is not supported; it looks like hardware limitation,
292		but I'm not sure.
293		+ Gxx0 SGRAM/SDRAM is not autodetected.
294		+ If you are using more than one framebuffer device, you must boot kernel
295		with 'video=scrollback:0'.
296		+ maybe more...
297		And following misfeatures:
298		+ SVGALib does not restore screen on exit.
299		+ pixclock for text modes is limited by hardware to
300		83 MHz on G200
301		66 MHz on Millennium I
302		60 MHz on Millennium II
303		Because I have no access to other devices, I do not know specific
304		frequencies for them. So driver does not check this and allows you to
305		set frequency higher that this. It causes sparks, black holes and other
306		pretty effects on screen. Device was not destroyed during tests. :-)
307		+ my Millennium G200 oscillator has frequency range from 35 MHz to 380 MHz
308		(and it works with 8bpp on about 320 MHz dotclocks (and changed mclk)).
309		But Matrox says on product sheet that VCO limit is 50-250 MHz, so I believe
310		them (maybe that chip overheats, but it has a very big cooler (G100 has
311		none), so it should work).
312		+ special mixed video/graphics videomodes of Mystique and Gx00 - 2G8V16 and
313		G16V16 are not supported
314		+ color keying is not supported
315		+ feature connector of Mystique and Gx00 is set to VGA mode (it is disabled
316		by BIOS)
317		+ DDC (monitor detection) is supported through dualhead driver
318		+ some check for input values are not so strict how it should be (you can
319		specify vslen=4000 and so on).
320		+ maybe more...
321		And following features:
322		+ 4bpp is available only on Millennium I and Millennium II. It is hardware
323		limitation.
324		+ selection between 1:5:5:5 and 5:6:5 16bpp videomode is done by -rgba
325		option of fbset: "fbset -depth 16 -rgba 5,5,5" selects 1:5:5:5, anything
326		else selects 5:6:5 mode.
327		+ text mode uses 6 bit VGA palette instead of 8 bit (one of 262144 colors
328		instead of one of 16M colors). It is due to hardware limitation of
329		Millennium I/II and SVGALib compatibility.
330
331
332		Benchmarks
333		==========
334		It is time to redraw whole screen 1000 times in 1024x768, 60Hz. It is
335		time for draw 6144000 characters on screen through /dev/vcsa
336		(for 32bpp it is about 3GB of data (exactly 3000 MB); for 8x16 font in
337		16 seconds, i.e. 187 MBps).
338		Times were obtained from one older version of driver, now they are about 3%
339		faster, it is kernel-space only time on P-II/350 MHz, Millennium I in 33 MHz
340		PCI slot, G200 in AGP 2x slot. I did not test vgacon.
341
342		NOACCEL
343		8x16 12x22
344		Millennium I G200 Millennium I G200
345		8bpp 16.42 9.54 12.33 9.13
346		16bpp 21.00 15.70 19.11 15.02
347		24bpp 36.66 36.66 35.00 35.00
348		32bpp 35.00 30.00 33.85 28.66
349
350		ACCEL, nofastfont
351		8x16 12x22 6x11
352		Millennium I G200 Millennium I G200 Millennium I G200
353		8bpp 7.79 7.24 13.55 7.78 30.00 21.01
354		16bpp 9.13 7.78 16.16 7.78 30.00 21.01
355		24bpp 14.17 10.72 18.69 10.24 34.99 21.01
356		32bpp 16.15 16.16 18.73 13.09 34.99 21.01
357
358		ACCEL, fastfont
359		8x16 12x22 6x11
360		Millennium I G200 Millennium I G200 Millennium I G200
361		8bpp 8.41 6.01 6.54 4.37 16.00 10.51
362		16bpp 9.54 9.12 8.76 6.17 17.52 14.01
363		24bpp 15.00 12.36 11.67 10.00 22.01 18.32
364		32bpp 16.18 18.29* 12.71 12.74 24.44 21.00
365
366		TEXT
367		8x16
368		Millennium I G200
369		TEXT 3.29 1.50
370
371		* Yes, it is slower than Millennium I.
372
373
374		Dualhead G400
375		=============
376		Driver supports dualhead G400 with some limitations:
377		+ secondary head shares videomemory with primary head. It is not problem
378		if you have 32MB of videoram, but if you have only 16MB, you may have
379		to think twice before choosing videomode (for example twice 1880x1440x32bpp
380		is not possible).
381		+ due to hardware limitation, secondary head can use only 16 and 32bpp
382		videomodes.
383		+ secondary head is not accelerated. There were bad problems with accelerated
384		XFree when secondary head used to use acceleration.
385		+ secondary head always powerups in 640x480@60-32 videomode. You have to use
386		fbset to change this mode.
387		+ secondary head always powerups in monitor mode. You have to use fbmatroxset
388		to change it to TV mode. Also, you must select at least 525 lines for
389		NTSC output and 625 lines for PAL output.
390		+ kernel is not fully multihead ready. So some things are impossible to do.
391		+ if you compiled it as module, you must insert i2c-matroxfb, matroxfb_maven
392		and matroxfb_crtc2 into kernel.
393
394
395		Dualhead G450
396		=============
397		Driver supports dualhead G450 with some limitations:
398		+ secondary head shares videomemory with primary head. It is not problem
399		if you have 32MB of videoram, but if you have only 16MB, you may have
400		to think twice before choosing videomode.
401		+ due to hardware limitation, secondary head can use only 16 and 32bpp
402		videomodes.
403		+ secondary head is not accelerated.
404		+ secondary head always powerups in 640x480@60-32 videomode. You have to use
405		fbset to change this mode.
406		+ TV output is not supported
407		+ kernel is not fully multihead ready, so some things are impossible to do.
408		+ if you compiled it as module, you must insert matroxfb_g450 and matroxfb_crtc2
409		into kernel.
410
411		--
412		Petr Vandrovec <vandrove@vc.cvut.cz>

+38

-0

debian/doc/kernel-doc/metronomefb.rst less more

	0	===========
	1	Metronomefb
	2	===========
	3
	4	Maintained by Jaya Kumar <jayakumar.lkml.gmail.com>
	5
	6	Last revised: Mar 10, 2008
	7
	8	Metronomefb is a driver for the Metronome display controller. The controller
	9	is from E-Ink Corporation. It is intended to be used to drive the E-Ink
	10	Vizplex display media. E-Ink hosts some details of this controller and the
	11	display media here http://www.e-ink.com/products/matrix/metronome.html .
	12
	13	Metronome is interfaced to the host CPU through the AMLCD interface. The
	14	host CPU generates the control information and the image in a framebuffer
	15	which is then delivered to the AMLCD interface by a host specific method.
	16	The display and error status are each pulled through individual GPIOs.
	17
	18	Metronomefb is platform independent and depends on a board specific driver
	19	to do all physical IO work. Currently, an example is implemented for the
	20	PXA board used in the AM-200 EPD devkit. This example is am200epd.c
	21
	22	Metronomefb requires waveform information which is delivered via the AMLCD
	23	interface to the metronome controller. The waveform information is expected to
	24	be delivered from userspace via the firmware class interface. The waveform file
	25	can be compressed as long as your udev or hotplug script is aware of the need
	26	to uncompress it before delivering it. metronomefb will ask for metronome.wbf
	27	which would typically go into /lib/firmware/metronome.wbf depending on your
	28	udev/hotplug setup. I have only tested with a single waveform file which was
	29	originally labeled 23P01201_60_WT0107_MTC. I do not know what it stands for.
	30	Caution should be exercised when manipulating the waveform as there may be
	31	a possibility that it could have some permanent effects on the display media.
	32	I neither have access to nor know exactly what the waveform does in terms of
	33	the physical media.
	34
	35	Metronomefb uses the deferred IO interface so that it can provide a memory
	36	mappable frame buffer. It has been tested with tinyx (Xfbdev). It is known
	37	to work at this time with xeyes, xclock, xloadimage, xpdf.

-36

~~debian/doc/kernel-doc/metronomefb.txt~~ less more

0		Metronomefb
1		-----------
2		Maintained by Jaya Kumar <jayakumar.lkml.gmail.com>
3		Last revised: Mar 10, 2008
4
5		Metronomefb is a driver for the Metronome display controller. The controller
6		is from E-Ink Corporation. It is intended to be used to drive the E-Ink
7		Vizplex display media. E-Ink hosts some details of this controller and the
8		display media here http://www.e-ink.com/products/matrix/metronome.html .
9
10		Metronome is interfaced to the host CPU through the AMLCD interface. The
11		host CPU generates the control information and the image in a framebuffer
12		which is then delivered to the AMLCD interface by a host specific method.
13		The display and error status are each pulled through individual GPIOs.
14
15		Metronomefb is platform independent and depends on a board specific driver
16		to do all physical IO work. Currently, an example is implemented for the
17		PXA board used in the AM-200 EPD devkit. This example is am200epd.c
18
19		Metronomefb requires waveform information which is delivered via the AMLCD
20		interface to the metronome controller. The waveform information is expected to
21		be delivered from userspace via the firmware class interface. The waveform file
22		can be compressed as long as your udev or hotplug script is aware of the need
23		to uncompress it before delivering it. metronomefb will ask for metronome.wbf
24		which would typically go into /lib/firmware/metronome.wbf depending on your
25		udev/hotplug setup. I have only tested with a single waveform file which was
26		originally labeled 23P01201_60_WT0107_MTC. I do not know what it stands for.
27		Caution should be exercised when manipulating the waveform as there may be
28		a possibility that it could have some permanent effects on the display media.
29		I neither have access to nor know exactly what the waveform does in terms of
30		the physical media.
31
32		Metronomefb uses the deferred IO interface so that it can provide a memory
33		mappable frame buffer. It has been tested with tinyx (Xfbdev). It is known
34		to work at this time with xeyes, xclock, xloadimage, xpdf.
35

+169

-0

debian/doc/kernel-doc/modedb.rst less more

	0	=================================
	1	modedb default video mode support
	2	=================================
	3
	4
	5	Currently all frame buffer device drivers have their own video mode databases,
	6	which is a mess and a waste of resources. The main idea of modedb is to have
	7
	8	- one routine to probe for video modes, which can be used by all frame buffer
	9	devices
	10	- one generic video mode database with a fair amount of standard videomodes
	11	(taken from XFree86)
	12	- the possibility to supply your own mode database for graphics hardware that
	13	needs non-standard modes, like amifb and Mac frame buffer drivers (which
	14	use macmodes.c)
	15
	16	When a frame buffer device receives a video= option it doesn't know, it should
	17	consider that to be a video mode option. If no frame buffer device is specified
	18	in a video= option, fbmem considers that to be a global video mode option.
	19
	20	Valid mode specifiers (mode_option argument)::
	21
	22	<xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd]
	23	<name>[-<bpp>][@<refresh>]
	24
	25	with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string.
	26	Things between square brackets are optional.
	27
	28	If 'M' is specified in the mode_option argument (after <yres> and before
	29	<bpp> and <refresh>, if specified) the timings will be calculated using
	30	VESA(TM) Coordinated Video Timings instead of looking up the mode from a table.
	31	If 'R' is specified, do a 'reduced blanking' calculation for digital displays.
	32	If 'i' is specified, calculate for an interlaced mode. And if 'm' is
	33	specified, add margins to the calculation (1.8% of xres rounded down to 8
	34	pixels and 1.8% of yres).
	35
	36	Sample usage: 1024x768M@60m - CVT timing with margins
	37
	38	DRM drivers also add options to enable or disable outputs:
	39
	40	'e' will force the display to be enabled, i.e. it will override the detection
	41	if a display is connected. 'D' will force the display to be enabled and use
	42	digital output. This is useful for outputs that have both analog and digital
	43	signals (e.g. HDMI and DVI-I). For other outputs it behaves like 'e'. If 'd'
	44	is specified the output is disabled.
	45
	46	You can additionally specify which output the options matches to.
	47	To force the VGA output to be enabled and drive a specific mode say::
	48
	49	video=VGA-1:1280x1024@60me
	50
	51	Specifying the option multiple times for different ports is possible, e.g.::
	52
	53	video=LVDS-1:d video=HDMI-1:D
	54
	55	Options can also be passed after the mode, using commas as separator.
	56
	57	Sample usage: 720x480,rotate=180 - 720x480 mode, rotated by 180 degrees
	58
	59	Valid options are::
	60
	61	- margin_top, margin_bottom, margin_left, margin_right (integer):
	62	Number of pixels in the margins, typically to deal with overscan on TVs
	63	- reflect_x (boolean): Perform an axial symmetry on the X axis
	64	- reflect_y (boolean): Perform an axial symmetry on the Y axis
	65	- rotate (integer): Rotate the initial framebuffer by x
	66	degrees. Valid values are 0, 90, 180 and 270.
	67
	68
	69	-----------------------------------------------------------------------------
	70
	71	What is the VESA(TM) Coordinated Video Timings (CVT)?
	72	=====================================================
	73
	74	From the VESA(TM) Website:
	75
	76	"The purpose of CVT is to provide a method for generating a consistent
	77	and coordinated set of standard formats, display refresh rates, and
	78	timing specifications for computer display products, both those
	79	employing CRTs, and those using other display technologies. The
	80	intention of CVT is to give both source and display manufacturers a
	81	common set of tools to enable new timings to be developed in a
	82	consistent manner that ensures greater compatibility."
	83
	84	This is the third standard approved by VESA(TM) concerning video timings. The
	85	first was the Discrete Video Timings (DVT) which is a collection of
	86	pre-defined modes approved by VESA(TM). The second is the Generalized Timing
	87	Formula (GTF) which is an algorithm to calculate the timings, given the
	88	pixelclock, the horizontal sync frequency, or the vertical refresh rate.
	89
	90	The GTF is limited by the fact that it is designed mainly for CRT displays.
	91	It artificially increases the pixelclock because of its high blanking
	92	requirement. This is inappropriate for digital display interface with its high
	93	data rate which requires that it conserves the pixelclock as much as possible.
	94	Also, GTF does not take into account the aspect ratio of the display.
	95
	96	The CVT addresses these limitations. If used with CRT's, the formula used
	97	is a derivation of GTF with a few modifications. If used with digital
	98	displays, the "reduced blanking" calculation can be used.
	99
	100	From the framebuffer subsystem perspective, new formats need not be added
	101	to the global mode database whenever a new mode is released by display
	102	manufacturers. Specifying for CVT will work for most, if not all, relatively
	103	new CRT displays and probably with most flatpanels, if 'reduced blanking'
	104	calculation is specified. (The CVT compatibility of the display can be
	105	determined from its EDID. The version 1.3 of the EDID has extra 128-byte
	106	blocks where additional timing information is placed. As of this time, there
	107	is no support yet in the layer to parse this additional blocks.)
	108
	109	CVT also introduced a new naming convention (should be seen from dmesg output)::
	110
	111	<pix>M<a>[-R]
	112
	113	where: pix = total amount of pixels in MB (xres x yres)
	114	M = always present
	115	a = aspect ratio (3 - 4:3; 4 - 5:4; 9 - 15:9, 16:9; A - 16:10)
	116	-R = reduced blanking
	117
	118	example: .48M3-R - 800x600 with reduced blanking
	119
	120	Note: VESA(TM) has restrictions on what is a standard CVT timing:
	121
	122	- aspect ratio can only be one of the above values
	123	- acceptable refresh rates are 50, 60, 70 or 85 Hz only
	124	- if reduced blanking, the refresh rate must be at 60Hz
	125
	126	If one of the above are not satisfied, the kernel will print a warning but the
	127	timings will still be calculated.
	128
	129	-----------------------------------------------------------------------------
	130
	131	To find a suitable video mode, you just call::
	132
	133	int __init fb_find_mode(struct fb_var_screeninfo *var,
	134	struct fb_info info, const char mode_option,
	135	const struct fb_videomode *db, unsigned int dbsize,
	136	const struct fb_videomode *default_mode,
	137	unsigned int default_bpp)
	138
	139	with db/dbsize your non-standard video mode database, or NULL to use the
	140	standard video mode database.
	141
	142	fb_find_mode() first tries the specified video mode (or any mode that matches,
	143	e.g. there can be multiple 640x480 modes, each of them is tried). If that
	144	fails, the default mode is tried. If that fails, it walks over all modes.
	145
	146	To specify a video mode at bootup, use the following boot options::
	147
	148	video=<driver>:<xres>x<yres>[-<bpp>][@refresh]
	149
	150	where <driver> is a name from the table below. Valid default modes can be
	151	found in linux/drivers/video/modedb.c. Check your driver's documentation.
	152	There may be more modes::
	153
	154	Drivers that support modedb boot options
	155	Boot Name Cards Supported
	156
	157	amifb - Amiga chipset frame buffer
	158	aty128fb - ATI Rage128 / Pro frame buffer
	159	atyfb - ATI Mach64 frame buffer
	160	pm2fb - Permedia 2/2V frame buffer
	161	pm3fb - Permedia 3 frame buffer
	162	sstfb - Voodoo 1/2 (SST1) chipset frame buffer
	163	tdfxfb - 3D Fx frame buffer
	164	tridentfb - Trident (Cyber)blade chipset frame buffer
	165	vt8623fb - VIA 8623 frame buffer
	166
	167	BTW, only a few fb drivers use this at the moment. Others are to follow
	168	(feel free to send patches). The DRM drivers also support this.

-151

~~debian/doc/kernel-doc/modedb.txt~~ less more

0
1
2		modedb default video mode support
3
4
5		Currently all frame buffer device drivers have their own video mode databases,
6		which is a mess and a waste of resources. The main idea of modedb is to have
7
8		- one routine to probe for video modes, which can be used by all frame buffer
9		devices
10		- one generic video mode database with a fair amount of standard videomodes
11		(taken from XFree86)
12		- the possibility to supply your own mode database for graphics hardware that
13		needs non-standard modes, like amifb and Mac frame buffer drivers (which
14		use macmodes.c)
15
16		When a frame buffer device receives a video= option it doesn't know, it should
17		consider that to be a video mode option. If no frame buffer device is specified
18		in a video= option, fbmem considers that to be a global video mode option.
19
20		Valid mode specifiers (mode_option argument):
21
22		<xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd]
23		<name>[-<bpp>][@<refresh>]
24
25		with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string.
26		Things between square brackets are optional.
27
28		If 'M' is specified in the mode_option argument (after <yres> and before
29		<bpp> and <refresh>, if specified) the timings will be calculated using
30		VESA(TM) Coordinated Video Timings instead of looking up the mode from a table.
31		If 'R' is specified, do a 'reduced blanking' calculation for digital displays.
32		If 'i' is specified, calculate for an interlaced mode. And if 'm' is
33		specified, add margins to the calculation (1.8% of xres rounded down to 8
34		pixels and 1.8% of yres).
35
36		Sample usage: 1024x768M@60m - CVT timing with margins
37
38		DRM drivers also add options to enable or disable outputs:
39
40		'e' will force the display to be enabled, i.e. it will override the detection
41		if a display is connected. 'D' will force the display to be enabled and use
42		digital output. This is useful for outputs that have both analog and digital
43		signals (e.g. HDMI and DVI-I). For other outputs it behaves like 'e'. If 'd'
44		is specified the output is disabled.
45
46		You can additionally specify which output the options matches to.
47		To force the VGA output to be enabled and drive a specific mode say:
48		video=VGA-1:1280x1024@60me
49
50		Specifying the option multiple times for different ports is possible, e.g.:
51		video=LVDS-1:d video=HDMI-1:D
52
53		*** oOo * oOo * oOo * oOo * oOo * oOo * oOo ***
54
55		What is the VESA(TM) Coordinated Video Timings (CVT)?
56
57		From the VESA(TM) Website:
58
59		"The purpose of CVT is to provide a method for generating a consistent
60		and coordinated set of standard formats, display refresh rates, and
61		timing specifications for computer display products, both those
62		employing CRTs, and those using other display technologies. The
63		intention of CVT is to give both source and display manufacturers a
64		common set of tools to enable new timings to be developed in a
65		consistent manner that ensures greater compatibility."
66
67		This is the third standard approved by VESA(TM) concerning video timings. The
68		first was the Discrete Video Timings (DVT) which is a collection of
69		pre-defined modes approved by VESA(TM). The second is the Generalized Timing
70		Formula (GTF) which is an algorithm to calculate the timings, given the
71		pixelclock, the horizontal sync frequency, or the vertical refresh rate.
72
73		The GTF is limited by the fact that it is designed mainly for CRT displays.
74		It artificially increases the pixelclock because of its high blanking
75		requirement. This is inappropriate for digital display interface with its high
76		data rate which requires that it conserves the pixelclock as much as possible.
77		Also, GTF does not take into account the aspect ratio of the display.
78
79		The CVT addresses these limitations. If used with CRT's, the formula used
80		is a derivation of GTF with a few modifications. If used with digital
81		displays, the "reduced blanking" calculation can be used.
82
83		From the framebuffer subsystem perspective, new formats need not be added
84		to the global mode database whenever a new mode is released by display
85		manufacturers. Specifying for CVT will work for most, if not all, relatively
86		new CRT displays and probably with most flatpanels, if 'reduced blanking'
87		calculation is specified. (The CVT compatibility of the display can be
88		determined from its EDID. The version 1.3 of the EDID has extra 128-byte
89		blocks where additional timing information is placed. As of this time, there
90		is no support yet in the layer to parse this additional blocks.)
91
92		CVT also introduced a new naming convention (should be seen from dmesg output):
93
94		<pix>M<a>[-R]
95
96		where: pix = total amount of pixels in MB (xres x yres)
97		M = always present
98		a = aspect ratio (3 - 4:3; 4 - 5:4; 9 - 15:9, 16:9; A - 16:10)
99		-R = reduced blanking
100
101		example: .48M3-R - 800x600 with reduced blanking
102
103		Note: VESA(TM) has restrictions on what is a standard CVT timing:
104
105		- aspect ratio can only be one of the above values
106		- acceptable refresh rates are 50, 60, 70 or 85 Hz only
107		- if reduced blanking, the refresh rate must be at 60Hz
108
109		If one of the above are not satisfied, the kernel will print a warning but the
110		timings will still be calculated.
111
112		*** oOo * oOo * oOo * oOo * oOo * oOo * oOo ***
113
114		To find a suitable video mode, you just call
115
116		int __init fb_find_mode(struct fb_var_screeninfo *var,
117		struct fb_info info, const char mode_option,
118		const struct fb_videomode *db, unsigned int dbsize,
119		const struct fb_videomode *default_mode,
120		unsigned int default_bpp)
121
122		with db/dbsize your non-standard video mode database, or NULL to use the
123		standard video mode database.
124
125		fb_find_mode() first tries the specified video mode (or any mode that matches,
126		e.g. there can be multiple 640x480 modes, each of them is tried). If that
127		fails, the default mode is tried. If that fails, it walks over all modes.
128
129		To specify a video mode at bootup, use the following boot options:
130		video=<driver>:<xres>x<yres>[-<bpp>][@refresh]
131
132		where <driver> is a name from the table below. Valid default modes can be
133		found in linux/drivers/video/modedb.c. Check your driver's documentation.
134		There may be more modes.
135
136		Drivers that support modedb boot options
137		Boot Name Cards Supported
138
139		amifb - Amiga chipset frame buffer
140		aty128fb - ATI Rage128 / Pro frame buffer
141		atyfb - ATI Mach64 frame buffer
142		pm2fb - Permedia 2/2V frame buffer
143		pm3fb - Permedia 3 frame buffer
144		sstfb - Voodoo 1/2 (SST1) chipset frame buffer
145		tdfxfb - 3D Fx frame buffer
146		tridentfb - Trident (Cyber)blade chipset frame buffer
147		vt8623fb - VIA 8623 frame buffer
148
149		BTW, only a few fb drivers use this at the moment. Others are to follow
150		(feel free to send patches). The DRM drivers also support this.

+66

-0

debian/doc/kernel-doc/pvr2fb.rst less more

	0	===============
	1	What is pvr2fb?
	2	===============
	3
	4	This is a driver for PowerVR 2 based graphics frame buffers, such as the
	5	one found in the Dreamcast.
	6
	7	Advantages:
	8
	9	* It provides a nice large console (128 cols + 48 lines with 1024x768)
	10	without using tiny, unreadable fonts (NOT on the Dreamcast)
	11	* You can run XF86_FBDev on top of /dev/fb0
	12	* Most important: boot logo :-)
	13
	14	Disadvantages:
	15
	16	* Driver is largely untested on non-Dreamcast systems.
	17
	18	Configuration
	19	=============
	20
	21	You can pass kernel command line options to pvr2fb with
	22	`video=pvr2fb:option1,option2:value2,option3` (multiple options should be
	23	separated by comma, values are separated from options by `:`).
	24
	25	Accepted options:
	26
	27	========== ==================================================================
	28	font:X default font to use. All fonts are supported, including the
	29	SUN12x22 font which is very nice at high resolutions.
	30
	31
	32	mode:X default video mode with format [xres]x[yres]-<bpp>@<refresh rate>
	33	The following video modes are supported:
	34	640x640-16@60, 640x480-24@60, 640x480-32@60. The Dreamcast
	35	defaults to 640x480-16@60. At the time of writing the
	36	24bpp and 32bpp modes function poorly. Work to fix that is
	37	ongoing
	38
	39	Note: the 640x240 mode is currently broken, and should not be
	40	used for any reason. It is only mentioned here as a reference.
	41
	42	inverse invert colors on screen (for LCD displays)
	43
	44	nomtrr disables write combining on frame buffer. This slows down driver
	45	but there is reported minor incompatibility between GUS DMA and
	46	XFree under high loads if write combining is enabled (sound
	47	dropouts). MTRR is enabled by default on systems that have it
	48	configured and that support it.
	49
	50	cable:X cable type. This can be any of the following: vga, rgb, and
	51	composite. If none is specified, we guess.
	52
	53	output:X output type. This can be any of the following: pal, ntsc, and
	54	vga. If none is specified, we guess.
	55	========== ==================================================================
	56
	57	X11
	58	===
	59
	60	XF86_FBDev has been shown to work on the Dreamcast in the past - though not yet
	61	on any 2.6 series kernel.
	62
	63	Paul Mundt <lethal@linuxdc.org>
	64
	65	Updated by Adrian McMenamin <adrian@mcmen.demon.co.uk>

-65

~~debian/doc/kernel-doc/pvr2fb.txt~~ less more

0		$Id: pvr2fb.txt,v 1.1 2001/05/24 05:09:16 mrbrown Exp $
1
2		What is pvr2fb?
3		===============
4
5		This is a driver for PowerVR 2 based graphics frame buffers, such as the
6		one found in the Dreamcast.
7
8		Advantages:
9
10		* It provides a nice large console (128 cols + 48 lines with 1024x768)
11		without using tiny, unreadable fonts (NOT on the Dreamcast)
12		* You can run XF86_FBDev on top of /dev/fb0
13		* Most important: boot logo :-)
14
15		Disadvantages:
16
17		* Driver is largely untested on non-Dreamcast systems.
18
19		Configuration
20		=============
21
22		You can pass kernel command line options to pvr2fb with
23		`video=pvr2fb:option1,option2:value2,option3' (multiple options should be
24		separated by comma, values are separated from options by `:').
25		Accepted options:
26
27		font:X - default font to use. All fonts are supported, including the
28		SUN12x22 font which is very nice at high resolutions.
29
30
31		mode:X - default video mode with format [xres]x[yres]-<bpp>@<refresh rate>
32		The following video modes are supported:
33		640x640-16@60, 640x480-24@60, 640x480-32@60. The Dreamcast
34		defaults to 640x480-16@60. At the time of writing the
35		24bpp and 32bpp modes function poorly. Work to fix that is
36		ongoing
37
38		Note: the 640x240 mode is currently broken, and should not be
39		used for any reason. It is only mentioned here as a reference.
40
41		inverse - invert colors on screen (for LCD displays)
42
43		nomtrr - disables write combining on frame buffer. This slows down driver
44		but there is reported minor incompatibility between GUS DMA and
45		XFree under high loads if write combining is enabled (sound
46		dropouts). MTRR is enabled by default on systems that have it
47		configured and that support it.
48
49		cable:X - cable type. This can be any of the following: vga, rgb, and
50		composite. If none is specified, we guess.
51
52		output:X - output type. This can be any of the following: pal, ntsc, and
53		vga. If none is specified, we guess.
54
55		X11
56		===
57
58		XF86_FBDev has been shown to work on the Dreamcast in the past - though not yet
59		on any 2.6 series kernel.
60
61		--
62		Paul Mundt <lethal@linuxdc.org>
63		Updated by Adrian McMenamin <adrian@mcmen.demon.co.uk>
64

+173

-0

debian/doc/kernel-doc/pxafb.rst less more

	0	================================
	1	Driver for PXA25x LCD controller
	2	================================
	3
	4	The driver supports the following options, either via
	5	options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in.
	6
	7	For example::
	8
	9	modprobe pxafb options=vmem:2M,mode:640x480-8,passive
	10
	11	or on the kernel command line::
	12
	13	video=pxafb:vmem:2M,mode:640x480-8,passive
	14
	15	vmem: VIDEO_MEM_SIZE
	16
	17	Amount of video memory to allocate (can be suffixed with K or M
	18	for kilobytes or megabytes)
	19
	20	mode:XRESxYRES[-BPP]
	21
	22	XRES == LCCR1_PPL + 1
	23
	24	YRES == LLCR2_LPP + 1
	25
	26	The resolution of the display in pixels
	27
	28	BPP == The bit depth. Valid values are 1, 2, 4, 8 and 16.
	29
	30	pixclock:PIXCLOCK
	31
	32	Pixel clock in picoseconds
	33
	34	left:LEFT == LCCR1_BLW + 1
	35
	36	right:RIGHT == LCCR1_ELW + 1
	37
	38	hsynclen:HSYNC == LCCR1_HSW + 1
	39
	40	upper:UPPER == LCCR2_BFW
	41
	42	lower:LOWER == LCCR2_EFR
	43
	44	vsynclen:VSYNC == LCCR2_VSW + 1
	45
	46	Display margins and sync times
	47
	48	color \| mono => LCCR0_CMS
	49
	50	umm...
	51
	52	active \| passive => LCCR0_PAS
	53
	54	Active (TFT) or Passive (STN) display
	55
	56	single \| dual => LCCR0_SDS
	57
	58	Single or dual panel passive display
	59
	60	4pix \| 8pix => LCCR0_DPD
	61
	62	4 or 8 pixel monochrome single panel data
	63
	64	hsync:HSYNC, vsync:VSYNC
	65
	66	Horizontal and vertical sync. 0 => active low, 1 => active
	67	high.
	68
	69	dpc:DPC
	70
	71	Double pixel clock. 1=>true, 0=>false
	72
	73	outputen:POLARITY
	74
	75	Output Enable Polarity. 0 => active low, 1 => active high
	76
	77	pixclockpol:POLARITY
	78
	79	pixel clock polarity
	80	0 => falling edge, 1 => rising edge
	81
	82
	83	Overlay Support for PXA27x and later LCD controllers
	84	====================================================
	85
	86	PXA27x and later processors support overlay1 and overlay2 on-top of the
	87	base framebuffer (although under-neath the base is also possible). They
	88	support palette and no-palette RGB formats, as well as YUV formats (only
	89	available on overlay2). These overlays have dedicated DMA channels and
	90	behave in a similar way as a framebuffer.
	91
	92	However, there are some differences between these overlay framebuffers
	93	and normal framebuffers, as listed below:
	94
	95	1. overlay can start at a 32-bit word aligned position within the base
	96	framebuffer, which means they have a start (x, y). This information
	97	is encoded into var->nonstd (no, var->xoffset and var->yoffset are
	98	not for such purpose).
	99
	100	2. overlay framebuffer is allocated dynamically according to specified
	101	'struct fb_var_screeninfo', the amount is decided by::
	102
	103	var->xres_virtual * var->yres_virtual * bpp
	104
	105	bpp = 16 -- for RGB565 or RGBT555
	106
	107	bpp = 24 -- for YUV444 packed
	108
	109	bpp = 24 -- for YUV444 planar
	110
	111	bpp = 16 -- for YUV422 planar (1 pixel = 1 Y + 1/2 Cb + 1/2 Cr)
	112
	113	bpp = 12 -- for YUV420 planar (1 pixel = 1 Y + 1/4 Cb + 1/4 Cr)
	114
	115	NOTE:
	116
	117	a. overlay does not support panning in x-direction, thus
	118	var->xres_virtual will always be equal to var->xres
	119
	120	b. line length of overlay(s) must be on a 32-bit word boundary,
	121	for YUV planar modes, it is a requirement for the component
	122	with minimum bits per pixel, e.g. for YUV420, Cr component
	123	for one pixel is actually 2-bits, it means the line length
	124	should be a multiple of 16-pixels
	125
	126	c. starting horizontal position (XPOS) should start on a 32-bit
	127	word boundary, otherwise the fb_check_var() will just fail.
	128
	129	d. the rectangle of the overlay should be within the base plane,
	130	otherwise fail
	131
	132	Applications should follow the sequence below to operate an overlay
	133	framebuffer:
	134
	135	a. open("/dev/fb[1-2]", ...)
	136	b. ioctl(fd, FBIOGET_VSCREENINFO, ...)
	137	c. modify 'var' with desired parameters:
	138
	139	1) var->xres and var->yres
	140	2) larger var->yres_virtual if more memory is required,
	141	usually for double-buffering
	142	3) var->nonstd for starting (x, y) and color format
	143	4) var->{red, green, blue, transp} if RGB mode is to be used
	144
	145	d. ioctl(fd, FBIOPUT_VSCREENINFO, ...)
	146	e. ioctl(fd, FBIOGET_FSCREENINFO, ...)
	147	f. mmap
	148	g. ...
	149
	150	3. for YUV planar formats, these are actually not supported within the
	151	framebuffer framework, application has to take care of the offsets
	152	and lengths of each component within the framebuffer.
	153
	154	4. var->nonstd is used to pass starting (x, y) position and color format,
	155	the detailed bit fields are shown below::
	156
	157	31 23 20 10 0
	158	+-----------------+---+----------+----------+
	159	\| ... unused ... \|FOR\| XPOS \| YPOS \|
	160	+-----------------+---+----------+----------+
	161
	162	FOR - color format, as defined by OVERLAY_FORMAT_* in pxafb.h
	163
	164	- 0 - RGB
	165	- 1 - YUV444 PACKED
	166	- 2 - YUV444 PLANAR
	167	- 3 - YUV422 PLANAR
	168	- 4 - YUR420 PLANAR
	169
	170	XPOS - starting horizontal position
	171
	172	YPOS - starting vertical position

-142

~~debian/doc/kernel-doc/pxafb.txt~~ less more

0		Driver for PXA25x LCD controller
1		================================
2
3		The driver supports the following options, either via
4		options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in.
5
6		For example:
7		modprobe pxafb options=vmem:2M,mode:640x480-8,passive
8		or on the kernel command line
9		video=pxafb:vmem:2M,mode:640x480-8,passive
10
11		vmem: VIDEO_MEM_SIZE
12		Amount of video memory to allocate (can be suffixed with K or M
13		for kilobytes or megabytes)
14
15		mode:XRESxYRES[-BPP]
16		XRES == LCCR1_PPL + 1
17		YRES == LLCR2_LPP + 1
18		The resolution of the display in pixels
19		BPP == The bit depth. Valid values are 1, 2, 4, 8 and 16.
20
21		pixclock:PIXCLOCK
22		Pixel clock in picoseconds
23
24		left:LEFT == LCCR1_BLW + 1
25		right:RIGHT == LCCR1_ELW + 1
26		hsynclen:HSYNC == LCCR1_HSW + 1
27		upper:UPPER == LCCR2_BFW
28		lower:LOWER == LCCR2_EFR
29		vsynclen:VSYNC == LCCR2_VSW + 1
30		Display margins and sync times
31
32		color \| mono => LCCR0_CMS
33		umm...
34
35		active \| passive => LCCR0_PAS
36		Active (TFT) or Passive (STN) display
37
38		single \| dual => LCCR0_SDS
39		Single or dual panel passive display
40
41		4pix \| 8pix => LCCR0_DPD
42		4 or 8 pixel monochrome single panel data
43
44		hsync:HSYNC
45		vsync:VSYNC
46		Horizontal and vertical sync. 0 => active low, 1 => active
47		high.
48
49		dpc:DPC
50		Double pixel clock. 1=>true, 0=>false
51
52		outputen:POLARITY
53		Output Enable Polarity. 0 => active low, 1 => active high
54
55		pixclockpol:POLARITY
56		pixel clock polarity
57		0 => falling edge, 1 => rising edge
58
59
60		Overlay Support for PXA27x and later LCD controllers
61		====================================================
62
63		PXA27x and later processors support overlay1 and overlay2 on-top of the
64		base framebuffer (although under-neath the base is also possible). They
65		support palette and no-palette RGB formats, as well as YUV formats (only
66		available on overlay2). These overlays have dedicated DMA channels and
67		behave in a similar way as a framebuffer.
68
69		However, there are some differences between these overlay framebuffers
70		and normal framebuffers, as listed below:
71
72		1. overlay can start at a 32-bit word aligned position within the base
73		framebuffer, which means they have a start (x, y). This information
74		is encoded into var->nonstd (no, var->xoffset and var->yoffset are
75		not for such purpose).
76
77		2. overlay framebuffer is allocated dynamically according to specified
78		'struct fb_var_screeninfo', the amount is decided by:
79
80		var->xres_virtual * var->yres_virtual * bpp
81
82		bpp = 16 -- for RGB565 or RGBT555
83		= 24 -- for YUV444 packed
84		= 24 -- for YUV444 planar
85		= 16 -- for YUV422 planar (1 pixel = 1 Y + 1/2 Cb + 1/2 Cr)
86		= 12 -- for YUV420 planar (1 pixel = 1 Y + 1/4 Cb + 1/4 Cr)
87
88		NOTE:
89
90		a. overlay does not support panning in x-direction, thus
91		var->xres_virtual will always be equal to var->xres
92
93		b. line length of overlay(s) must be on a 32-bit word boundary,
94		for YUV planar modes, it is a requirement for the component
95		with minimum bits per pixel, e.g. for YUV420, Cr component
96		for one pixel is actually 2-bits, it means the line length
97		should be a multiple of 16-pixels
98
99		c. starting horizontal position (XPOS) should start on a 32-bit
100		word boundary, otherwise the fb_check_var() will just fail.
101
102		d. the rectangle of the overlay should be within the base plane,
103		otherwise fail
104
105		Applications should follow the sequence below to operate an overlay
106		framebuffer:
107
108		a. open("/dev/fb[1-2]", ...)
109		b. ioctl(fd, FBIOGET_VSCREENINFO, ...)
110		c. modify 'var' with desired parameters:
111		1) var->xres and var->yres
112		2) larger var->yres_virtual if more memory is required,
113		usually for double-buffering
114		3) var->nonstd for starting (x, y) and color format
115		4) var->{red, green, blue, transp} if RGB mode is to be used
116		d. ioctl(fd, FBIOPUT_VSCREENINFO, ...)
117		e. ioctl(fd, FBIOGET_FSCREENINFO, ...)
118		f. mmap
119		g. ...
120
121		3. for YUV planar formats, these are actually not supported within the
122		framebuffer framework, application has to take care of the offsets
123		and lengths of each component within the framebuffer.
124
125		4. var->nonstd is used to pass starting (x, y) position and color format,
126		the detailed bit fields are shown below:
127
128		31 23 20 10 0
129		+-----------------+---+----------+----------+
130		\| ... unused ... \|FOR\| XPOS \| YPOS \|
131		+-----------------+---+----------+----------+
132
133		FOR - color format, as defined by OVERLAY_FORMAT_* in pxafb.h
134		0 - RGB
135		1 - YUV444 PACKED
136		2 - YUV444 PLANAR
137		3 - YUV422 PLANAR
138		4 - YUR420 PLANAR
139
140		XPOS - starting horizontal position
141		YPOS - starting vertical position

+82

-0

debian/doc/kernel-doc/s3fb.rst less more

	0	===========================================
	1	s3fb - fbdev driver for S3 Trio/Virge chips
	2	===========================================
	3
	4
	5	Supported Hardware
	6	==================
	7
	8	S3 Trio32
	9	S3 Trio64 (and variants V+, UV+, V2/DX, V2/GX)
	10	S3 Virge (and variants VX, DX, GX and GX2+)
	11	S3 Plato/PX (completely untested)
	12	S3 Aurora64V+ (completely untested)
	13
	14	- only PCI bus supported
	15	- only BIOS initialized VGA devices supported
	16	- probably not working on big endian
	17
	18	I tested s3fb on Trio64 (plain, V+ and V2/DX) and Virge (plain, VX, DX),
	19	all on i386.
	20
	21
	22	Supported Features
	23	==================
	24
	25	* 4 bpp pseudocolor modes (with 18bit palette, two variants)
	26	* 8 bpp pseudocolor mode (with 18bit palette)
	27	* 16 bpp truecolor modes (RGB 555 and RGB 565)
	28	* 24 bpp truecolor mode (RGB 888) on (only on Virge VX)
	29	* 32 bpp truecolor mode (RGB 888) on (not on Virge VX)
	30	* text mode (activated by bpp = 0)
	31	* interlaced mode variant (not available in text mode)
	32	* doublescan mode variant (not available in text mode)
	33	* panning in both directions
	34	* suspend/resume support
	35	* DPMS support
	36
	37	Text mode is supported even in higher resolutions, but there is limitation to
	38	lower pixclocks (maximum usually between 50-60 MHz, depending on specific
	39	hardware, i get best results from plain S3 Trio32 card - about 75 MHz). This
	40	limitation is not enforced by driver. Text mode supports 8bit wide fonts only
	41	(hardware limitation) and 16bit tall fonts (driver limitation). Text mode
	42	support is broken on S3 Trio64 V2/DX.
	43
	44	There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
	45	packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
	46	with interleaved planes (1 byte interleave), MSB first. Both modes support
	47	8bit wide fonts only (driver limitation).
	48
	49	Suspend/resume works on systems that initialize video card during resume and
	50	if device is active (for example used by fbcon).
	51
	52
	53	Missing Features
	54	================
	55	(alias TODO list)
	56
	57	* secondary (not initialized by BIOS) device support
	58	* big endian support
	59	* Zorro bus support
	60	* MMIO support
	61	* 24 bpp mode support on more cards
	62	* support for fontwidths != 8 in 4 bpp modes
	63	* support for fontheight != 16 in text mode
	64	* composite and external sync (is anyone able to test this?)
	65	* hardware cursor
	66	* video overlay support
	67	* vsync synchronization
	68	* feature connector support
	69	* acceleration support (8514-like 2D, Virge 3D, busmaster transfers)
	70	* better values for some magic registers (performance issues)
	71
	72
	73	Known bugs
	74	==========
	75
	76	* cursor disable in text mode doesn't work
	77	* text mode broken on S3 Trio64 V2/DX
	78
	79
	80	--
	81	Ondrej Zajicek <santiago@crfreenet.org>

-82

~~debian/doc/kernel-doc/s3fb.txt~~ less more

0
1		s3fb - fbdev driver for S3 Trio/Virge chips
2		===========================================
3
4
5		Supported Hardware
6		==================
7
8		S3 Trio32
9		S3 Trio64 (and variants V+, UV+, V2/DX, V2/GX)
10		S3 Virge (and variants VX, DX, GX and GX2+)
11		S3 Plato/PX (completely untested)
12		S3 Aurora64V+ (completely untested)
13
14		- only PCI bus supported
15		- only BIOS initialized VGA devices supported
16		- probably not working on big endian
17
18		I tested s3fb on Trio64 (plain, V+ and V2/DX) and Virge (plain, VX, DX),
19		all on i386.
20
21
22		Supported Features
23		==================
24
25		* 4 bpp pseudocolor modes (with 18bit palette, two variants)
26		* 8 bpp pseudocolor mode (with 18bit palette)
27		* 16 bpp truecolor modes (RGB 555 and RGB 565)
28		* 24 bpp truecolor mode (RGB 888) on (only on Virge VX)
29		* 32 bpp truecolor mode (RGB 888) on (not on Virge VX)
30		* text mode (activated by bpp = 0)
31		* interlaced mode variant (not available in text mode)
32		* doublescan mode variant (not available in text mode)
33		* panning in both directions
34		* suspend/resume support
35		* DPMS support
36
37		Text mode is supported even in higher resolutions, but there is limitation to
38		lower pixclocks (maximum usually between 50-60 MHz, depending on specific
39		hardware, i get best results from plain S3 Trio32 card - about 75 MHz). This
40		limitation is not enforced by driver. Text mode supports 8bit wide fonts only
41		(hardware limitation) and 16bit tall fonts (driver limitation). Text mode
42		support is broken on S3 Trio64 V2/DX.
43
44		There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
45		packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
46		with interleaved planes (1 byte interleave), MSB first. Both modes support
47		8bit wide fonts only (driver limitation).
48
49		Suspend/resume works on systems that initialize video card during resume and
50		if device is active (for example used by fbcon).
51
52
53		Missing Features
54		================
55		(alias TODO list)
56
57		* secondary (not initialized by BIOS) device support
58		* big endian support
59		* Zorro bus support
60		* MMIO support
61		* 24 bpp mode support on more cards
62		* support for fontwidths != 8 in 4 bpp modes
63		* support for fontheight != 16 in text mode
64		* composite and external sync (is anyone able to test this?)
65		* hardware cursor
66		* video overlay support
67		* vsync synchronization
68		* feature connector support
69		* acceleration support (8514-like 2D, Virge 3D, busmaster transfers)
70		* better values for some magic registers (performance issues)
71
72
73		Known bugs
74		==========
75
76		* cursor disable in text mode doesn't work
77		* text mode broken on S3 Trio64 V2/DX
78
79
80		--
81		Ondrej Zajicek <santiago@crfreenet.org>

+40

-0

debian/doc/kernel-doc/sa1100fb.rst less more

	0	=================
	1	What is sa1100fb?
	2	=================
	3
	4	.. [This file is cloned from VesaFB/matroxfb]
	5
	6
	7	This is a driver for a graphic framebuffer for the SA-1100 LCD
	8	controller.
	9
	10	Configuration
	11	==============
	12
	13	For most common passive displays, giving the option::
	14
	15	video=sa1100fb:bpp:<value>,lccr0:<value>,lccr1:<value>,lccr2:<value>,lccr3:<value>
	16
	17	on the kernel command line should be enough to configure the
	18	controller. The bits per pixel (bpp) value should be 4, 8, 12, or
	19	16. LCCR values are display-specific and should be computed as
	20	documented in the SA-1100 Developer's Manual, Section 11.7. Dual-panel
	21	displays are supported as long as the SDS bit is set in LCCR0; GPIO<9:2>
	22	are used for the lower panel.
	23
	24	For active displays or displays requiring additional configuration
	25	(controlling backlights, powering on the LCD, etc.), the command line
	26	options may not be enough to configure the display. Adding sections to
	27	sa1100fb_init_fbinfo(), sa1100fb_activate_var(),
	28	sa1100fb_disable_lcd_controller(), and sa1100fb_enable_lcd_controller()
	29	will probably be necessary.
	30
	31	Accepted options::
	32
	33	bpp:<value> Configure for <value> bits per pixel
	34	lccr0:<value> Configure LCD control register 0 (11.7.3)
	35	lccr1:<value> Configure LCD control register 1 (11.7.4)
	36	lccr2:<value> Configure LCD control register 2 (11.7.5)
	37	lccr3:<value> Configure LCD control register 3 (11.7.6)
	38
	39	Mark Huang <mhuang@livetoy.com>

-39

~~debian/doc/kernel-doc/sa1100fb.txt~~ less more

0		[This file is cloned from VesaFB/matroxfb]
1
2		What is sa1100fb?
3		=================
4
5		This is a driver for a graphic framebuffer for the SA-1100 LCD
6		controller.
7
8		Configuration
9		==============
10
11		For most common passive displays, giving the option
12
13		video=sa1100fb:bpp:<value>,lccr0:<value>,lccr1:<value>,lccr2:<value>,lccr3:<value>
14
15		on the kernel command line should be enough to configure the
16		controller. The bits per pixel (bpp) value should be 4, 8, 12, or
17		16. LCCR values are display-specific and should be computed as
18		documented in the SA-1100 Developer's Manual, Section 11.7. Dual-panel
19		displays are supported as long as the SDS bit is set in LCCR0; GPIO<9:2>
20		are used for the lower panel.
21
22		For active displays or displays requiring additional configuration
23		(controlling backlights, powering on the LCD, etc.), the command line
24		options may not be enough to configure the display. Adding sections to
25		sa1100fb_init_fbinfo(), sa1100fb_activate_var(),
26		sa1100fb_disable_lcd_controller(), and sa1100fb_enable_lcd_controller()
27		will probably be necessary.
28
29		Accepted options:
30
31		bpp:<value> Configure for <value> bits per pixel
32		lccr0:<value> Configure LCD control register 0 (11.7.3)
33		lccr1:<value> Configure LCD control register 1 (11.7.4)
34		lccr2:<value> Configure LCD control register 2 (11.7.5)
35		lccr3:<value> Configure LCD control register 3 (11.7.6)
36
37		--
38		Mark Huang <mhuang@livetoy.com>

+130

-0

debian/doc/kernel-doc/sh7760fb.rst less more

	0	================================================
	1	SH7760/SH7763 integrated LCDC Framebuffer driver
	2	================================================
	3
	4	0. Overview
	5	-----------
	6	The SH7760/SH7763 have an integrated LCD Display controller (LCDC) which
	7	supports (in theory) resolutions ranging from 1x1 to 1024x1024,
	8	with color depths ranging from 1 to 16 bits, on STN, DSTN and TFT Panels.
	9
	10	Caveats:
	11
	12	* Framebuffer memory must be a large chunk allocated at the top
	13	of Area3 (HW requirement). Because of this requirement you should NOT
	14	make the driver a module since at runtime it may become impossible to
	15	get a large enough contiguous chunk of memory.
	16
	17	* The driver does not support changing resolution while loaded
	18	(displays aren't hotpluggable anyway)
	19
	20	* Heavy flickering may be observed
	21	a) if you're using 15/16bit color modes at >= 640x480 px resolutions,
	22	b) during PCMCIA (or any other slow bus) activity.
	23
	24	* Rotation works only 90degress clockwise, and only if horizontal
	25	resolution is <= 320 pixels.
	26
	27	Files:
	28	- drivers/video/sh7760fb.c
	29	- include/asm-sh/sh7760fb.h
	30	- Documentation/fb/sh7760fb.rst
	31
	32	1. Platform setup
	33	-----------------
	34	SH7760:
	35	Video data is fetched via the DMABRG DMA engine, so you have to
	36	configure the SH DMAC for DMABRG mode (write 0x94808080 to the
	37	DMARSRA register somewhere at boot).
	38
	39	PFC registers PCCR and PCDR must be set to peripheral mode.
	40	(write zeros to both).
	41
	42	The driver does NOT do the above for you since board setup is, well, job
	43	of the board setup code.
	44
	45	2. Panel definitions
	46	--------------------
	47	The LCDC must explicitly be told about the type of LCD panel
	48	attached. Data must be wrapped in a "struct sh7760fb_platdata" and
	49	passed to the driver as platform_data.
	50
	51	Suggest you take a closer look at the SH7760 Manual, Section 30.
	52	(http://documentation.renesas.com/eng/products/mpumcu/e602291_sh7760.pdf)
	53
	54	The following code illustrates what needs to be done to
	55	get the framebuffer working on a 640x480 TFT::
	56
	57	#include <linux/fb.h>
	58	#include <asm/sh7760fb.h>
	59
	60	/*
	61	* NEC NL6440bc26-01 640x480 TFT
	62	* dotclock 25175 kHz
	63	* Xres 640 Yres 480
	64	* Htotal 800 Vtotal 525
	65	* HsynStart 656 VsynStart 490
	66	* HsynLenn 30 VsynLenn 2
	67	*
	68	* The linux framebuffer layer does not use the syncstart/synclen
	69	* values but right/left/upper/lower margin values. The comments
	70	* for the x_margin explain how to calculate those from given
	71	* panel sync timings.
	72	*/
	73	static struct fb_videomode nl6448bc26 = {
	74	.name = "NL6448BC26",
	75	.refresh = 60,
	76	.xres = 640,
	77	.yres = 480,
	78	.pixclock = 39683, /* in picoseconds! */
	79	.hsync_len = 30,
	80	.vsync_len = 2,
	81	.left_margin = 114, /* HTOT - (HSYNSLEN + HSYNSTART) */
	82	.right_margin = 16, /* HSYNSTART - XRES */
	83	.upper_margin = 33, /* VTOT - (VSYNLEN + VSYNSTART) */
	84	.lower_margin = 10, /* VSYNSTART - YRES */
	85	.sync = FB_SYNC_HOR_HIGH_ACT \| FB_SYNC_VERT_HIGH_ACT,
	86	.vmode = FB_VMODE_NONINTERLACED,
	87	.flag = 0,
	88	};
	89
	90	static struct sh7760fb_platdata sh7760fb_nl6448 = {
	91	.def_mode = &nl6448bc26,
	92	.ldmtr = LDMTR_TFT_COLOR_16, /* 16bit TFT panel */
	93	.lddfr = LDDFR_8BPP, /* we want 8bit output */
	94	.ldpmmr = 0x0070,
	95	.ldpspr = 0x0500,
	96	.ldaclnr = 0,
	97	.ldickr = LDICKR_CLKSRC(LCDC_CLKSRC_EXTERNAL) \|
	98	LDICKR_CLKDIV(1),
	99	.rotate = 0,
	100	.novsync = 1,
	101	.blank = NULL,
	102	};
	103
	104	/* SH7760:
	105	* 0xFE300800: 256 * 4byte xRGB palette ram
	106	* 0xFE300C00: 42 bytes ctrl registers
	107	*/
	108	static struct resource sh7760_lcdc_res[] = {
	109	[0] = {
	110	.start = 0xFE300800,
	111	.end = 0xFE300CFF,
	112	.flags = IORESOURCE_MEM,
	113	},
	114	[1] = {
	115	.start = 65,
	116	.end = 65,
	117	.flags = IORESOURCE_IRQ,
	118	},
	119	};
	120
	121	static struct platform_device sh7760_lcdc_dev = {
	122	.dev = {
	123	.platform_data = &sh7760fb_nl6448,
	124	},
	125	.name = "sh7760-lcdc",
	126	.id = -1,
	127	.resource = sh7760_lcdc_res,
	128	.num_resources = ARRAY_SIZE(sh7760_lcdc_res),
	129	};

-131

~~debian/doc/kernel-doc/sh7760fb.txt~~ less more

0		SH7760/SH7763 integrated LCDC Framebuffer driver
1		================================================
2
3		0. Overview
4		-----------
5		The SH7760/SH7763 have an integrated LCD Display controller (LCDC) which
6		supports (in theory) resolutions ranging from 1x1 to 1024x1024,
7		with color depths ranging from 1 to 16 bits, on STN, DSTN and TFT Panels.
8
9		Caveats:
10		* Framebuffer memory must be a large chunk allocated at the top
11		of Area3 (HW requirement). Because of this requirement you should NOT
12		make the driver a module since at runtime it may become impossible to
13		get a large enough contiguous chunk of memory.
14
15		* The driver does not support changing resolution while loaded
16		(displays aren't hotpluggable anyway)
17
18		* Heavy flickering may be observed
19		a) if you're using 15/16bit color modes at >= 640x480 px resolutions,
20		b) during PCMCIA (or any other slow bus) activity.
21
22		* Rotation works only 90degress clockwise, and only if horizontal
23		resolution is <= 320 pixels.
24
25		files: drivers/video/sh7760fb.c
26		include/asm-sh/sh7760fb.h
27		Documentation/fb/sh7760fb.txt
28
29		1. Platform setup
30		-----------------
31		SH7760:
32		Video data is fetched via the DMABRG DMA engine, so you have to
33		configure the SH DMAC for DMABRG mode (write 0x94808080 to the
34		DMARSRA register somewhere at boot).
35
36		PFC registers PCCR and PCDR must be set to peripheral mode.
37		(write zeros to both).
38
39		The driver does NOT do the above for you since board setup is, well, job
40		of the board setup code.
41
42		2. Panel definitions
43		--------------------
44		The LCDC must explicitly be told about the type of LCD panel
45		attached. Data must be wrapped in a "struct sh7760fb_platdata" and
46		passed to the driver as platform_data.
47
48		Suggest you take a closer look at the SH7760 Manual, Section 30.
49		(http://documentation.renesas.com/eng/products/mpumcu/e602291_sh7760.pdf)
50
51		The following code illustrates what needs to be done to
52		get the framebuffer working on a 640x480 TFT:
53
54		====================== cut here ======================================
55
56		#include <linux/fb.h>
57		#include <asm/sh7760fb.h>
58
59		/*
60		* NEC NL6440bc26-01 640x480 TFT
61		* dotclock 25175 kHz
62		* Xres 640 Yres 480
63		* Htotal 800 Vtotal 525
64		* HsynStart 656 VsynStart 490
65		* HsynLenn 30 VsynLenn 2
66		*
67		* The linux framebuffer layer does not use the syncstart/synclen
68		* values but right/left/upper/lower margin values. The comments
69		* for the x_margin explain how to calculate those from given
70		* panel sync timings.
71		*/
72		static struct fb_videomode nl6448bc26 = {
73		.name = "NL6448BC26",
74		.refresh = 60,
75		.xres = 640,
76		.yres = 480,
77		.pixclock = 39683, /* in picoseconds! */
78		.hsync_len = 30,
79		.vsync_len = 2,
80		.left_margin = 114, /* HTOT - (HSYNSLEN + HSYNSTART) */
81		.right_margin = 16, /* HSYNSTART - XRES */
82		.upper_margin = 33, /* VTOT - (VSYNLEN + VSYNSTART) */
83		.lower_margin = 10, /* VSYNSTART - YRES */
84		.sync = FB_SYNC_HOR_HIGH_ACT \| FB_SYNC_VERT_HIGH_ACT,
85		.vmode = FB_VMODE_NONINTERLACED,
86		.flag = 0,
87		};
88
89		static struct sh7760fb_platdata sh7760fb_nl6448 = {
90		.def_mode = &nl6448bc26,
91		.ldmtr = LDMTR_TFT_COLOR_16, /* 16bit TFT panel */
92		.lddfr = LDDFR_8BPP, /* we want 8bit output */
93		.ldpmmr = 0x0070,
94		.ldpspr = 0x0500,
95		.ldaclnr = 0,
96		.ldickr = LDICKR_CLKSRC(LCDC_CLKSRC_EXTERNAL) \|
97		LDICKR_CLKDIV(1),
98		.rotate = 0,
99		.novsync = 1,
100		.blank = NULL,
101		};
102
103		/* SH7760:
104		* 0xFE300800: 256 * 4byte xRGB palette ram
105		* 0xFE300C00: 42 bytes ctrl registers
106		*/
107		static struct resource sh7760_lcdc_res[] = {
108		[0] = {
109		.start = 0xFE300800,
110		.end = 0xFE300CFF,
111		.flags = IORESOURCE_MEM,
112		},
113		[1] = {
114		.start = 65,
115		.end = 65,
116		.flags = IORESOURCE_IRQ,
117		},
118		};
119
120		static struct platform_device sh7760_lcdc_dev = {
121		.dev = {
122		.platform_data = &sh7760fb_nl6448,
123		},
124		.name = "sh7760-lcdc",
125		.id = -1,
126		.resource = sh7760_lcdc_res,
127		.num_resources = ARRAY_SIZE(sh7760_lcdc_res),
128		};
129
130		====================== cut here ======================================

+160

-0

debian/doc/kernel-doc/sisfb.rst less more

	0	==============
	1	What is sisfb?
	2	==============
	3
	4	sisfb is a framebuffer device driver for SiS (Silicon Integrated Systems)
	5	graphics chips. Supported are:
	6
	7	- SiS 300 series: SiS 300/305, 540, 630(S), 730(S)
	8	- SiS 315 series: SiS 315/H/PRO, 55x, (M)65x, 740, (M)661(F/M)X, (M)741(GX)
	9	- SiS 330 series: SiS 330 ("Xabre"), (M)760
	10
	11
	12	Why do I need a framebuffer driver?
	13	===================================
	14
	15	sisfb is eg. useful if you want a high-resolution text console. Besides that,
	16	sisfb is required to run DirectFB (which comes with an additional, dedicated
	17	driver for the 315 series).
	18
	19	On the 300 series, sisfb on kernels older than 2.6.3 furthermore plays an
	20	important role in connection with DRM/DRI: Sisfb manages the memory heap
	21	used by DRM/DRI for 3D texture and other data. This memory management is
	22	required for using DRI/DRM.
	23
	24	Kernels >= around 2.6.3 do not need sisfb any longer for DRI/DRM memory
	25	management. The SiS DRM driver has been updated and features a memory manager
	26	of its own (which will be used if sisfb is not compiled). So unless you want
	27	a graphical console, you don't need sisfb on kernels >=2.6.3.
	28
	29	Sidenote: Since this seems to be a commonly made mistake: sisfb and vesafb
	30	cannot be active at the same time! Do only select one of them in your kernel
	31	configuration.
	32
	33
	34	How are parameters passed to sisfb?
	35	===================================
	36
	37	Well, it depends: If compiled statically into the kernel, use lilo's append
	38	statement to add the parameters to the kernel command line. Please see lilo's
	39	(or GRUB's) documentation for more information. If sisfb is a kernel module,
	40	parameters are given with the modprobe (or insmod) command.
	41
	42	Example for sisfb as part of the static kernel: Add the following line to your
	43	lilo.conf::
	44
	45	append="video=sisfb:mode:1024x768x16,mem:12288,rate:75"
	46
	47	Example for sisfb as a module: Start sisfb by typing::
	48
	49	modprobe sisfb mode=1024x768x16 rate=75 mem=12288
	50
	51	A common mistake is that folks use a wrong parameter format when using the
	52	driver compiled into the kernel. Please note: If compiled into the kernel,
	53	the parameter format is video=sisfb:mode:none or video=sisfb:mode:1024x768x16
	54	(or whatever mode you want to use, alternatively using any other format
	55	described above or the vesa keyword instead of mode). If compiled as a module,
	56	the parameter format reads mode=none or mode=1024x768x16 (or whatever mode you
	57	want to use). Using a "=" for a ":" (and vice versa) is a huge difference!
	58	Additionally: If you give more than one argument to the in-kernel sisfb, the
	59	arguments are separated with ",". For example::
	60
	61	video=sisfb:mode:1024x768x16,rate:75,mem:12288
	62
	63
	64	How do I use it?
	65	================
	66
	67	Preface statement: This file only covers very little of the driver's
	68	capabilities and features. Please refer to the author's and maintainer's
	69	website at http://www.winischhofer.net/linuxsisvga.shtml for more
	70	information. Additionally, "modinfo sisfb" gives an overview over all
	71	supported options including some explanation.
	72
	73	The desired display mode can be specified using the keyword "mode" with
	74	a parameter in one of the following formats:
	75
	76	- XxYxDepth or
	77	- XxY-Depth or
	78	- XxY-Depth@Rate or
	79	- XxY
	80	- or simply use the VESA mode number in hexadecimal or decimal.
	81
	82	For example: 1024x768x16, 1024x768-16@75, 1280x1024-16. If no depth is
	83	specified, it defaults to 8. If no rate is given, it defaults to 60Hz. Depth 32
	84	means 24bit color depth (but 32 bit framebuffer depth, which is not relevant
	85	to the user).
	86
	87	Additionally, sisfb understands the keyword "vesa" followed by a VESA mode
	88	number in decimal or hexadecimal. For example: vesa=791 or vesa=0x117. Please
	89	use either "mode" or "vesa" but not both.
	90
	91	Linux 2.4 only: If no mode is given, sisfb defaults to "no mode" (mode=none) if
	92	compiled as a module; if sisfb is statically compiled into the kernel, it
	93	defaults to 800x600x8 unless CRT2 type is LCD, in which case the LCD's native
	94	resolution is used. If you want to switch to a different mode, use the fbset
	95	shell command.
	96
	97	Linux 2.6 only: If no mode is given, sisfb defaults to 800x600x8 unless CRT2
	98	type is LCD, in which case it defaults to the LCD's native resolution. If
	99	you want to switch to another mode, use the stty shell command.
	100
	101	You should compile in both vgacon (to boot if you remove you SiS card from
	102	your system) and sisfb (for graphics mode). Under Linux 2.6, also "Framebuffer
	103	console support" (fbcon) is needed for a graphical console.
	104
	105	You should not compile-in vesafb. And please do not use the "vga=" keyword
	106	in lilo's or grub's configuration file; mode selection is done using the
	107	"mode" or "vesa" keywords as a parameter. See above and below.
	108
	109
	110	X11
	111	===
	112
	113	If using XFree86 or X.org, it is recommended that you don't use the "fbdev"
	114	driver but the dedicated "sis" X driver. The "sis" X driver and sisfb are
	115	developed by the same person (Thomas Winischhofer) and cooperate well with
	116	each other.
	117
	118
	119	SVGALib
	120	=======
	121
	122	SVGALib, if directly accessing the hardware, never restores the screen
	123	correctly, especially on laptops or if the output devices are LCD or TV.
	124	Therefore, use the chipset "FBDEV" in SVGALib configuration. This will make
	125	SVGALib use the framebuffer device for mode switches and restoration.
	126
	127
	128	Configuration
	129	=============
	130
	131	(Some) accepted options:
	132
	133	========= ==================================================================
	134	off Disable sisfb. This option is only understood if sisfb is
	135	in-kernel, not a module.
	136	mem:X size of memory for the console, rest will be used for DRI/DRM. X
	137	is in kilobytes. On 300 series, the default is 4096, 8192 or
	138	16384 (each in kilobyte) depending on how much video ram the card
	139	has. On 315/330 series, the default is the maximum available ram
	140	(since DRI/DRM is not supported for these chipsets).
	141	noaccel do not use 2D acceleration engine. (Default: use acceleration)
	142	noypan disable y-panning and scroll by redrawing the entire screen.
	143	This is much slower than y-panning. (Default: use y-panning)
	144	vesa:X selects startup videomode. X is number from 0 to 0x1FF and
	145	represents the VESA mode number (can be given in decimal or
	146	hexadecimal form, the latter prefixed with "0x").
	147	mode:X selects startup videomode. Please see above for the format of
	148	"X".
	149	========= ==================================================================
	150
	151	Boolean options such as "noaccel" or "noypan" are to be given without a
	152	parameter if sisfb is in-kernel (for example "video=sisfb:noypan). If
	153	sisfb is a module, these are to be set to 1 (for example "modprobe sisfb
	154	noypan=1").
	155
	156
	157	Thomas Winischhofer <thomas@winischhofer.net>
	158
	159	May 27, 2004

-158

~~debian/doc/kernel-doc/sisfb.txt~~ less more

0
1		What is sisfb?
2		==============
3
4		sisfb is a framebuffer device driver for SiS (Silicon Integrated Systems)
5		graphics chips. Supported are:
6
7		- SiS 300 series: SiS 300/305, 540, 630(S), 730(S)
8		- SiS 315 series: SiS 315/H/PRO, 55x, (M)65x, 740, (M)661(F/M)X, (M)741(GX)
9		- SiS 330 series: SiS 330 ("Xabre"), (M)760
10
11
12		Why do I need a framebuffer driver?
13		===================================
14
15		sisfb is eg. useful if you want a high-resolution text console. Besides that,
16		sisfb is required to run DirectFB (which comes with an additional, dedicated
17		driver for the 315 series).
18
19		On the 300 series, sisfb on kernels older than 2.6.3 furthermore plays an
20		important role in connection with DRM/DRI: Sisfb manages the memory heap
21		used by DRM/DRI for 3D texture and other data. This memory management is
22		required for using DRI/DRM.
23
24		Kernels >= around 2.6.3 do not need sisfb any longer for DRI/DRM memory
25		management. The SiS DRM driver has been updated and features a memory manager
26		of its own (which will be used if sisfb is not compiled). So unless you want
27		a graphical console, you don't need sisfb on kernels >=2.6.3.
28
29		Sidenote: Since this seems to be a commonly made mistake: sisfb and vesafb
30		cannot be active at the same time! Do only select one of them in your kernel
31		configuration.
32
33
34		How are parameters passed to sisfb?
35		===================================
36
37		Well, it depends: If compiled statically into the kernel, use lilo's append
38		statement to add the parameters to the kernel command line. Please see lilo's
39		(or GRUB's) documentation for more information. If sisfb is a kernel module,
40		parameters are given with the modprobe (or insmod) command.
41
42		Example for sisfb as part of the static kernel: Add the following line to your
43		lilo.conf:
44
45		append="video=sisfb:mode:1024x768x16,mem:12288,rate:75"
46
47		Example for sisfb as a module: Start sisfb by typing
48
49		modprobe sisfb mode=1024x768x16 rate=75 mem=12288
50
51		A common mistake is that folks use a wrong parameter format when using the
52		driver compiled into the kernel. Please note: If compiled into the kernel,
53		the parameter format is video=sisfb:mode:none or video=sisfb:mode:1024x768x16
54		(or whatever mode you want to use, alternatively using any other format
55		described above or the vesa keyword instead of mode). If compiled as a module,
56		the parameter format reads mode=none or mode=1024x768x16 (or whatever mode you
57		want to use). Using a "=" for a ":" (and vice versa) is a huge difference!
58		Additionally: If you give more than one argument to the in-kernel sisfb, the
59		arguments are separated with ",". For example:
60
61		video=sisfb:mode:1024x768x16,rate:75,mem:12288
62
63
64		How do I use it?
65		================
66
67		Preface statement: This file only covers very little of the driver's
68		capabilities and features. Please refer to the author's and maintainer's
69		website at http://www.winischhofer.net/linuxsisvga.shtml for more
70		information. Additionally, "modinfo sisfb" gives an overview over all
71		supported options including some explanation.
72
73		The desired display mode can be specified using the keyword "mode" with
74		a parameter in one of the following formats:
75		- XxYxDepth or
76		- XxY-Depth or
77		- XxY-Depth@Rate or
78		- XxY
79		- or simply use the VESA mode number in hexadecimal or decimal.
80
81		For example: 1024x768x16, 1024x768-16@75, 1280x1024-16. If no depth is
82		specified, it defaults to 8. If no rate is given, it defaults to 60Hz. Depth 32
83		means 24bit color depth (but 32 bit framebuffer depth, which is not relevant
84		to the user).
85
86		Additionally, sisfb understands the keyword "vesa" followed by a VESA mode
87		number in decimal or hexadecimal. For example: vesa=791 or vesa=0x117. Please
88		use either "mode" or "vesa" but not both.
89
90		Linux 2.4 only: If no mode is given, sisfb defaults to "no mode" (mode=none) if
91		compiled as a module; if sisfb is statically compiled into the kernel, it
92		defaults to 800x600x8 unless CRT2 type is LCD, in which case the LCD's native
93		resolution is used. If you want to switch to a different mode, use the fbset
94		shell command.
95
96		Linux 2.6 only: If no mode is given, sisfb defaults to 800x600x8 unless CRT2
97		type is LCD, in which case it defaults to the LCD's native resolution. If
98		you want to switch to another mode, use the stty shell command.
99
100		You should compile in both vgacon (to boot if you remove you SiS card from
101		your system) and sisfb (for graphics mode). Under Linux 2.6, also "Framebuffer
102		console support" (fbcon) is needed for a graphical console.
103
104		You should not compile-in vesafb. And please do not use the "vga=" keyword
105		in lilo's or grub's configuration file; mode selection is done using the
106		"mode" or "vesa" keywords as a parameter. See above and below.
107
108
109		X11
110		===
111
112		If using XFree86 or X.org, it is recommended that you don't use the "fbdev"
113		driver but the dedicated "sis" X driver. The "sis" X driver and sisfb are
114		developed by the same person (Thomas Winischhofer) and cooperate well with
115		each other.
116
117
118		SVGALib
119		=======
120
121		SVGALib, if directly accessing the hardware, never restores the screen
122		correctly, especially on laptops or if the output devices are LCD or TV.
123		Therefore, use the chipset "FBDEV" in SVGALib configuration. This will make
124		SVGALib use the framebuffer device for mode switches and restoration.
125
126
127		Configuration
128		=============
129
130		(Some) accepted options:
131
132		off - Disable sisfb. This option is only understood if sisfb is
133		in-kernel, not a module.
134		mem:X - size of memory for the console, rest will be used for DRI/DRM. X
135		is in kilobytes. On 300 series, the default is 4096, 8192 or
136		16384 (each in kilobyte) depending on how much video ram the card
137		has. On 315/330 series, the default is the maximum available ram
138		(since DRI/DRM is not supported for these chipsets).
139		noaccel - do not use 2D acceleration engine. (Default: use acceleration)
140		noypan - disable y-panning and scroll by redrawing the entire screen.
141		This is much slower than y-panning. (Default: use y-panning)
142		vesa:X - selects startup videomode. X is number from 0 to 0x1FF and
143		represents the VESA mode number (can be given in decimal or
144		hexadecimal form, the latter prefixed with "0x").
145		mode:X - selects startup videomode. Please see above for the format of
146		"X".
147
148		Boolean options such as "noaccel" or "noypan" are to be given without a
149		parameter if sisfb is in-kernel (for example "video=sisfb:noypan). If
150		sisfb is a module, these are to be set to 1 (for example "modprobe sisfb
151		noypan=1").
152
153		--
154		Thomas Winischhofer <thomas@winischhofer.net>
155		May 27, 2004
156
157

+15

-0

debian/doc/kernel-doc/sm501.rst less more

	0	=======
	1	sm501fb
	2	=======
	3
	4	Configuration:
	5
	6	You can pass the following kernel command line options to sm501
	7	videoframebuffer::
	8
	9	sm501fb.bpp= SM501 Display driver:
	10	Specify bits-per-pixel if not specified by 'mode'
	11
	12	sm501fb.mode= SM501 Display driver:
	13	Specify resolution as
	14	"<xres>x<yres>[-<bpp>][@<refresh>]"

-10

~~debian/doc/kernel-doc/sm501.txt~~ less more

0		Configuration:
1
2		You can pass the following kernel command line options to sm501 videoframebuffer:
3
4		sm501fb.bpp= SM501 Display driver:
5		Specify bits-per-pixel if not specified by 'mode'
6
7		sm501fb.mode= SM501 Display driver:
8		Specify resolution as
9		"<xres>x<yres>[-<bpp>][@<refresh>]"

+35

-0

debian/doc/kernel-doc/sm712fb.rst less more

	0	================
	1	What is sm712fb?
	2	================
	3
	4	This is a graphics framebuffer driver for Silicon Motion SM712 based processors.
	5
	6	How to use it?
	7	==============
	8
	9	Switching modes is done using the video=sm712fb:... boot parameter.
	10
	11	If you want, for example, enable a resolution of 1280x1024x24bpp you should
	12	pass to the kernel this command line: "video=sm712fb:0x31B".
	13
	14	You should not compile-in vesafb.
	15
	16	Currently supported video modes are:
	17
	18	Graphic modes
	19	-------------
	20
	21	=== ======= ======= ======== =========
	22	bpp 640x480 800x600 1024x768 1280x1024
	23	=== ======= ======= ======== =========
	24	8 0x301 0x303 0x305 0x307
	25	16 0x311 0x314 0x317 0x31A
	26	24 0x312 0x315 0x318 0x31B
	27	=== ======= ======= ======== =========
	28
	29	Missing Features
	30	================
	31	(alias TODO list)
	32
	33	* 2D acceleratrion
	34	* dual-head support

-31

~~debian/doc/kernel-doc/sm712fb.txt~~ less more

0		What is sm712fb?
1		=================
2
3		This is a graphics framebuffer driver for Silicon Motion SM712 based processors.
4
5		How to use it?
6		==============
7
8		Switching modes is done using the video=sm712fb:... boot parameter.
9
10		If you want, for example, enable a resolution of 1280x1024x24bpp you should
11		pass to the kernel this command line: "video=sm712fb:0x31B".
12
13		You should not compile-in vesafb.
14
15		Currently supported video modes are:
16
17		[Graphic modes]
18
19		bpp \| 640x480 800x600 1024x768 1280x1024
20		----+--------------------------------------------
21		8 \| 0x301 0x303 0x305 0x307
22		16 \| 0x311 0x314 0x317 0x31A
23		24 \| 0x312 0x315 0x318 0x31B
24
25		Missing Features
26		================
27		(alias TODO list)
28
29		* 2D acceleratrion
30		* dual-head support

+207

-0

debian/doc/kernel-doc/sstfb.rst less more

	0	=====
	1	sstfb
	2	=====
	3
	4	Introduction
	5	============
	6
	7	This is a frame buffer device driver for 3dfx' Voodoo Graphics
	8	(aka voodoo 1, aka sst1) and Voodoo² (aka Voodoo 2, aka CVG) based
	9	video boards. It's highly experimental code, but is guaranteed to work
	10	on my computer, with my "Maxi Gamer 3D" and "Maxi Gamer 3d²" boards,
	11	and with me "between chair and keyboard". Some people tested other
	12	combinations and it seems that it works.
	13	The main page is located at <http://sstfb.sourceforge.net>, and if
	14	you want the latest version, check out the CVS, as the driver is a work
	15	in progress, I feel uncomfortable with releasing tarballs of something
	16	not completely working...Don't worry, it's still more than usable
	17	(I eat my own dog food)
	18
	19	Please read the Bug section, and report any success or failure to me
	20	(Ghozlane Toumi <gtoumi@laposte.net>).
	21	BTW, If you have only one monitor , and you don't feel like playing
	22	with the vga passthrou cable, I can only suggest borrowing a screen
	23	somewhere...
	24
	25
	26	Installation
	27	============
	28
	29	This driver (should) work on ix86, with "late" 2.2.x kernel (tested
	30	with x = 19) and "recent" 2.4.x kernel, as a module or compiled in.
	31	It has been included in mainstream kernel since the infamous 2.4.10.
	32	You can apply the patches found in `sstfb/kernel/*-2.{2\|4}.x.patch`,
	33	and copy sstfb.c to linux/drivers/video/, or apply a single patch,
	34	`sstfb/patch-2.{2\|4}.x-sstfb-yymmdd` to your linux source tree.
	35
	36	Then configure your kernel as usual: choose "m" or "y" to 3Dfx Voodoo
	37	Graphics in section "console". Compile, install, have fun... and please
	38	drop me a report :)
	39
	40
	41	Module Usage
	42	============
	43
	44	.. warning::
	45
	46	#. You should read completely this section before issuing any command.
	47
	48	#. If you have only one monitor to play with, once you insmod the
	49	module, the 3dfx takes control of the output, so you'll have to
	50	plug the monitor to the "normal" video board in order to issue
	51	the commands, or you can blindly use sst_dbg_vgapass
	52	in the tools directory (See Tools). The latest solution is pass the
	53	parameter vgapass=1 when insmodding the driver. (See Kernel/Modules
	54	Options)
	55
	56	Module insertion
	57	----------------
	58
	59	#. insmod sstfb.o
	60
	61	you should see some strange output from the board:
	62	a big blue square, a green and a red small squares and a vertical
	63	white rectangle. why? the function's name is self-explanatory:
	64	"sstfb_test()"...
	65	(if you don't have a second monitor, you'll have to plug your monitor
	66	directly to the 2D videocard to see what you're typing)
	67
	68	#. con2fb /dev/fbx /dev/ttyx
	69
	70	bind a tty to the new frame buffer. if you already have a frame
	71	buffer driver, the voodoo fb will likely be /dev/fb1. if not,
	72	the device will be /dev/fb0. You can check this by doing a
	73	cat /proc/fb. You can find a copy of con2fb in tools/ directory.
	74	if you don't have another fb device, this step is superfluous,
	75	as the console subsystem automagicaly binds ttys to the fb.
	76	#. switch to the virtual console you just mapped. "tadaaa" ...
	77
	78	Module removal
	79	--------------
	80
	81	#. con2fb /dev/fbx /dev/ttyx
	82
	83	bind the tty to the old frame buffer so the module can be removed.
	84	(how does it work with vgacon ? short answer : it doesn't work)
	85
	86	#. rmmod sstfb
	87
	88
	89	Kernel/Modules Options
	90	----------------------
	91
	92	You can pass some options to the sstfb module, and via the kernel
	93	command line when the driver is compiled in:
	94	for module : insmod sstfb.o option1=value1 option2=value2 ...
	95	in kernel : video=sstfb:option1,option2:value2,option3 ...
	96
	97	sstfb supports the following options:
	98
	99	=============== =============== ===============================================
	100	Module Kernel Description
	101	=============== =============== ===============================================
	102	vgapass=0 vganopass Enable or disable VGA passthrou cable.
	103	vgapass=1 vgapass When enabled, the monitor will get the signal
	104	from the VGA board and not from the voodoo.
	105
	106	Default: nopass
	107
	108	mem=x mem:x Force frame buffer memory in MiB
	109	allowed values: 0, 1, 2, 4.
	110
	111	Default: 0 (= autodetect)
	112
	113	inverse=1 inverse Supposed to enable inverse console.
	114	doesn't work yet...
	115
	116	clipping=1 clipping Enable or disable clipping.
	117	clipping=0 noclipping With clipping enabled, all offscreen
	118	reads and writes are discarded.
	119
	120	Default: enable clipping.
	121
	122	gfxclk=x gfxclk:x Force graphic clock frequency (in MHz).
	123	Be careful with this option, it may be
	124	DANGEROUS.
	125
	126	Default: auto
	127
	128	- 50Mhz for Voodoo 1,
	129	- 75MHz for Voodoo 2.
	130
	131	slowpci=1 fastpci Enable or disable fast PCI read/writes.
	132	slowpci=1 slowpci Default : fastpci
	133
	134	dev=x dev:x Attach the driver to device number x.
	135	0 is the first compatible board (in
	136	lspci order)
	137	=============== =============== ===============================================
	138
	139	Tools
	140	=====
	141
	142	These tools are mostly for debugging purposes, but you can
	143	find some of these interesting:
	144
	145	- `con2fb`, maps a tty to a fbramebuffer::
	146
	147	con2fb /dev/fb1 /dev/tty5
	148
	149	- `sst_dbg_vgapass`, changes vga passthrou. You have to recompile the
	150	driver with SST_DEBUG and SST_DEBUG_IOCTL set to 1::
	151
	152	sst_dbg_vgapass /dev/fb1 1 (enables vga cable)
	153	sst_dbg_vgapass /dev/fb1 0 (disables vga cable)
	154
	155	- `glide_reset`, resets the voodoo using glide
	156	use this after rmmoding sstfb, if the module refuses to
	157	reinsert.
	158
	159	Bugs
	160	====
	161
	162	- DO NOT use glide while the sstfb module is in, you'll most likely
	163	hang your computer.
	164	- If you see some artefacts (pixels not cleaning and stuff like that),
	165	try turning off clipping (clipping=0), and/or using slowpci
	166	- the driver don't detect the 4Mb frame buffer voodoos, it seems that
	167	the 2 last Mbs wrap around. looking into that .
	168	- The driver is 16 bpp only, 24/32 won't work.
	169	- The driver is not your_favorite_toy-safe. this includes SMP...
	170
	171	[Actually from inspection it seems to be safe - Alan]
	172
	173	- When using XFree86 FBdev (X over fbdev) you may see strange color
	174	patterns at the border of your windows (the pixels lose the lowest
	175	byte -> basically the blue component and some of the green). I'm unable
	176	to reproduce this with XFree86-3.3, but one of the testers has this
	177	problem with XFree86-4. Apparently recent Xfree86-4.x solve this
	178	problem.
	179	- I didn't really test changing the palette, so you may find some weird
	180	things when playing with that.
	181	- Sometimes the driver will not recognise the DAC, and the
	182	initialisation will fail. This is specifically true for
	183	voodoo 2 boards, but it should be solved in recent versions. Please
	184	contact me.
	185	- The 24/32 is not likely to work anytime soon, knowing that the
	186	hardware does ... unusual things in 24/32 bpp.
	187	- When used with another video board, current limitations of the linux
	188	console subsystem can cause some troubles, specifically, you should
	189	disable software scrollback, as it can oops badly ...
	190
	191	Todo
	192	====
	193
	194	- Get rid of the previous paragraph.
	195	- Buy more coffee.
	196	- test/port to other arch.
	197	- try to add panning using tweeks with front and back buffer .
	198	- try to implement accel on voodoo2, this board can actually do a
	199	lot in 2D even if it was sold as a 3D only board ...
	200
	201	Ghozlane Toumi <gtoumi@laposte.net>
	202
	203
	204	Date: 2002/05/09 20:11:45
	205
	206	http://sstfb.sourceforge.net/README

-174

~~debian/doc/kernel-doc/sstfb.txt~~ less more

0
1		Introduction
2
3		This is a frame buffer device driver for 3dfx' Voodoo Graphics
4		(aka voodoo 1, aka sst1) and Voodoo² (aka Voodoo 2, aka CVG) based
5		video boards. It's highly experimental code, but is guaranteed to work
6		on my computer, with my "Maxi Gamer 3D" and "Maxi Gamer 3d²" boards,
7		and with me "between chair and keyboard". Some people tested other
8		combinations and it seems that it works.
9		The main page is located at <http://sstfb.sourceforge.net>, and if
10		you want the latest version, check out the CVS, as the driver is a work
11		in progress, I feel uncomfortable with releasing tarballs of something
12		not completely working...Don't worry, it's still more than usable
13		(I eat my own dog food)
14
15		Please read the Bug section, and report any success or failure to me
16		(Ghozlane Toumi <gtoumi@laposte.net>).
17		BTW, If you have only one monitor , and you don't feel like playing
18		with the vga passthrou cable, I can only suggest borrowing a screen
19		somewhere...
20
21
22		Installation
23
24		This driver (should) work on ix86, with "late" 2.2.x kernel (tested
25		with x = 19) and "recent" 2.4.x kernel, as a module or compiled in.
26		It has been included in mainstream kernel since the infamous 2.4.10.
27		You can apply the patches found in sstfb/kernel/*-2.{2\|4}.x.patch,
28		and copy sstfb.c to linux/drivers/video/, or apply a single patch,
29		sstfb/patch-2.{2\|4}.x-sstfb-yymmdd to your linux source tree.
30
31		Then configure your kernel as usual: choose "m" or "y" to 3Dfx Voodoo
32		Graphics in section "console". Compile, install, have fun... and please
33		drop me a report :)
34
35
36		Module Usage
37
38		Warnings.
39		# You should read completely this section before issuing any command.
40		# If you have only one monitor to play with, once you insmod the
41		module, the 3dfx takes control of the output, so you'll have to
42		plug the monitor to the "normal" video board in order to issue
43		the commands, or you can blindly use sst_dbg_vgapass
44		in the tools directory (See Tools). The latest solution is pass the
45		parameter vgapass=1 when insmodding the driver. (See Kernel/Modules
46		Options)
47
48		Module insertion:
49		# insmod sstfb.o
50		you should see some strange output from the board:
51		a big blue square, a green and a red small squares and a vertical
52		white rectangle. why? the function's name is self-explanatory:
53		"sstfb_test()"...
54		(if you don't have a second monitor, you'll have to plug your monitor
55		directly to the 2D videocard to see what you're typing)
56		# con2fb /dev/fbx /dev/ttyx
57		bind a tty to the new frame buffer. if you already have a frame
58		buffer driver, the voodoo fb will likely be /dev/fb1. if not,
59		the device will be /dev/fb0. You can check this by doing a
60		cat /proc/fb. You can find a copy of con2fb in tools/ directory.
61		if you don't have another fb device, this step is superfluous,
62		as the console subsystem automagicaly binds ttys to the fb.
63		# switch to the virtual console you just mapped. "tadaaa" ...
64
65		Module removal:
66		# con2fb /dev/fbx /dev/ttyx
67		bind the tty to the old frame buffer so the module can be removed.
68		(how does it work with vgacon ? short answer : it doesn't work)
69		# rmmod sstfb
70
71
72		Kernel/Modules Options
73
74		You can pass some options to the sstfb module, and via the kernel
75		command line when the driver is compiled in:
76		for module : insmod sstfb.o option1=value1 option2=value2 ...
77		in kernel : video=sstfb:option1,option2:value2,option3 ...
78
79		sstfb supports the following options :
80
81		Module Kernel Description
82
83		vgapass=0 vganopass Enable or disable VGA passthrou cable.
84		vgapass=1 vgapass When enabled, the monitor will get the signal
85		from the VGA board and not from the voodoo.
86		Default: nopass
87
88		mem=x mem:x Force frame buffer memory in MiB
89		allowed values: 0, 1, 2, 4.
90		Default: 0 (= autodetect)
91
92		inverse=1 inverse Supposed to enable inverse console.
93		doesn't work yet...
94
95		clipping=1 clipping Enable or disable clipping.
96		clipping=0 noclipping With clipping enabled, all offscreen
97		reads and writes are discarded.
98		Default: enable clipping.
99
100		gfxclk=x gfxclk:x Force graphic clock frequency (in MHz).
101		Be careful with this option, it may be
102		DANGEROUS.
103		Default: auto
104		50Mhz for Voodoo 1,
105		75MHz for Voodoo 2.
106
107		slowpci=1 fastpci Enable or disable fast PCI read/writes.
108		slowpci=1 slowpci Default : fastpci
109
110		dev=x dev:x Attach the driver to device number x.
111		0 is the first compatible board (in
112		lspci order)
113
114		Tools
115
116		These tools are mostly for debugging purposes, but you can
117		find some of these interesting :
118		- con2fb , maps a tty to a fbramebuffer .
119		con2fb /dev/fb1 /dev/tty5
120		- sst_dbg_vgapass , changes vga passthrou. You have to recompile the
121		driver with SST_DEBUG and SST_DEBUG_IOCTL set to 1
122		sst_dbg_vgapass /dev/fb1 1 (enables vga cable)
123		sst_dbg_vgapass /dev/fb1 0 (disables vga cable)
124		- glide_reset , resets the voodoo using glide
125		use this after rmmoding sstfb, if the module refuses to
126		reinsert .
127
128		Bugs
129
130		- DO NOT use glide while the sstfb module is in, you'll most likely
131		hang your computer.
132		- If you see some artefacts (pixels not cleaning and stuff like that),
133		try turning off clipping (clipping=0), and/or using slowpci
134		- the driver don't detect the 4Mb frame buffer voodoos, it seems that
135		the 2 last Mbs wrap around. looking into that .
136		- The driver is 16 bpp only, 24/32 won't work.
137		- The driver is not your_favorite_toy-safe. this includes SMP...
138		[Actually from inspection it seems to be safe - Alan]
139		- When using XFree86 FBdev (X over fbdev) you may see strange color
140		patterns at the border of your windows (the pixels lose the lowest
141		byte -> basically the blue component and some of the green). I'm unable
142		to reproduce this with XFree86-3.3, but one of the testers has this
143		problem with XFree86-4. Apparently recent Xfree86-4.x solve this
144		problem.
145		- I didn't really test changing the palette, so you may find some weird
146		things when playing with that.
147		- Sometimes the driver will not recognise the DAC, and the
148		initialisation will fail. This is specifically true for
149		voodoo 2 boards, but it should be solved in recent versions. Please
150		contact me.
151		- The 24/32 is not likely to work anytime soon, knowing that the
152		hardware does ... unusual things in 24/32 bpp.
153		- When used with another video board, current limitations of the linux
154		console subsystem can cause some troubles, specifically, you should
155		disable software scrollback, as it can oops badly ...
156
157		Todo
158
159		- Get rid of the previous paragraph.
160		- Buy more coffee.
161		- test/port to other arch.
162		- try to add panning using tweeks with front and back buffer .
163		- try to implement accel on voodoo2, this board can actually do a
164		lot in 2D even if it was sold as a 3D only board ...
165
166		ghoz.
167
168		--
169		Ghozlane Toumi <gtoumi@laposte.net>
170
171
172		$Date: 2002/05/09 20:11:45 $
173		http://sstfb.sourceforge.net/README

+71

-0

debian/doc/kernel-doc/tgafb.rst less more

	0	==============
	1	What is tgafb?
	2	==============
	3
	4	This is a driver for DECChip 21030 based graphics framebuffers, a.k.a. TGA
	5	cards, which are usually found in older Digital Alpha systems. The
	6	following models are supported:
	7
	8	- ZLxP-E1 (8bpp, 2 MB VRAM)
	9	- ZLxP-E2 (32bpp, 8 MB VRAM)
	10	- ZLxP-E3 (32bpp, 16 MB VRAM, Zbuffer)
	11
	12	This version is an almost complete rewrite of the code written by Geert
	13	Uytterhoeven, which was based on the original TGA console code written by
	14	Jay Estabrook.
	15
	16	Major new features since Linux 2.0.x:
	17
	18	* Support for multiple resolutions
	19	* Support for fixed-frequency and other oddball monitors
	20	(by allowing the video mode to be set at boot time)
	21
	22	User-visible changes since Linux 2.2.x:
	23
	24	* Sync-on-green is now handled properly
	25	* More useful information is printed on bootup
	26	(this helps if people run into problems)
	27
	28	This driver does not (yet) support the TGA2 family of framebuffers, so the
	29	PowerStorm 3D30/4D20 (also known as PBXGB) cards are not supported. These
	30	can however be used with the standard VGA Text Console driver.
	31
	32
	33	Configuration
	34	=============
	35
	36	You can pass kernel command line options to tgafb with
	37	`video=tgafb:option1,option2:value2,option3` (multiple options should be
	38	separated by comma, values are separated from options by `:`).
	39
	40	Accepted options:
	41
	42	========== ============================================================
	43	font:X default font to use. All fonts are supported, including the
	44	SUN12x22 font which is very nice at high resolutions.
	45
	46	mode:X default video mode. The following video modes are supported:
	47	640x480-60, 800x600-56, 640x480-72, 800x600-60, 800x600-72,
	48	1024x768-60, 1152x864-60, 1024x768-70, 1024x768-76,
	49	1152x864-70, 1280x1024-61, 1024x768-85, 1280x1024-70,
	50	1152x864-84, 1280x1024-76, 1280x1024-85
	51	========== ============================================================
	52
	53
	54	Known Issues
	55	============
	56
	57	The XFree86 FBDev server has been reported not to work, since tgafb doesn't do
	58	mmap(). Running the standard XF86_TGA server from XFree86 3.3.x works fine for
	59	me, however this server does not do acceleration, which make certain operations
	60	quite slow. Support for acceleration is being progressively integrated in
	61	XFree86 4.x.
	62
	63	When running tgafb in resolutions higher than 640x480, on switching VCs from
	64	tgafb to XF86_TGA 3.3.x, the entire screen is not re-drawn and must be manually
	65	refreshed. This is an X server problem, not a tgafb problem, and is fixed in
	66	XFree86 4.0.
	67
	68	Enjoy!
	69
	70	Martin Lucina <mato@kotelna.sk>

-69

~~debian/doc/kernel-doc/tgafb.txt~~ less more

0		$Id: tgafb.txt,v 1.1.2.2 2000/04/04 06:50:18 mato Exp $
1
2		What is tgafb?
3		===============
4
5		This is a driver for DECChip 21030 based graphics framebuffers, a.k.a. TGA
6		cards, which are usually found in older Digital Alpha systems. The
7		following models are supported:
8
9		ZLxP-E1 (8bpp, 2 MB VRAM)
10		ZLxP-E2 (32bpp, 8 MB VRAM)
11		ZLxP-E3 (32bpp, 16 MB VRAM, Zbuffer)
12
13		This version is an almost complete rewrite of the code written by Geert
14		Uytterhoeven, which was based on the original TGA console code written by
15		Jay Estabrook.
16
17		Major new features since Linux 2.0.x:
18
19		* Support for multiple resolutions
20		* Support for fixed-frequency and other oddball monitors
21		(by allowing the video mode to be set at boot time)
22
23		User-visible changes since Linux 2.2.x:
24
25		* Sync-on-green is now handled properly
26		* More useful information is printed on bootup
27		(this helps if people run into problems)
28
29		This driver does not (yet) support the TGA2 family of framebuffers, so the
30		PowerStorm 3D30/4D20 (also known as PBXGB) cards are not supported. These
31		can however be used with the standard VGA Text Console driver.
32
33
34		Configuration
35		=============
36
37		You can pass kernel command line options to tgafb with
38		`video=tgafb:option1,option2:value2,option3' (multiple options should be
39		separated by comma, values are separated from options by `:').
40		Accepted options:
41
42		font:X - default font to use. All fonts are supported, including the
43		SUN12x22 font which is very nice at high resolutions.
44
45		mode:X - default video mode. The following video modes are supported:
46		640x480-60, 800x600-56, 640x480-72, 800x600-60, 800x600-72,
47		1024x768-60, 1152x864-60, 1024x768-70, 1024x768-76,
48		1152x864-70, 1280x1024-61, 1024x768-85, 1280x1024-70,
49		1152x864-84, 1280x1024-76, 1280x1024-85
50
51
52		Known Issues
53		============
54
55		The XFree86 FBDev server has been reported not to work, since tgafb doesn't do
56		mmap(). Running the standard XF86_TGA server from XFree86 3.3.x works fine for
57		me, however this server does not do acceleration, which make certain operations
58		quite slow. Support for acceleration is being progressively integrated in
59		XFree86 4.x.
60
61		When running tgafb in resolutions higher than 640x480, on switching VCs from
62		tgafb to XF86_TGA 3.3.x, the entire screen is not re-drawn and must be manually
63		refreshed. This is an X server problem, not a tgafb problem, and is fixed in
64		XFree86 4.0.
65
66		Enjoy!
67
68		Martin Lucina <mato@kotelna.sk>

+78

-0

debian/doc/kernel-doc/tridentfb.rst less more

	0	=========
	1	Tridentfb
	2	=========
	3
	4	Tridentfb is a framebuffer driver for some Trident chip based cards.
	5
	6	The following list of chips is thought to be supported although not all are
	7	tested:
	8
	9	those from the TGUI series 9440/96XX and with Cyber in their names
	10	those from the Image series and with Cyber in their names
	11	those with Blade in their names (Blade3D,CyberBlade...)
	12	the newer CyberBladeXP family
	13
	14	All families are accelerated. Only PCI/AGP based cards are supported,
	15	none of the older Tridents.
	16	The driver supports 8, 16 and 32 bits per pixel depths.
	17	The TGUI family requires a line length to be power of 2 if acceleration
	18	is enabled. This means that range of possible resolutions and bpp is
	19	limited comparing to the range if acceleration is disabled (see list
	20	of parameters below).
	21
	22	Known bugs:
	23
	24	1. The driver randomly locks up on 3DImage975 chip with acceleration
	25	enabled. The same happens in X11 (Xorg).
	26	2. The ramdac speeds require some more fine tuning. It is possible to
	27	switch resolution which the chip does not support at some depths for
	28	older chips.
	29
	30	How to use it?
	31	==============
	32
	33	When booting you can pass the video parameter::
	34
	35	video=tridentfb
	36
	37	The parameters for tridentfb are concatenated with a ':' as in this example::
	38
	39	video=tridentfb:800x600-16@75,noaccel
	40
	41	The second level parameters that tridentfb understands are:
	42
	43	======== =====================================================================
	44	noaccel turns off acceleration (when it doesn't work for your card)
	45
	46	fp use flat panel related stuff
	47	crt assume monitor is present instead of fp
	48
	49	center for flat panels and resolutions smaller than native size center the
	50	image, otherwise use
	51	stretch
	52
	53	memsize integer value in KB, use if your card's memory size is misdetected.
	54	look at the driver output to see what it says when initializing.
	55
	56	memdiff integer value in KB, should be nonzero if your card reports
	57	more memory than it actually has. For instance mine is 192K less than
	58	detection says in all three BIOS selectable situations 2M, 4M, 8M.
	59	Only use if your video memory is taken from main memory hence of
	60	configurable size. Otherwise use memsize.
	61	If in some modes which barely fit the memory you see garbage
	62	at the bottom this might help by not letting change to that mode
	63	anymore.
	64
	65	nativex the width in pixels of the flat panel.If you know it (usually 1024
	66	800 or 1280) and it is not what the driver seems to detect use it.
	67
	68	bpp bits per pixel (8,16 or 32)
	69	mode a mode name like 800x600-8@75 as described in
	70	Documentation/fb/modedb.rst
	71	======== =====================================================================
	72
	73	Using insane values for the above parameters will probably result in driver
	74	misbehaviour so take care(for instance memsize=12345678 or memdiff=23784 or
	75	nativex=93)
	76
	77	Contact: jani@astechnix.ro

-70

~~debian/doc/kernel-doc/tridentfb.txt~~ less more

0		Tridentfb is a framebuffer driver for some Trident chip based cards.
1
2		The following list of chips is thought to be supported although not all are
3		tested:
4
5		those from the TGUI series 9440/96XX and with Cyber in their names
6		those from the Image series and with Cyber in their names
7		those with Blade in their names (Blade3D,CyberBlade...)
8		the newer CyberBladeXP family
9
10		All families are accelerated. Only PCI/AGP based cards are supported,
11		none of the older Tridents.
12		The driver supports 8, 16 and 32 bits per pixel depths.
13		The TGUI family requires a line length to be power of 2 if acceleration
14		is enabled. This means that range of possible resolutions and bpp is
15		limited comparing to the range if acceleration is disabled (see list
16		of parameters below).
17
18		Known bugs:
19		1. The driver randomly locks up on 3DImage975 chip with acceleration
20		enabled. The same happens in X11 (Xorg).
21		2. The ramdac speeds require some more fine tuning. It is possible to
22		switch resolution which the chip does not support at some depths for
23		older chips.
24
25		How to use it?
26		==============
27
28		When booting you can pass the video parameter.
29		video=tridentfb
30
31		The parameters for tridentfb are concatenated with a ':' as in this example.
32
33		video=tridentfb:800x600-16@75,noaccel
34
35		The second level parameters that tridentfb understands are:
36
37		noaccel - turns off acceleration (when it doesn't work for your card)
38
39		fp - use flat panel related stuff
40		crt - assume monitor is present instead of fp
41
42		center - for flat panels and resolutions smaller than native size center the
43		image, otherwise use
44		stretch
45
46		memsize - integer value in KB, use if your card's memory size is misdetected.
47		look at the driver output to see what it says when initializing.
48
49		memdiff - integer value in KB, should be nonzero if your card reports
50		more memory than it actually has. For instance mine is 192K less than
51		detection says in all three BIOS selectable situations 2M, 4M, 8M.
52		Only use if your video memory is taken from main memory hence of
53		configurable size. Otherwise use memsize.
54		If in some modes which barely fit the memory you see garbage
55		at the bottom this might help by not letting change to that mode
56		anymore.
57
58		nativex - the width in pixels of the flat panel.If you know it (usually 1024
59		800 or 1280) and it is not what the driver seems to detect use it.
60
61		bpp - bits per pixel (8,16 or 32)
62		mode - a mode name like 800x600-8@75 as described in
63		Documentation/fb/modedb.txt
64
65		Using insane values for the above parameters will probably result in driver
66		misbehaviour so take care(for instance memsize=12345678 or memdiff=23784 or
67		nativex=93)
68
69		Contact: jani@astechnix.ro

+162

-0

debian/doc/kernel-doc/udlfb.rst less more

	0	==============
	1	What is udlfb?
	2	==============
	3
	4	This is a driver for DisplayLink USB 2.0 era graphics chips.
	5
	6	DisplayLink chips provide simple hline/blit operations with some compression,
	7	pairing that with a hardware framebuffer (16MB) on the other end of the
	8	USB wire. That hardware framebuffer is able to drive the VGA, DVI, or HDMI
	9	monitor with no CPU involvement until a pixel has to change.
	10
	11	The CPU or other local resource does all the rendering; optionally compares the
	12	result with a local shadow of the remote hardware framebuffer to identify
	13	the minimal set of pixels that have changed; and compresses and sends those
	14	pixels line-by-line via USB bulk transfers.
	15
	16	Because of the efficiency of bulk transfers and a protocol on top that
	17	does not require any acks - the effect is very low latency that
	18	can support surprisingly high resolutions with good performance for
	19	non-gaming and non-video applications.
	20
	21	Mode setting, EDID read, etc are other bulk or control transfers. Mode
	22	setting is very flexible - able to set nearly arbitrary modes from any timing.
	23
	24	Advantages of USB graphics in general:
	25
	26	* Ability to add a nearly arbitrary number of displays to any USB 2.0
	27	capable system. On Linux, number of displays is limited by fbdev interface
	28	(FB_MAX is currently 32). Of course, all USB devices on the same
	29	host controller share the same 480Mbs USB 2.0 interface.
	30
	31	Advantages of supporting DisplayLink chips with kernel framebuffer interface:
	32
	33	* The actual hardware functionality of DisplayLink chips matches nearly
	34	one-to-one with the fbdev interface, making the driver quite small and
	35	tight relative to the functionality it provides.
	36	* X servers and other applications can use the standard fbdev interface
	37	from user mode to talk to the device, without needing to know anything
	38	about USB or DisplayLink's protocol at all. A "displaylink" X driver
	39	and a slightly modified "fbdev" X driver are among those that already do.
	40
	41	Disadvantages:
	42
	43	* Fbdev's mmap interface assumes a real hardware framebuffer is mapped.
	44	In the case of USB graphics, it is just an allocated (virtual) buffer.
	45	Writes need to be detected and encoded into USB bulk transfers by the CPU.
	46	Accurate damage/changed area notifications work around this problem.
	47	In the future, hopefully fbdev will be enhanced with an small standard
	48	interface to allow mmap clients to report damage, for the benefit
	49	of virtual or remote framebuffers.
	50	* Fbdev does not arbitrate client ownership of the framebuffer well.
	51	* Fbcon assumes the first framebuffer it finds should be consumed for console.
	52	* It's not clear what the future of fbdev is, given the rise of KMS/DRM.
	53
	54	How to use it?
	55	==============
	56
	57	Udlfb, when loaded as a module, will match against all USB 2.0 generation
	58	DisplayLink chips (Alex and Ollie family). It will then attempt to read the EDID
	59	of the monitor, and set the best common mode between the DisplayLink device
	60	and the monitor's capabilities.
	61
	62	If the DisplayLink device is successful, it will paint a "green screen" which
	63	means that from a hardware and fbdev software perspective, everything is good.
	64
	65	At that point, a /dev/fb? interface will be present for user-mode applications
	66	to open and begin writing to the framebuffer of the DisplayLink device using
	67	standard fbdev calls. Note that if mmap() is used, by default the user mode
	68	application must send down damage notifications to trigger repaints of the
	69	changed regions. Alternatively, udlfb can be recompiled with experimental
	70	defio support enabled, to support a page-fault based detection mechanism
	71	that can work without explicit notification.
	72
	73	The most common client of udlfb is xf86-video-displaylink or a modified
	74	xf86-video-fbdev X server. These servers have no real DisplayLink specific
	75	code. They write to the standard framebuffer interface and rely on udlfb
	76	to do its thing. The one extra feature they have is the ability to report
	77	rectangles from the X DAMAGE protocol extension down to udlfb via udlfb's
	78	damage interface (which will hopefully be standardized for all virtual
	79	framebuffers that need damage info). These damage notifications allow
	80	udlfb to efficiently process the changed pixels.
	81
	82	Module Options
	83	==============
	84
	85	Special configuration for udlfb is usually unnecessary. There are a few
	86	options, however.
	87
	88	From the command line, pass options to modprobe
	89	modprobe udlfb fb_defio=0 console=1 shadow=1
	90
	91	Or modify options on the fly at /sys/module/udlfb/parameters directory via
	92	sudo nano fb_defio
	93	change the parameter in place, and save the file.
	94
	95	Unplug/replug USB device to apply with new settings
	96
	97	Or for permanent option, create file like /etc/modprobe.d/udlfb.conf with text
	98	options udlfb fb_defio=0 console=1 shadow=1
	99
	100	Accepted boolean options:
	101
	102	=============== ================================================================
	103	fb_defio Make use of the fb_defio (CONFIG_FB_DEFERRED_IO) kernel
	104	module to track changed areas of the framebuffer by page faults.
	105	Standard fbdev applications that use mmap but that do not
	106	report damage, should be able to work with this enabled.
	107	Disable when running with X server that supports reporting
	108	changed regions via ioctl, as this method is simpler,
	109	more stable, and higher performance.
	110	default: fb_defio=1
	111
	112	console Allow fbcon to attach to udlfb provided framebuffers.
	113	Can be disabled if fbcon and other clients
	114	(e.g. X with --shared-vt) are in conflict.
	115	default: console=1
	116
	117	shadow Allocate a 2nd framebuffer to shadow what's currently across
	118	the USB bus in device memory. If any pixels are unchanged,
	119	do not transmit. Spends host memory to save USB transfers.
	120	Enabled by default. Only disable on very low memory systems.
	121	default: shadow=1
	122	=============== ================================================================
	123
	124	Sysfs Attributes
	125	================
	126
	127	Udlfb creates several files in /sys/class/graphics/fb?
	128	Where ? is the sequential framebuffer id of the particular DisplayLink device
	129
	130	======================== ========================================================
	131	edid If a valid EDID blob is written to this file (typically
	132	by a udev rule), then udlfb will use this EDID as a
	133	backup in case reading the actual EDID of the monitor
	134	attached to the DisplayLink device fails. This is
	135	especially useful for fixed panels, etc. that cannot
	136	communicate their capabilities via EDID. Reading
	137	this file returns the current EDID of the attached
	138	monitor (or last backup value written). This is
	139	useful to get the EDID of the attached monitor,
	140	which can be passed to utilities like parse-edid.
	141
	142	metrics_bytes_rendered 32-bit count of pixel bytes rendered
	143
	144	metrics_bytes_identical 32-bit count of how many of those bytes were found to be
	145	unchanged, based on a shadow framebuffer check
	146
	147	metrics_bytes_sent 32-bit count of how many bytes were transferred over
	148	USB to communicate the resulting changed pixels to the
	149	hardware. Includes compression and protocol overhead
	150
	151	metrics_cpu_kcycles_used 32-bit count of CPU cycles used in processing the
	152	above pixels (in thousands of cycles).
	153
	154	metrics_reset Write-only. Any write to this file resets all metrics
	155	above to zero. Note that the 32-bit counters above
	156	roll over very quickly. To get reliable results, design
	157	performance tests to start and finish in a very short
	158	period of time (one minute or less is safe).
	159	======================== ========================================================
	160
	161	Bernie Thompson <bernie@plugable.com>

-159

~~debian/doc/kernel-doc/udlfb.txt~~ less more

0
1		What is udlfb?
2		===============
3
4		This is a driver for DisplayLink USB 2.0 era graphics chips.
5
6		DisplayLink chips provide simple hline/blit operations with some compression,
7		pairing that with a hardware framebuffer (16MB) on the other end of the
8		USB wire. That hardware framebuffer is able to drive the VGA, DVI, or HDMI
9		monitor with no CPU involvement until a pixel has to change.
10
11		The CPU or other local resource does all the rendering; optionally compares the
12		result with a local shadow of the remote hardware framebuffer to identify
13		the minimal set of pixels that have changed; and compresses and sends those
14		pixels line-by-line via USB bulk transfers.
15
16		Because of the efficiency of bulk transfers and a protocol on top that
17		does not require any acks - the effect is very low latency that
18		can support surprisingly high resolutions with good performance for
19		non-gaming and non-video applications.
20
21		Mode setting, EDID read, etc are other bulk or control transfers. Mode
22		setting is very flexible - able to set nearly arbitrary modes from any timing.
23
24		Advantages of USB graphics in general:
25
26		* Ability to add a nearly arbitrary number of displays to any USB 2.0
27		capable system. On Linux, number of displays is limited by fbdev interface
28		(FB_MAX is currently 32). Of course, all USB devices on the same
29		host controller share the same 480Mbs USB 2.0 interface.
30
31		Advantages of supporting DisplayLink chips with kernel framebuffer interface:
32
33		* The actual hardware functionality of DisplayLink chips matches nearly
34		one-to-one with the fbdev interface, making the driver quite small and
35		tight relative to the functionality it provides.
36		* X servers and other applications can use the standard fbdev interface
37		from user mode to talk to the device, without needing to know anything
38		about USB or DisplayLink's protocol at all. A "displaylink" X driver
39		and a slightly modified "fbdev" X driver are among those that already do.
40
41		Disadvantages:
42
43		* Fbdev's mmap interface assumes a real hardware framebuffer is mapped.
44		In the case of USB graphics, it is just an allocated (virtual) buffer.
45		Writes need to be detected and encoded into USB bulk transfers by the CPU.
46		Accurate damage/changed area notifications work around this problem.
47		In the future, hopefully fbdev will be enhanced with an small standard
48		interface to allow mmap clients to report damage, for the benefit
49		of virtual or remote framebuffers.
50		* Fbdev does not arbitrate client ownership of the framebuffer well.
51		* Fbcon assumes the first framebuffer it finds should be consumed for console.
52		* It's not clear what the future of fbdev is, given the rise of KMS/DRM.
53
54		How to use it?
55		==============
56
57		Udlfb, when loaded as a module, will match against all USB 2.0 generation
58		DisplayLink chips (Alex and Ollie family). It will then attempt to read the EDID
59		of the monitor, and set the best common mode between the DisplayLink device
60		and the monitor's capabilities.
61
62		If the DisplayLink device is successful, it will paint a "green screen" which
63		means that from a hardware and fbdev software perspective, everything is good.
64
65		At that point, a /dev/fb? interface will be present for user-mode applications
66		to open and begin writing to the framebuffer of the DisplayLink device using
67		standard fbdev calls. Note that if mmap() is used, by default the user mode
68		application must send down damage notifications to trigger repaints of the
69		changed regions. Alternatively, udlfb can be recompiled with experimental
70		defio support enabled, to support a page-fault based detection mechanism
71		that can work without explicit notification.
72
73		The most common client of udlfb is xf86-video-displaylink or a modified
74		xf86-video-fbdev X server. These servers have no real DisplayLink specific
75		code. They write to the standard framebuffer interface and rely on udlfb
76		to do its thing. The one extra feature they have is the ability to report
77		rectangles from the X DAMAGE protocol extension down to udlfb via udlfb's
78		damage interface (which will hopefully be standardized for all virtual
79		framebuffers that need damage info). These damage notifications allow
80		udlfb to efficiently process the changed pixels.
81
82		Module Options
83		==============
84
85		Special configuration for udlfb is usually unnecessary. There are a few
86		options, however.
87
88		From the command line, pass options to modprobe
89		modprobe udlfb fb_defio=0 console=1 shadow=1
90
91		Or modify options on the fly at /sys/module/udlfb/parameters directory via
92		sudo nano fb_defio
93		change the parameter in place, and save the file.
94
95		Unplug/replug USB device to apply with new settings
96
97		Or for permanent option, create file like /etc/modprobe.d/udlfb.conf with text
98		options udlfb fb_defio=0 console=1 shadow=1
99
100		Accepted boolean options:
101
102		fb_defio Make use of the fb_defio (CONFIG_FB_DEFERRED_IO) kernel
103		module to track changed areas of the framebuffer by page faults.
104		Standard fbdev applications that use mmap but that do not
105		report damage, should be able to work with this enabled.
106		Disable when running with X server that supports reporting
107		changed regions via ioctl, as this method is simpler,
108		more stable, and higher performance.
109		default: fb_defio=1
110
111		console Allow fbcon to attach to udlfb provided framebuffers.
112		Can be disabled if fbcon and other clients
113		(e.g. X with --shared-vt) are in conflict.
114		default: console=1
115
116		shadow Allocate a 2nd framebuffer to shadow what's currently across
117		the USB bus in device memory. If any pixels are unchanged,
118		do not transmit. Spends host memory to save USB transfers.
119		Enabled by default. Only disable on very low memory systems.
120		default: shadow=1
121
122		Sysfs Attributes
123		================
124
125		Udlfb creates several files in /sys/class/graphics/fb?
126		Where ? is the sequential framebuffer id of the particular DisplayLink device
127
128		edid If a valid EDID blob is written to this file (typically
129		by a udev rule), then udlfb will use this EDID as a
130		backup in case reading the actual EDID of the monitor
131		attached to the DisplayLink device fails. This is
132		especially useful for fixed panels, etc. that cannot
133		communicate their capabilities via EDID. Reading
134		this file returns the current EDID of the attached
135		monitor (or last backup value written). This is
136		useful to get the EDID of the attached monitor,
137		which can be passed to utilities like parse-edid.
138
139		metrics_bytes_rendered 32-bit count of pixel bytes rendered
140
141		metrics_bytes_identical 32-bit count of how many of those bytes were found to be
142		unchanged, based on a shadow framebuffer check
143
144		metrics_bytes_sent 32-bit count of how many bytes were transferred over
145		USB to communicate the resulting changed pixels to the
146		hardware. Includes compression and protocol overhead
147
148		metrics_cpu_kcycles_used 32-bit count of CPU cycles used in processing the
149		above pixels (in thousands of cycles).
150
151		metrics_reset Write-only. Any write to this file resets all metrics
152		above to zero. Note that the 32-bit counters above
153		roll over very quickly. To get reliable results, design
154		performance tests to start and finish in a very short
155		period of time (one minute or less is safe).
156
157		--
158		Bernie Thompson <bernie@plugable.com>

+188

-0

debian/doc/kernel-doc/uvesafb.rst less more

	0	==========================================================
	1	uvesafb - A Generic Driver for VBE2+ compliant video cards
	2	==========================================================
	3
	4	1. Requirements
	5	---------------
	6
	7	uvesafb should work with any video card that has a Video BIOS compliant
	8	with the VBE 2.0 standard.
	9
	10	Unlike other drivers, uvesafb makes use of a userspace helper called
	11	v86d. v86d is used to run the x86 Video BIOS code in a simulated and
	12	controlled environment. This allows uvesafb to function on arches other
	13	than x86. Check the v86d documentation for a list of currently supported
	14	arches.
	15
	16	v86d source code can be downloaded from the following website:
	17
	18	https://github.com/mjanusz/v86d
	19
	20	Please refer to the v86d documentation for detailed configuration and
	21	installation instructions.
	22
	23	Note that the v86d userspace helper has to be available at all times in
	24	order for uvesafb to work properly. If you want to use uvesafb during
	25	early boot, you will have to include v86d into an initramfs image, and
	26	either compile it into the kernel or use it as an initrd.
	27
	28	2. Caveats and limitations
	29	--------------------------
	30
	31	uvesafb is a _generic_ driver which supports a wide variety of video
	32	cards, but which is ultimately limited by the Video BIOS interface.
	33	The most important limitations are:
	34
	35	- Lack of any type of acceleration.
	36	- A strict and limited set of supported video modes. Often the native
	37	or most optimal resolution/refresh rate for your setup will not work
	38	with uvesafb, simply because the Video BIOS doesn't support the
	39	video mode you want to use. This can be especially painful with
	40	widescreen panels, where native video modes don't have the 4:3 aspect
	41	ratio, which is what most BIOS-es are limited to.
	42	- Adjusting the refresh rate is only possible with a VBE 3.0 compliant
	43	Video BIOS. Note that many nVidia Video BIOS-es claim to be VBE 3.0
	44	compliant, while they simply ignore any refresh rate settings.
	45
	46	3. Configuration
	47	----------------
	48
	49	uvesafb can be compiled either as a module, or directly into the kernel.
	50	In both cases it supports the same set of configuration options, which
	51	are either given on the kernel command line or as module parameters, e.g.::
	52
	53	video=uvesafb:1024x768-32,mtrr:3,ywrap (compiled into the kernel)
	54
	55	# modprobe uvesafb mode_option=1024x768-32 mtrr=3 scroll=ywrap (module)
	56
	57	Accepted options:
	58
	59	======= =========================================================
	60	ypan Enable display panning using the VESA protected mode
	61	interface. The visible screen is just a window of the
	62	video memory, console scrolling is done by changing the
	63	start of the window. This option is available on x86
	64	only and is the default option on that architecture.
	65
	66	ywrap Same as ypan, but assumes your gfx board can wrap-around
	67	the video memory (i.e. starts reading from top if it
	68	reaches the end of video memory). Faster than ypan.
	69	Available on x86 only.
	70
	71	redraw Scroll by redrawing the affected part of the screen, this
	72	is the default on non-x86.
	73	======= =========================================================
	74
	75	(If you're using uvesafb as a module, the above three options are
	76	used a parameter of the scroll option, e.g. scroll=ypan.)
	77
	78	=========== ====================================================================
	79	vgapal Use the standard VGA registers for palette changes.
	80
	81	pmipal Use the protected mode interface for palette changes.
	82	This is the default if the protected mode interface is
	83	available. Available on x86 only.
	84
	85	mtrr:n Setup memory type range registers for the framebuffer
	86	where n:
	87
	88	- 0 - disabled (equivalent to nomtrr)
	89	- 3 - write-combining (default)
	90
	91	Values other than 0 and 3 will result in a warning and will be
	92	treated just like 3.
	93
	94	nomtrr Do not use memory type range registers.
	95
	96	vremap:n
	97	Remap 'n' MiB of video RAM. If 0 or not specified, remap memory
	98	according to video mode.
	99
	100	vtotal:n If the video BIOS of your card incorrectly determines the total
	101	amount of video RAM, use this option to override the BIOS (in MiB).
	102
	103	<mode> The mode you want to set, in the standard modedb format. Refer to
	104	modedb.txt for a detailed description. When uvesafb is compiled as
	105	a module, the mode string should be provided as a value of the
	106	'mode_option' option.
	107
	108	vbemode:x Force the use of VBE mode x. The mode will only be set if it's
	109	found in the VBE-provided list of supported modes.
	110	NOTE: The mode number 'x' should be specified in VESA mode number
	111	notation, not the Linux kernel one (eg. 257 instead of 769).
	112	HINT: If you use this option because normal <mode> parameter does
	113	not work for you and you use a X server, you'll probably want to
	114	set the 'nocrtc' option to ensure that the video mode is properly
	115	restored after console <-> X switches.
	116
	117	nocrtc Do not use CRTC timings while setting the video mode. This option
	118	has any effect only if the Video BIOS is VBE 3.0 compliant. Use it
	119	if you have problems with modes set the standard way. Note that
	120	using this option implies that any refresh rate adjustments will
	121	be ignored and the refresh rate will stay at your BIOS default
	122	(60 Hz).
	123
	124	noedid Do not try to fetch and use EDID-provided modes.
	125
	126	noblank Disable hardware blanking.
	127
	128	v86d:path Set path to the v86d executable. This option is only available as
	129	a module parameter, and not as a part of the video= string. If you
	130	need to use it and have uvesafb built into the kernel, use
	131	uvesafb.v86d="path".
	132	=========== ====================================================================
	133
	134	Additionally, the following parameters may be provided. They all override the
	135	EDID-provided values and BIOS defaults. Refer to your monitor's specs to get
	136	the correct values for maxhf, maxvf and maxclk for your hardware.
	137
	138	=========== ======================================
	139	maxhf:n Maximum horizontal frequency (in kHz).
	140	maxvf:n Maximum vertical frequency (in Hz).
	141	maxclk:n Maximum pixel clock (in MHz).
	142	=========== ======================================
	143
	144	4. The sysfs interface
	145	----------------------
	146
	147	uvesafb provides several sysfs nodes for configurable parameters and
	148	additional information.
	149
	150	Driver attributes:
	151
	152	/sys/bus/platform/drivers/uvesafb
	153	v86d
	154	(default: /sbin/v86d)
	155
	156	Path to the v86d executable. v86d is started by uvesafb
	157	if an instance of the daemon isn't already running.
	158
	159	Device attributes:
	160
	161	/sys/bus/platform/drivers/uvesafb/uvesafb.0
	162	nocrtc
	163	Use the default refresh rate (60 Hz) if set to 1.
	164
	165	oem_product_name, oem_product_rev, oem_string, oem_vendor
	166	Information about the card and its maker.
	167
	168	vbe_modes
	169	A list of video modes supported by the Video BIOS along with their
	170	VBE mode numbers in hex.
	171
	172	vbe_version
	173	A BCD value indicating the implemented VBE standard.
	174
	175	5. Miscellaneous
	176	----------------
	177
	178	Uvesafb will set a video mode with the default refresh rate and timings
	179	from the Video BIOS if you set pixclock to 0 in fb_var_screeninfo.
	180
	181
	182
	183	Michal Januszewski <spock@gentoo.org>
	184
	185	Last updated: 2017-10-10
	186
	187	Documentation of the uvesafb options is loosely based on vesafb.txt.

-183

~~debian/doc/kernel-doc/uvesafb.txt~~ less more

0
1		uvesafb - A Generic Driver for VBE2+ compliant video cards
2		==========================================================
3
4		1. Requirements
5		---------------
6
7		uvesafb should work with any video card that has a Video BIOS compliant
8		with the VBE 2.0 standard.
9
10		Unlike other drivers, uvesafb makes use of a userspace helper called
11		v86d. v86d is used to run the x86 Video BIOS code in a simulated and
12		controlled environment. This allows uvesafb to function on arches other
13		than x86. Check the v86d documentation for a list of currently supported
14		arches.
15
16		v86d source code can be downloaded from the following website:
17		http://dev.gentoo.org/~spock/projects/uvesafb
18
19		Please refer to the v86d documentation for detailed configuration and
20		installation instructions.
21
22		Note that the v86d userspace helper has to be available at all times in
23		order for uvesafb to work properly. If you want to use uvesafb during
24		early boot, you will have to include v86d into an initramfs image, and
25		either compile it into the kernel or use it as an initrd.
26
27		2. Caveats and limitations
28		--------------------------
29
30		uvesafb is a _generic_ driver which supports a wide variety of video
31		cards, but which is ultimately limited by the Video BIOS interface.
32		The most important limitations are:
33
34		- Lack of any type of acceleration.
35		- A strict and limited set of supported video modes. Often the native
36		or most optimal resolution/refresh rate for your setup will not work
37		with uvesafb, simply because the Video BIOS doesn't support the
38		video mode you want to use. This can be especially painful with
39		widescreen panels, where native video modes don't have the 4:3 aspect
40		ratio, which is what most BIOS-es are limited to.
41		- Adjusting the refresh rate is only possible with a VBE 3.0 compliant
42		Video BIOS. Note that many nVidia Video BIOS-es claim to be VBE 3.0
43		compliant, while they simply ignore any refresh rate settings.
44
45		3. Configuration
46		----------------
47
48		uvesafb can be compiled either as a module, or directly into the kernel.
49		In both cases it supports the same set of configuration options, which
50		are either given on the kernel command line or as module parameters, e.g.:
51
52		video=uvesafb:1024x768-32,mtrr:3,ywrap (compiled into the kernel)
53
54		# modprobe uvesafb mode_option=1024x768-32 mtrr=3 scroll=ywrap (module)
55
56		Accepted options:
57
58		ypan Enable display panning using the VESA protected mode
59		interface. The visible screen is just a window of the
60		video memory, console scrolling is done by changing the
61		start of the window. This option is available on x86
62		only and is the default option on that architecture.
63
64		ywrap Same as ypan, but assumes your gfx board can wrap-around
65		the video memory (i.e. starts reading from top if it
66		reaches the end of video memory). Faster than ypan.
67		Available on x86 only.
68
69		redraw Scroll by redrawing the affected part of the screen, this
70		is the default on non-x86.
71
72		(If you're using uvesafb as a module, the above three options are
73		used a parameter of the scroll option, e.g. scroll=ypan.)
74
75		vgapal Use the standard VGA registers for palette changes.
76
77		pmipal Use the protected mode interface for palette changes.
78		This is the default if the protected mode interface is
79		available. Available on x86 only.
80
81		mtrr:n Setup memory type range registers for the framebuffer
82		where n:
83		0 - disabled (equivalent to nomtrr)
84		3 - write-combining (default)
85
86		Values other than 0 and 3 will result in a warning and will be
87		treated just like 3.
88
89		nomtrr Do not use memory type range registers.
90
91		vremap:n
92		Remap 'n' MiB of video RAM. If 0 or not specified, remap memory
93		according to video mode.
94
95		vtotal:n
96		If the video BIOS of your card incorrectly determines the total
97		amount of video RAM, use this option to override the BIOS (in MiB).
98
99		<mode> The mode you want to set, in the standard modedb format. Refer to
100		modedb.txt for a detailed description. When uvesafb is compiled as
101		a module, the mode string should be provided as a value of the
102		'mode_option' option.
103
104		vbemode:x
105		Force the use of VBE mode x. The mode will only be set if it's
106		found in the VBE-provided list of supported modes.
107		NOTE: The mode number 'x' should be specified in VESA mode number
108		notation, not the Linux kernel one (eg. 257 instead of 769).
109		HINT: If you use this option because normal <mode> parameter does
110		not work for you and you use a X server, you'll probably want to
111		set the 'nocrtc' option to ensure that the video mode is properly
112		restored after console <-> X switches.
113
114		nocrtc Do not use CRTC timings while setting the video mode. This option
115		has any effect only if the Video BIOS is VBE 3.0 compliant. Use it
116		if you have problems with modes set the standard way. Note that
117		using this option implies that any refresh rate adjustments will
118		be ignored and the refresh rate will stay at your BIOS default (60 Hz).
119
120		noedid Do not try to fetch and use EDID-provided modes.
121
122		noblank Disable hardware blanking.
123
124		v86d:path
125		Set path to the v86d executable. This option is only available as
126		a module parameter, and not as a part of the video= string. If you
127		need to use it and have uvesafb built into the kernel, use
128		uvesafb.v86d="path".
129
130		Additionally, the following parameters may be provided. They all override the
131		EDID-provided values and BIOS defaults. Refer to your monitor's specs to get
132		the correct values for maxhf, maxvf and maxclk for your hardware.
133
134		maxhf:n Maximum horizontal frequency (in kHz).
135		maxvf:n Maximum vertical frequency (in Hz).
136		maxclk:n Maximum pixel clock (in MHz).
137
138		4. The sysfs interface
139		----------------------
140
141		uvesafb provides several sysfs nodes for configurable parameters and
142		additional information.
143
144		Driver attributes:
145
146		/sys/bus/platform/drivers/uvesafb
147		- v86d (default: /sbin/v86d)
148		Path to the v86d executable. v86d is started by uvesafb
149		if an instance of the daemon isn't already running.
150
151		Device attributes:
152
153		/sys/bus/platform/drivers/uvesafb/uvesafb.0
154		- nocrtc
155		Use the default refresh rate (60 Hz) if set to 1.
156
157		- oem_product_name
158		- oem_product_rev
159		- oem_string
160		- oem_vendor
161		Information about the card and its maker.
162
163		- vbe_modes
164		A list of video modes supported by the Video BIOS along with their
165		VBE mode numbers in hex.
166
167		- vbe_version
168		A BCD value indicating the implemented VBE standard.
169
170		5. Miscellaneous
171		----------------
172
173		Uvesafb will set a video mode with the default refresh rate and timings
174		from the Video BIOS if you set pixclock to 0 in fb_var_screeninfo.
175
176
177		--
178		Michal Januszewski <spock@gentoo.org>
179		Last updated: 2009-03-30
180
181		Documentation of the uvesafb options is loosely based on vesafb.txt.
182

+192

-0

debian/doc/kernel-doc/vesafb.rst less more

	0	===============
	1	What is vesafb?
	2	===============
	3
	4	This is a generic driver for a graphic framebuffer on intel boxes.
	5
	6	The idea is simple: Turn on graphics mode at boot time with the help
	7	of the BIOS, and use this as framebuffer device /dev/fb0, like the m68k
	8	(and other) ports do.
	9
	10	This means we decide at boot time whenever we want to run in text or
	11	graphics mode. Switching mode later on (in protected mode) is
	12	impossible; BIOS calls work in real mode only. VESA BIOS Extensions
	13	Version 2.0 are required, because we need a linear frame buffer.
	14
	15	Advantages:
	16
	17	* It provides a nice large console (128 cols + 48 lines with 1024x768)
	18	without using tiny, unreadable fonts.
	19	* You can run XF68_FBDev on top of /dev/fb0 (=> non-accelerated X11
	20	support for every VBE 2.0 compliant graphics board).
	21	* Most important: boot logo :-)
	22
	23	Disadvantages:
	24
	25	* graphic mode is slower than text mode...
	26
	27
	28	How to use it?
	29	==============
	30
	31	Switching modes is done using the vga=... boot parameter. Read
	32	Documentation/admin-guide/svga.rst for details.
	33
	34	You should compile in both vgacon (for text mode) and vesafb (for
	35	graphics mode). Which of them takes over the console depends on
	36	whenever the specified mode is text or graphics.
	37
	38	The graphic modes are NOT in the list which you get if you boot with
	39	vga=ask and hit return. The mode you wish to use is derived from the
	40	VESA mode number. Here are those VESA mode numbers:
	41
	42	====== ======= ======= ======== =========
	43	colors 640x480 800x600 1024x768 1280x1024
	44	====== ======= ======= ======== =========
	45	256 0x101 0x103 0x105 0x107
	46	32k 0x110 0x113 0x116 0x119
	47	64k 0x111 0x114 0x117 0x11A
	48	16M 0x112 0x115 0x118 0x11B
	49	====== ======= ======= ======== =========
	50
	51
	52	The video mode number of the Linux kernel is the VESA mode number plus
	53	0x200:
	54
	55	Linux_kernel_mode_number = VESA_mode_number + 0x200
	56
	57	So the table for the Kernel mode numbers are:
	58
	59	====== ======= ======= ======== =========
	60	colors 640x480 800x600 1024x768 1280x1024
	61	====== ======= ======= ======== =========
	62	256 0x301 0x303 0x305 0x307
	63	32k 0x310 0x313 0x316 0x319
	64	64k 0x311 0x314 0x317 0x31A
	65	16M 0x312 0x315 0x318 0x31B
	66	====== ======= ======= ======== =========
	67
	68	To enable one of those modes you have to specify "vga=ask" in the
	69	lilo.conf file and rerun LILO. Then you can type in the desired
	70	mode at the "vga=ask" prompt. For example if you like to use
	71	1024x768x256 colors you have to say "305" at this prompt.
	72
	73	If this does not work, this might be because your BIOS does not support
	74	linear framebuffers or because it does not support this mode at all.
	75	Even if your board does, it might be the BIOS which does not. VESA BIOS
	76	Extensions v2.0 are required, 1.2 is NOT sufficient. You will get a
	77	"bad mode number" message if something goes wrong.
	78
	79	1. Note: LILO cannot handle hex, for booting directly with
	80	"vga=mode-number" you have to transform the numbers to decimal.
	81	2. Note: Some newer versions of LILO appear to work with those hex values,
	82	if you set the 0x in front of the numbers.
	83
	84	X11
	85	===
	86
	87	XF68_FBDev should work just fine, but it is non-accelerated. Running
	88	another (accelerated) X-Server like XF86_SVGA might or might not work.
	89	It depends on X-Server and graphics board.
	90
	91	The X-Server must restore the video mode correctly, else you end up
	92	with a broken console (and vesafb cannot do anything about this).
	93
	94
	95	Refresh rates
	96	=============
	97
	98	There is no way to change the vesafb video mode and/or timings after
	99	booting linux. If you are not happy with the 60 Hz refresh rate, you
	100	have these options:
	101
	102	* configure and load the DOS-Tools for the graphics board (if
	103	available) and boot linux with loadlin.
	104	* use a native driver (matroxfb/atyfb) instead if vesafb. If none
	105	is available, write a new one!
	106	* VBE 3.0 might work too. I have neither a gfx board with VBE 3.0
	107	support nor the specs, so I have not checked this yet.
	108
	109
	110	Configuration
	111	=============
	112
	113	The VESA BIOS provides protected mode interface for changing
	114	some parameters. vesafb can use it for palette changes and
	115	to pan the display. It is turned off by default because it
	116	seems not to work with some BIOS versions, but there are options
	117	to turn it on.
	118
	119	You can pass options to vesafb using "video=vesafb:option" on
	120	the kernel command line. Multiple options should be separated
	121	by comma, like this: "video=vesafb:ypan,inverse"
	122
	123	Accepted options:
	124
	125	inverse use inverse color map
	126
	127	========= ======================================================================
	128	ypan enable display panning using the VESA protected mode
	129	interface. The visible screen is just a window of the
	130	video memory, console scrolling is done by changing the
	131	start of the window.
	132
	133	pro:
	134
	135	* scrolling (fullscreen) is fast, because there is
	136	no need to copy around data.
	137	* You'll get scrollback (the Shift-PgUp thing),
	138	the video memory can be used as scrollback buffer
	139
	140	kontra:
	141
	142	* scrolling only parts of the screen causes some
	143	ugly flicker effects (boot logo flickers for
	144	example).
	145
	146	ywrap Same as ypan, but assumes your gfx board can wrap-around
	147	the video memory (i.e. starts reading from top if it
	148	reaches the end of video memory). Faster than ypan.
	149
	150	redraw Scroll by redrawing the affected part of the screen, this
	151	is the safe (and slow) default.
	152
	153
	154	vgapal Use the standard vga registers for palette changes.
	155	This is the default.
	156	pmipal Use the protected mode interface for palette changes.
	157
	158	mtrr:n Setup memory type range registers for the vesafb framebuffer
	159	where n:
	160
	161	- 0 - disabled (equivalent to nomtrr) (default)
	162	- 1 - uncachable
	163	- 2 - write-back
	164	- 3 - write-combining
	165	- 4 - write-through
	166
	167	If you see the following in dmesg, choose the type that matches the
	168	old one. In this example, use "mtrr:2".
	169	...
	170	mtrr: type mismatch for e0000000,8000000 old: write-back new:
	171	write-combining
	172	...
	173
	174	nomtrr disable mtrr
	175
	176	vremap:n
	177	Remap 'n' MiB of video RAM. If 0 or not specified, remap memory
	178	according to video mode. (2.5.66 patch/idea by Antonino Daplas
	179	reversed to give override possibility (allocate more fb memory
	180	than the kernel would) to 2.4 by tmb@iki.fi)
	181
	182	vtotal:n If the video BIOS of your card incorrectly determines the total
	183	amount of video RAM, use this option to override the BIOS (in MiB).
	184	========= ======================================================================
	185
	186	Have fun!
	187
	188	Gerd Knorr <kraxel@goldbach.in-berlin.de>
	189
	190	Minor (mostly typo) changes
	191	by Nico Schmoigl <schmoigl@rumms.uni-mannheim.de>

-181

~~debian/doc/kernel-doc/vesafb.txt~~ less more

0
1		What is vesafb?
2		===============
3
4		This is a generic driver for a graphic framebuffer on intel boxes.
5
6		The idea is simple: Turn on graphics mode at boot time with the help
7		of the BIOS, and use this as framebuffer device /dev/fb0, like the m68k
8		(and other) ports do.
9
10		This means we decide at boot time whenever we want to run in text or
11		graphics mode. Switching mode later on (in protected mode) is
12		impossible; BIOS calls work in real mode only. VESA BIOS Extensions
13		Version 2.0 are required, because we need a linear frame buffer.
14
15		Advantages:
16
17		* It provides a nice large console (128 cols + 48 lines with 1024x768)
18		without using tiny, unreadable fonts.
19		* You can run XF68_FBDev on top of /dev/fb0 (=> non-accelerated X11
20		support for every VBE 2.0 compliant graphics board).
21		* Most important: boot logo :-)
22
23		Disadvantages:
24
25		* graphic mode is slower than text mode...
26
27
28		How to use it?
29		==============
30
31		Switching modes is done using the vga=... boot parameter. Read
32		Documentation/svga.txt for details.
33
34		You should compile in both vgacon (for text mode) and vesafb (for
35		graphics mode). Which of them takes over the console depends on
36		whenever the specified mode is text or graphics.
37
38		The graphic modes are NOT in the list which you get if you boot with
39		vga=ask and hit return. The mode you wish to use is derived from the
40		VESA mode number. Here are those VESA mode numbers:
41
42		\| 640x480 800x600 1024x768 1280x1024
43		----+-------------------------------------
44		256 \| 0x101 0x103 0x105 0x107
45		32k \| 0x110 0x113 0x116 0x119
46		64k \| 0x111 0x114 0x117 0x11A
47		16M \| 0x112 0x115 0x118 0x11B
48
49		The video mode number of the Linux kernel is the VESA mode number plus
50		0x200.
51
52		Linux_kernel_mode_number = VESA_mode_number + 0x200
53
54		So the table for the Kernel mode numbers are:
55
56		\| 640x480 800x600 1024x768 1280x1024
57		----+-------------------------------------
58		256 \| 0x301 0x303 0x305 0x307
59		32k \| 0x310 0x313 0x316 0x319
60		64k \| 0x311 0x314 0x317 0x31A
61		16M \| 0x312 0x315 0x318 0x31B
62
63		To enable one of those modes you have to specify "vga=ask" in the
64		lilo.conf file and rerun LILO. Then you can type in the desired
65		mode at the "vga=ask" prompt. For example if you like to use
66		1024x768x256 colors you have to say "305" at this prompt.
67
68		If this does not work, this might be because your BIOS does not support
69		linear framebuffers or because it does not support this mode at all.
70		Even if your board does, it might be the BIOS which does not. VESA BIOS
71		Extensions v2.0 are required, 1.2 is NOT sufficient. You will get a
72		"bad mode number" message if something goes wrong.
73
74		1. Note: LILO cannot handle hex, for booting directly with
75		"vga=mode-number" you have to transform the numbers to decimal.
76		2. Note: Some newer versions of LILO appear to work with those hex values,
77		if you set the 0x in front of the numbers.
78
79		X11
80		===
81
82		XF68_FBDev should work just fine, but it is non-accelerated. Running
83		another (accelerated) X-Server like XF86_SVGA might or might not work.
84		It depends on X-Server and graphics board.
85
86		The X-Server must restore the video mode correctly, else you end up
87		with a broken console (and vesafb cannot do anything about this).
88
89
90		Refresh rates
91		=============
92
93		There is no way to change the vesafb video mode and/or timings after
94		booting linux. If you are not happy with the 60 Hz refresh rate, you
95		have these options:
96
97		* configure and load the DOS-Tools for the graphics board (if
98		available) and boot linux with loadlin.
99		* use a native driver (matroxfb/atyfb) instead if vesafb. If none
100		is available, write a new one!
101		* VBE 3.0 might work too. I have neither a gfx board with VBE 3.0
102		support nor the specs, so I have not checked this yet.
103
104
105		Configuration
106		=============
107
108		The VESA BIOS provides protected mode interface for changing
109		some parameters. vesafb can use it for palette changes and
110		to pan the display. It is turned off by default because it
111		seems not to work with some BIOS versions, but there are options
112		to turn it on.
113
114		You can pass options to vesafb using "video=vesafb:option" on
115		the kernel command line. Multiple options should be separated
116		by comma, like this: "video=vesafb:ypan,invers"
117
118		Accepted options:
119
120		invers no comment...
121
122		ypan enable display panning using the VESA protected mode
123		interface. The visible screen is just a window of the
124		video memory, console scrolling is done by changing the
125		start of the window.
126		pro: * scrolling (fullscreen) is fast, because there is
127		no need to copy around data.
128		* You'll get scrollback (the Shift-PgUp thing),
129		the video memory can be used as scrollback buffer
130		kontra: * scrolling only parts of the screen causes some
131		ugly flicker effects (boot logo flickers for
132		example).
133
134		ywrap Same as ypan, but assumes your gfx board can wrap-around
135		the video memory (i.e. starts reading from top if it
136		reaches the end of video memory). Faster than ypan.
137
138		redraw scroll by redrawing the affected part of the screen, this
139		is the safe (and slow) default.
140
141
142		vgapal Use the standard vga registers for palette changes.
143		This is the default.
144		pmipal Use the protected mode interface for palette changes.
145
146		mtrr:n setup memory type range registers for the vesafb framebuffer
147		where n:
148		0 - disabled (equivalent to nomtrr) (default)
149		1 - uncachable
150		2 - write-back
151		3 - write-combining
152		4 - write-through
153
154		If you see the following in dmesg, choose the type that matches the
155		old one. In this example, use "mtrr:2".
156		...
157		mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining
158		...
159
160		nomtrr disable mtrr
161
162		vremap:n
163		remap 'n' MiB of video RAM. If 0 or not specified, remap memory
164		according to video mode. (2.5.66 patch/idea by Antonino Daplas
165		reversed to give override possibility (allocate more fb memory
166		than the kernel would) to 2.4 by tmb@iki.fi)
167
168		vtotal:n
169		if the video BIOS of your card incorrectly determines the total
170		amount of video RAM, use this option to override the BIOS (in MiB).
171
172		Have fun!
173
174		Gerd
175
176		--
177		Gerd Knorr <kraxel@goldbach.in-berlin.de>
178
179		Minor (mostly typo) changes
180		by Nico Schmoigl <schmoigl@rumms.uni-mannheim.de>

+870

-0

debian/doc/kernel-doc/viafb.modes less more

	0	#
	1	#
	2	# These data are based on the CRTC parameters in
	3	#
	4	# VIA Integration Graphics Chip
	5	# (C) 2004 VIA Technologies Inc.
	6	#
	7
	8	#
	9	# 640x480, 60 Hz, Non-Interlaced (25.175 MHz dotclock)
	10	#
	11	# Horizontal Vertical
	12	# Resolution 640 480
	13	# Scan Frequency 31.469 kHz 59.94 Hz
	14	# Sync Width 3.813 us 0.064 ms
	15	# 12 chars 2 lines
	16	# Front Porch 0.636 us 0.318 ms
	17	# 2 chars 10 lines
	18	# Back Porch 1.907 us 1.048 ms
	19	# 6 chars 33 lines
	20	# Active Time 25.422 us 15.253 ms
	21	# 80 chars 480 lines
	22	# Blank Time 6.356 us 1.430 ms
	23	# 20 chars 45 lines
	24	# Polarity negative negative
	25	#
	26
	27	mode "640x480-60"
	28	# D: 25.175 MHz, H: 31.469 kHz, V: 59.94 Hz
	29	geometry 640 480 640 480 32
	30	timings 39722 48 16 33 10 96 2 endmode mode "480x640-60"
	31	# D: 24.823 MHz, H: 39.780 kHz, V: 60.00 Hz
	32	geometry 480 640 480 640 32 timings 39722 72 24 19 1 48 3 endmode
	33	#
	34	# 640x480, 75 Hz, Non-Interlaced (31.50 MHz dotclock)
	35	#
	36	# Horizontal Vertical
	37	# Resolution 640 480
	38	# Scan Frequency 37.500 kHz 75.00 Hz
	39	# Sync Width 2.032 us 0.080 ms
	40	# 8 chars 3 lines
	41	# Front Porch 0.508 us 0.027 ms
	42	# 2 chars 1 lines
	43	# Back Porch 3.810 us 0.427 ms
	44	# 15 chars 16 lines
	45	# Active Time 20.317 us 12.800 ms
	46	# 80 chars 480 lines
	47	# Blank Time 6.349 us 0.533 ms
	48	# 25 chars 20 lines
	49	# Polarity negative negative
	50	#
	51	mode "640x480-75"
	52	# D: 31.50 MHz, H: 37.500 kHz, V: 75.00 Hz
	53	geometry 640 480 640 480 32 timings 31747 120 16 16 1 64 3 endmode
	54	#
	55	# 640x480, 85 Hz, Non-Interlaced (36.000 MHz dotclock)
	56	#
	57	# Horizontal Vertical
	58	# Resolution 640 480
	59	# Scan Frequency 43.269 kHz 85.00 Hz
	60	# Sync Width 1.556 us 0.069 ms
	61	# 7 chars 3 lines
	62	# Front Porch 1.556 us 0.023 ms
	63	# 7 chars 1 lines
	64	# Back Porch 2.222 us 0.578 ms
	65	# 10 chars 25 lines
	66	# Active Time 17.778 us 11.093 ms
	67	# 80 chars 480 lines
	68	# Blank Time 5.333 us 0.670 ms
	69	# 24 chars 29 lines
	70	# Polarity negative negative
	71	#
	72	mode "640x480-85"
	73	# D: 36.000 MHz, H: 43.269 kHz, V: 85.00 Hz
	74	geometry 640 480 640 480 32 timings 27777 80 56 25 1 56 3 endmode
	75	#
	76	# 640x480, 100 Hz, Non-Interlaced (43.163 MHz dotclock)
	77	#
	78	# Horizontal Vertical
	79	# Resolution 640 480
	80	# Scan Frequency 50.900 kHz 100.00 Hz
	81	# Sync Width 1.483 us 0.058 ms
	82	# 8 chars 3 lines
	83	# Front Porch 0.927 us 0.019 ms
	84	# 5 chars 1 lines
	85	# Back Porch 2.409 us 0.475 ms
	86	# 13 chars 25 lines
	87	# Active Time 14.827 us 9.430 ms
	88	# 80 chars 480 lines
	89	# Blank Time 4.819 us 0.570 ms
	90	# 26 chars 29 lines
	91	# Polarity positive positive
	92	#
	93	mode "640x480-100"
	94	# D: 43.163 MHz, H: 50.900 kHz, V: 100.00 Hz
	95	geometry 640 480 640 480 32 timings 23168 104 40 25 1 64 3 endmode
	96	#
	97	# 640x480, 120 Hz, Non-Interlaced (52.406 MHz dotclock)
	98	#
	99	# Horizontal Vertical
	100	# Resolution 640 480
	101	# Scan Frequency 61.800 kHz 120.00 Hz
	102	# Sync Width 1.221 us 0.048 ms
	103	# 8 chars 3 lines
	104	# Front Porch 0.763 us 0.016 ms
	105	# 5 chars 1 lines
	106	# Back Porch 1.984 us 0.496 ms
	107	# 13 chars 31 lines
	108	# Active Time 12.212 us 7.767 ms
	109	# 80 chars 480 lines
	110	# Blank Time 3.969 us 0.566 ms
	111	# 26 chars 35 lines
	112	# Polarity positive positive
	113	#
	114	mode "640x480-120"
	115	# D: 52.406 MHz, H: 61.800 kHz, V: 120.00 Hz
	116	geometry 640 480 640 480 32 timings 19081 104 40 31 1 64 3 endmode
	117	#
	118	# 720x480, 60 Hz, Non-Interlaced (26.880 MHz dotclock)
	119	#
	120	# Horizontal Vertical
	121	# Resolution 720 480
	122	# Scan Frequency 30.000 kHz 60.241 Hz
	123	# Sync Width 2.679 us 0.099 ms
	124	# 9 chars 3 lines
	125	# Front Porch 0.595 us 0.033 ms
	126	# 2 chars 1 lines
	127	# Back Porch 3.274 us 0.462 ms
	128	# 11 chars 14 lines
	129	# Active Time 26.786 us 16.000 ms
	130	# 90 chars 480 lines
	131	# Blank Time 6.548 us 0.600 ms
	132	# 22 chars 18 lines
	133	# Polarity positive positive
	134	#
	135	mode "720x480-60"
	136	# D: 26.880 MHz, H: 30.000 kHz, V: 60.24 Hz
	137	geometry 720 480 720 480 32 timings 37202 88 16 14 1 72 3 endmode
	138	#
	139	# 800x480, 60 Hz, Non-Interlaced (29.581 MHz dotclock)
	140	#
	141	# Horizontal Vertical
	142	# Resolution 800 480
	143	# Scan Frequency 29.892 kHz 60.00 Hz
	144	# Sync Width 2.704 us 100.604 us
	145	# 10 chars 3 lines
	146	# Front Porch 0.541 us 33.535 us
	147	# 2 chars 1 lines
	148	# Back Porch 3.245 us 435.949 us
	149	# 12 chars 13 lines
	150	# Active Time 27.044 us 16.097 ms
	151	# 100 chars 480 lines
	152	# Blank Time 6.491 us 0.570 ms
	153	# 24 chars 17 lines
	154	# Polarity positive positive
	155	#
	156	mode "800x480-60"
	157	# D: 29.500 MHz, H: 29.738 kHz, V: 60.00 Hz
	158	geometry 800 480 800 480 32 timings 33805 96 24 10 3 72 7 endmode
	159	#
	160	# 720x576, 60 Hz, Non-Interlaced (32.668 MHz dotclock)
	161	#
	162	# Horizontal Vertical
	163	# Resolution 720 576
	164	# Scan Frequency 35.820 kHz 60.00 Hz
	165	# Sync Width 2.204 us 0.083 ms
	166	# 9 chars 3 lines
	167	# Front Porch 0.735 us 0.027 ms
	168	# 3 chars 1 lines
	169	# Back Porch 2.939 us 0.459 ms
	170	# 12 chars 17 lines
	171	# Active Time 22.040 us 16.080 ms
	172	# 90 chars 476 lines
	173	# Blank Time 5.877 us 0.586 ms
	174	# 24 chars 21 lines
	175	# Polarity positive positive
	176	#
	177	mode "720x576-60"
	178	# D: 32.668 MHz, H: 35.820 kHz, V: 60.00 Hz
	179	geometry 720 576 720 576 32 timings 30611 96 24 17 1 72 3 endmode
	180	#
	181	# 800x600, 60 Hz, Non-Interlaced (40.00 MHz dotclock)
	182	#
	183	# Horizontal Vertical
	184	# Resolution 800 600
	185	# Scan Frequency 37.879 kHz 60.32 Hz
	186	# Sync Width 3.200 us 0.106 ms
	187	# 16 chars 4 lines
	188	# Front Porch 1.000 us 0.026 ms
	189	# 5 chars 1 lines
	190	# Back Porch 2.200 us 0.607 ms
	191	# 11 chars 23 lines
	192	# Active Time 20.000 us 15.840 ms
	193	# 100 chars 600 lines
	194	# Blank Time 6.400 us 0.739 ms
	195	# 32 chars 28 lines
	196	# Polarity positive positive
	197	#
	198	mode "800x600-60"
	199	# D: 40.00 MHz, H: 37.879 kHz, V: 60.32 Hz
	200	geometry 800 600 800 600 32
	201	timings 25000 88 40 23 1 128 4 hsync high vsync high endmode
	202	#
	203	# 800x600, 75 Hz, Non-Interlaced (49.50 MHz dotclock)
	204	#
	205	# Horizontal Vertical
	206	# Resolution 800 600
	207	# Scan Frequency 46.875 kHz 75.00 Hz
	208	# Sync Width 1.616 us 0.064 ms
	209	# 10 chars 3 lines
	210	# Front Porch 0.323 us 0.021 ms
	211	# 2 chars 1 lines
	212	# Back Porch 3.232 us 0.448 ms
	213	# 20 chars 21 lines
	214	# Active Time 16.162 us 12.800 ms
	215	# 100 chars 600 lines
	216	# Blank Time 5.172 us 0.533 ms
	217	# 32 chars 25 lines
	218	# Polarity positive positive
	219	#
	220	mode "800x600-75"
	221	# D: 49.50 MHz, H: 46.875 kHz, V: 75.00 Hz
	222	geometry 800 600 800 600 32
	223	timings 20203 160 16 21 1 80 3 hsync high vsync high endmode
	224	#
	225	# 800x600, 85 Hz, Non-Interlaced (56.25 MHz dotclock)
	226	#
	227	# Horizontal Vertical
	228	# Resolution 800 600
	229	# Scan Frequency 53.674 kHz 85.061 Hz
	230	# Sync Width 1.138 us 0.056 ms
	231	# 8 chars 3 lines
	232	# Front Porch 0.569 us 0.019 ms
	233	# 4 chars 1 lines
	234	# Back Porch 2.702 us 0.503 ms
	235	# 19 chars 27 lines
	236	# Active Time 14.222 us 11.179 ms
	237	# 100 chars 600 lines
	238	# Blank Time 4.409 us 0.578 ms
	239	# 31 chars 31 lines
	240	# Polarity positive positive
	241	#
	242	mode "800x600-85"
	243	# D: 56.25 MHz, H: 53.674 kHz, V: 85.061 Hz
	244	geometry 800 600 800 600 32
	245	timings 17777 152 32 27 1 64 3 hsync high vsync high endmode
	246	#
	247	# 800x600, 100 Hz, Non-Interlaced (67.50 MHz dotclock)
	248	#
	249	# Horizontal Vertical
	250	# Resolution 800 600
	251	# Scan Frequency 62.500 kHz 100.00 Hz
	252	# Sync Width 0.948 us 0.064 ms
	253	# 8 chars 4 lines
	254	# Front Porch 0.000 us 0.112 ms
	255	# 0 chars 7 lines
	256	# Back Porch 3.200 us 0.224 ms
	257	# 27 chars 14 lines
	258	# Active Time 11.852 us 9.600 ms
	259	# 100 chars 600 lines
	260	# Blank Time 4.148 us 0.400 ms
	261	# 35 chars 25 lines
	262	# Polarity positive positive
	263	#
	264	mode "800x600-100"
	265	# D: 67.50 MHz, H: 62.500 kHz, V: 100.00 Hz
	266	geometry 800 600 800 600 32
	267	timings 14667 216 0 14 7 64 4 hsync high vsync high endmode
	268	#
	269	# 800x600, 120 Hz, Non-Interlaced (83.950 MHz dotclock)
	270	#
	271	# Horizontal Vertical
	272	# Resolution 800 600
	273	# Scan Frequency 77.160 kHz 120.00 Hz
	274	# Sync Width 1.048 us 0.039 ms
	275	# 11 chars 3 lines
	276	# Front Porch 0.667 us 0.013 ms
	277	# 7 chars 1 lines
	278	# Back Porch 1.715 us 0.507 ms
	279	# 18 chars 39 lines
	280	# Active Time 9.529 us 7.776 ms
	281	# 100 chars 600 lines
	282	# Blank Time 3.431 us 0.557 ms
	283	# 36 chars 43 lines
	284	# Polarity positive positive
	285	#
	286	mode "800x600-120"
	287	# D: 83.950 MHz, H: 77.160 kHz, V: 120.00 Hz
	288	geometry 800 600 800 600 32
	289	timings 11912 144 56 39 1 88 3 hsync high vsync high endmode
	290	#
	291	# 848x480, 60 Hz, Non-Interlaced (31.490 MHz dotclock)
	292	#
	293	# Horizontal Vertical
	294	# Resolution 848 480
	295	# Scan Frequency 29.820 kHz 60.00 Hz
	296	# Sync Width 2.795 us 0.099 ms
	297	# 11 chars 3 lines
	298	# Front Porch 0.508 us 0.033 ms
	299	# 2 chars 1 lines
	300	# Back Porch 3.303 us 0.429 ms
	301	# 13 chars 13 lines
	302	# Active Time 26.929 us 16.097 ms
	303	# 106 chars 480 lines
	304	# Blank Time 6.605 us 0.570 ms
	305	# 26 chars 17 lines
	306	# Polarity positive positive
	307	#
	308	mode "848x480-60"
	309	# D: 31.500 MHz, H: 29.830 kHz, V: 60.00 Hz
	310	geometry 848 480 848 480 32
	311	timings 31746 104 24 12 3 80 5 hsync high vsync high endmode
	312	#
	313	# 856x480, 60 Hz, Non-Interlaced (31.728 MHz dotclock)
	314	#
	315	# Horizontal Vertical
	316	# Resolution 856 480
	317	# Scan Frequency 29.820 kHz 60.00 Hz
	318	# Sync Width 2.774 us 0.099 ms
	319	# 11 chars 3 lines
	320	# Front Porch 0.504 us 0.033 ms
	321	# 2 chars 1 lines
	322	# Back Porch 3.728 us 0.429 ms
	323	# 13 chars 13 lines
	324	# Active Time 26.979 us 16.097 ms
	325	# 107 chars 480 lines
	326	# Blank Time 6.556 us 0.570 ms
	327	# 26 chars 17 lines
	328	# Polarity positive positive
	329	#
	330	mode "856x480-60"
	331	# D: 31.728 MHz, H: 29.820 kHz, V: 60.00 Hz
	332	geometry 856 480 856 480 32
	333	timings 31518 104 16 13 1 88 3
	334	hsync high vsync high endmode mode "960x600-60"
	335	# D: 45.250 MHz, H: 37.212 kHz, V: 60.00 Hz
	336	geometry 960 600 960 600 32 timings 22099 128 32 15 3 96 6 endmode
	337	#
	338	# 1000x600, 60 Hz, Non-Interlaced (48.068 MHz dotclock)
	339	#
	340	# Horizontal Vertical
	341	# Resolution 1000 600
	342	# Scan Frequency 37.320 kHz 60.00 Hz
	343	# Sync Width 2.164 us 0.080 ms
	344	# 13 chars 3 lines
	345	# Front Porch 0.832 us 0.027 ms
	346	# 5 chars 1 lines
	347	# Back Porch 2.996 us 0.483 ms
	348	# 18 chars 18 lines
	349	# Active Time 20.804 us 16.077 ms
	350	# 125 chars 600 lines
	351	# Blank Time 5.991 us 0.589 ms
	352	# 36 chars 22 lines
	353	# Polarity negative positive
	354	#
	355	mode "1000x600-60"
	356	# D: 48.068 MHz, H: 37.320 kHz, V: 60.00 Hz
	357	geometry 1000 600 1000 600 32
	358	timings 20834 144 40 18 1 104 3 endmode mode "1024x576-60"
	359	# D: 46.996 MHz, H: 35.820 kHz, V: 60.00 Hz
	360	geometry 1024 576 1024 576 32
	361	timings 21278 144 40 17 1 104 3 endmode mode "1024x600-60"
	362	# D: 48.964 MHz, H: 37.320 kHz, V: 60.00 Hz
	363	geometry 1024 600 1024 600 32
	364	timings 20461 144 40 18 1 104 3 endmode mode "1088x612-60"
	365	# D: 52.952 MHz, H: 38.040 kHz, V: 60.00 Hz
	366	geometry 1088 612 1088 612 32 timings 18877 152 48 16 3 104 5 endmode
	367	#
	368	# 1024x512, 60 Hz, Non-Interlaced (41.291 MHz dotclock)
	369	#
	370	# Horizontal Vertical
	371	# Resolution 1024 512
	372	# Scan Frequency 31.860 kHz 60.00 Hz
	373	# Sync Width 2.519 us 0.094 ms
	374	# 13 chars 3 lines
	375	# Front Porch 0.775 us 0.031 ms
	376	# 4 chars 1 lines
	377	# Back Porch 3.294 us 0.465 ms
	378	# 17 chars 15 lines
	379	# Active Time 24.800 us 16.070 ms
	380	# 128 chars 512 lines
	381	# Blank Time 6.587 us 0.596 ms
	382	# 34 chars 19 lines
	383	# Polarity positive positive
	384	#
	385	mode "1024x512-60"
	386	# D: 41.291 MHz, H: 31.860 kHz, V: 60.00 Hz
	387	geometry 1024 512 1024 512 32
	388	timings 24218 126 32 15 1 104 3 hsync high vsync high endmode
	389	#
	390	# 1024x600, 60 Hz, Non-Interlaced (48.875 MHz dotclock)
	391	#
	392	# Horizontal Vertical
	393	# Resolution 1024 768
	394	# Scan Frequency 37.252 kHz 60.00 Hz
	395	# Sync Width 2.128 us 80.532us
	396	# 13 chars 3 lines
	397	# Front Porch 0.818 us 26.844 us
	398	# 5 chars 1 lines
	399	# Back Porch 2.946 us 483.192 us
	400	# 18 chars 18 lines
	401	# Active Time 20.951 us 16.697 ms
	402	# 128 chars 622 lines
	403	# Blank Time 5.893 us 0.591 ms
	404	# 36 chars 22 lines
	405	# Polarity negative positive
	406	#
	407	#mode "1024x600-60"
	408	# # D: 48.875 MHz, H: 37.252 kHz, V: 60.00 Hz
	409	# geometry 1024 600 1024 600 32
	410	# timings 20460 144 40 18 1 104 3
	411	# endmode
	412	#
	413	# 1024x768, 60 Hz, Non-Interlaced (65.00 MHz dotclock)
	414	#
	415	# Horizontal Vertical
	416	# Resolution 1024 768
	417	# Scan Frequency 48.363 kHz 60.00 Hz
	418	# Sync Width 2.092 us 0.124 ms
	419	# 17 chars 6 lines
	420	# Front Porch 0.369 us 0.062 ms
	421	# 3 chars 3 lines
	422	# Back Porch 2.462 us 0.601 ms
	423	# 20 chars 29 lines
	424	# Active Time 15.754 us 15.880 ms
	425	# 128 chars 768 lines
	426	# Blank Time 4.923 us 0.786 ms
	427	# 40 chars 38 lines
	428	# Polarity negative negative
	429	#
	430	mode "1024x768-60"
	431	# D: 65.00 MHz, H: 48.363 kHz, V: 60.00 Hz
	432	geometry 1024 768 1024 768 32 timings 15385 160 24 29 3 136 6 endmode
	433	#
	434	# 1024x768, 75 Hz, Non-Interlaced (78.75 MHz dotclock)
	435	#
	436	# Horizontal Vertical
	437	# Resolution 1024 768
	438	# Scan Frequency 60.023 kHz 75.03 Hz
	439	# Sync Width 1.219 us 0.050 ms
	440	# 12 chars 3 lines
	441	# Front Porch 0.203 us 0.017 ms
	442	# 2 chars 1 lines
	443	# Back Porch 2.235 us 0.466 ms
	444	# 22 chars 28 lines
	445	# Active Time 13.003 us 12.795 ms
	446	# 128 chars 768 lines
	447	# Blank Time 3.657 us 0.533 ms
	448	# 36 chars 32 lines
	449	# Polarity positive positive
	450	#
	451	mode "1024x768-75"
	452	# D: 78.75 MHz, H: 60.023 kHz, V: 75.03 Hz
	453	geometry 1024 768 1024 768 32
	454	timings 12699 176 16 28 1 96 3 hsync high vsync high endmode
	455	#
	456	# 1024x768, 85 Hz, Non-Interlaced (94.50 MHz dotclock)
	457	#
	458	# Horizontal Vertical
	459	# Resolution 1024 768
	460	# Scan Frequency 68.677 kHz 85.00 Hz
	461	# Sync Width 1.016 us 0.044 ms
	462	# 12 chars 3 lines
	463	# Front Porch 0.508 us 0.015 ms
	464	# 6 chars 1 lines
	465	# Back Porch 2.201 us 0.524 ms
	466	# 26 chars 36 lines
	467	# Active Time 10.836 us 11.183 ms
	468	# 128 chars 768 lines
	469	# Blank Time 3.725 us 0.582 ms
	470	# 44 chars 40 lines
	471	# Polarity positive positive
	472	#
	473	mode "1024x768-85"
	474	# D: 94.50 MHz, H: 68.677 kHz, V: 85.00 Hz
	475	geometry 1024 768 1024 768 32
	476	timings 10582 208 48 36 1 96 3 hsync high vsync high endmode
	477	#
	478	# 1024x768, 100 Hz, Non-Interlaced (110.0 MHz dotclock)
	479	#
	480	# Horizontal Vertical
	481	# Resolution 1024 768
	482	# Scan Frequency 79.023 kHz 99.78 Hz
	483	# Sync Width 0.800 us 0.101 ms
	484	# 11 chars 8 lines
	485	# Front Porch 0.000 us 0.000 ms
	486	# 0 chars 0 lines
	487	# Back Porch 2.545 us 0.202 ms
	488	# 35 chars 16 lines
	489	# Active Time 9.309 us 9.719 ms
	490	# 128 chars 768 lines
	491	# Blank Time 3.345 us 0.304 ms
	492	# 46 chars 24 lines
	493	# Polarity negative negative
	494	#
	495	mode "1024x768-100"
	496	# D: 113.3 MHz, H: 79.023 kHz, V: 99.78 Hz
	497	geometry 1024 768 1024 768 32
	498	timings 8825 280 0 16 0 88 8 endmode mode "1152x720-60"
	499	# D: 66.750 MHz, H: 44.859 kHz, V: 60.00 Hz
	500	geometry 1152 720 1152 720 32 timings 14981 168 56 19 3 112 6 endmode
	501	#
	502	# 1152x864, 75 Hz, Non-Interlaced (110.0 MHz dotclock)
	503	#
	504	# Horizontal Vertical
	505	# Resolution 1152 864
	506	# Scan Frequency 75.137 kHz 74.99 Hz
	507	# Sync Width 1.309 us 0.106 ms
	508	# 18 chars 8 lines
	509	# Front Porch 0.245 us 0.599 ms
	510	# 3 chars 45 lines
	511	# Back Porch 1.282 us 1.132 ms
	512	# 18 chars 85 lines
	513	# Active Time 10.473 us 11.499 ms
	514	# 144 chars 864 lines
	515	# Blank Time 2.836 us 1.837 ms
	516	# 39 chars 138 lines
	517	# Polarity positive positive
	518	#
	519	mode "1152x864-75"
	520	# D: 110.0 MHz, H: 75.137 kHz, V: 74.99 Hz
	521	geometry 1152 864 1152 864 32
	522	timings 9259 144 24 85 45 144 8
	523	hsync high vsync high endmode mode "1200x720-60"
	524	# D: 70.184 MHz, H: 44.760 kHz, V: 60.00 Hz
	525	geometry 1200 720 1200 720 32
	526	timings 14253 184 28 22 1 128 3 endmode mode "1280x600-60"
	527	# D: 61.503 MHz, H: 37.320 kHz, V: 60.00 Hz
	528	geometry 1280 600 1280 600 32
	529	timings 16260 184 28 18 1 128 3 endmode mode "1280x720-50"
	530	# D: 60.466 MHz, H: 37.050 kHz, V: 50.00 Hz
	531	geometry 1280 720 1280 720 32
	532	timings 16538 176 48 17 1 128 3 endmode mode "1280x768-50"
	533	# D: 65.178 MHz, H: 39.550 kHz, V: 50.00 Hz
	534	geometry 1280 768 1280 768 32 timings 15342 184 28 19 1 128 3 endmode
	535	#
	536	# 1280x768, 60 Hz, Non-Interlaced (80.136 MHz dotclock)
	537	#
	538	# Horizontal Vertical
	539	# Resolution 1280 768
	540	# Scan Frequency 47.700 kHz 60.00 Hz
	541	# Sync Width 1.697 us 0.063 ms
	542	# 17 chars 3 lines
	543	# Front Porch 0.799 us 0.021 ms
	544	# 8 chars 1 lines
	545	# Back Porch 2.496 us 0.483 ms
	546	# 25 chars 23 lines
	547	# Active Time 15.973 us 16.101 ms
	548	# 160 chars 768 lines
	549	# Blank Time 4.992 us 0.566 ms
	550	# 50 chars 27 lines
	551	# Polarity positive positive
	552	#
	553	mode "1280x768-60"
	554	# D: 80.13 MHz, H: 47.700 kHz, V: 60.00 Hz
	555	geometry 1280 768 1280 768 32
	556	timings 12480 200 48 23 1 126 3 hsync high vsync high endmode
	557	#
	558	# 1280x800, 60 Hz, Non-Interlaced (83.375 MHz dotclock)
	559	#
	560	# Horizontal Vertical
	561	# Resolution 1280 800
	562	# Scan Frequency 49.628 kHz 60.00 Hz
	563	# Sync Width 1.631 us 60.450 us
	564	# 17 chars 3 lines
	565	# Front Porch 0.768 us 20.15 us
	566	# 8 chars 1 lines
	567	# Back Porch 2.399 us 0.483 ms
	568	# 25 chars 24 lines
	569	# Active Time 15.352 us 16.120 ms
	570	# 160 chars 800 lines
	571	# Blank Time 4.798 us 0.564 ms
	572	# 50 chars 28 lines
	573	# Polarity negative positive
	574	#
	575	mode "1280x800-60"
	576	# D: 83.500 MHz, H: 49.702 kHz, V: 60.00 Hz
	577	geometry 1280 800 1280 800 32 timings 11994 200 72 22 3 128 6 endmode
	578	#
	579	# 1280x960, 60 Hz, Non-Interlaced (108.00 MHz dotclock)
	580	#
	581	# Horizontal Vertical
	582	# Resolution 1280 960
	583	# Scan Frequency 60.000 kHz 60.00 Hz
	584	# Sync Width 1.037 us 0.050 ms
	585	# 14 chars 3 lines
	586	# Front Porch 0.889 us 0.017 ms
	587	# 12 chars 1 lines
	588	# Back Porch 2.889 us 0.600 ms
	589	# 39 chars 36 lines
	590	# Active Time 11.852 us 16.000 ms
	591	# 160 chars 960 lines
	592	# Blank Time 4.815 us 0.667 ms
	593	# 65 chars 40 lines
	594	# Polarity positive positive
	595	#
	596	mode "1280x960-60"
	597	# D: 108.00 MHz, H: 60.000 kHz, V: 60.00 Hz
	598	geometry 1280 960 1280 960 32
	599	timings 9259 312 96 36 1 112 3 hsync high vsync high endmode
	600	#
	601	# 1280x1024, 60 Hz, Non-Interlaced (108.00 MHz dotclock)
	602	#
	603	# Horizontal Vertical
	604	# Resolution 1280 1024
	605	# Scan Frequency 63.981 kHz 60.02 Hz
	606	# Sync Width 1.037 us 0.047 ms
	607	# 14 chars 3 lines
	608	# Front Porch 0.444 us 0.015 ms
	609	# 6 chars 1 lines
	610	# Back Porch 2.297 us 0.594 ms
	611	# 31 chars 38 lines
	612	# Active Time 11.852 us 16.005 ms
	613	# 160 chars 1024 lines
	614	# Blank Time 3.778 us 0.656 ms
	615	# 51 chars 42 lines
	616	# Polarity positive positive
	617	#
	618	mode "1280x1024-60"
	619	# D: 108.00 MHz, H: 63.981 kHz, V: 60.02 Hz
	620	geometry 1280 1024 1280 1024 32
	621	timings 9260 248 48 38 1 112 3 hsync high vsync high endmode
	622	#
	623	# 1280x1024, 75 Hz, Non-Interlaced (135.00 MHz dotclock)
	624	#
	625	# Horizontal Vertical
	626	# Resolution 1280 1024
	627	# Scan Frequency 79.976 kHz 75.02 Hz
	628	# Sync Width 1.067 us 0.038 ms
	629	# 18 chars 3 lines
	630	# Front Porch 0.119 us 0.012 ms
	631	# 2 chars 1 lines
	632	# Back Porch 1.837 us 0.475 ms
	633	# 31 chars 38 lines
	634	# Active Time 9.481 us 12.804 ms
	635	# 160 chars 1024 lines
	636	# Blank Time 3.022 us 0.525 ms
	637	# 51 chars 42 lines
	638	# Polarity positive positive
	639	#
	640	mode "1280x1024-75"
	641	# D: 135.00 MHz, H: 79.976 kHz, V: 75.02 Hz
	642	geometry 1280 1024 1280 1024 32
	643	timings 7408 248 16 38 1 144 3 hsync high vsync high endmode
	644	#
	645	# 1280x1024, 85 Hz, Non-Interlaced (157.50 MHz dotclock)
	646	#
	647	# Horizontal Vertical
	648	# Resolution 1280 1024
	649	# Scan Frequency 91.146 kHz 85.02 Hz
	650	# Sync Width 1.016 us 0.033 ms
	651	# 20 chars 3 lines
	652	# Front Porch 0.406 us 0.011 ms
	653	# 8 chars 1 lines
	654	# Back Porch 1.422 us 0.483 ms
	655	# 28 chars 44 lines
	656	# Active Time 8.127 us 11.235 ms
	657	# 160 chars 1024 lines
	658	# Blank Time 2.844 us 0.527 ms
	659	# 56 chars 48 lines
	660	# Polarity positive positive
	661	#
	662	mode "1280x1024-85"
	663	# D: 157.50 MHz, H: 91.146 kHz, V: 85.02 Hz
	664	geometry 1280 1024 1280 1024 32
	665	timings 6349 224 64 44 1 160 3
	666	hsync high vsync high endmode mode "1440x900-60"
	667	# D: 106.500 MHz, H: 55.935 kHz, V: 60.00 Hz
	668	geometry 1440 900 1440 900 32
	669	timings 9390 232 80 25 3 152 6
	670	hsync high vsync high endmode mode "1440x900-75"
	671	# D: 136.750 MHz, H: 70.635 kHz, V: 75.00 Hz
	672	geometry 1440 900 1440 900 32
	673	timings 7315 248 96 33 3 152 6 hsync high vsync high endmode
	674	#
	675	# 1440x1050, 60 Hz, Non-Interlaced (125.10 MHz dotclock)
	676	#
	677	# Horizontal Vertical
	678	# Resolution 1440 1050
	679	# Scan Frequency 65.220 kHz 60.00 Hz
	680	# Sync Width 1.204 us 0.046 ms
	681	# 19 chars 3 lines
	682	# Front Porch 0.760 us 0.015 ms
	683	# 12 chars 1 lines
	684	# Back Porch 1.964 us 0.495 ms
	685	# 31 chars 33 lines
	686	# Active Time 11.405 us 16.099 ms
	687	# 180 chars 1050 lines
	688	# Blank Time 3.928 us 0.567 ms
	689	# 62 chars 37 lines
	690	# Polarity positive positive
	691	#
	692	mode "1440x1050-60"
	693	# D: 125.10 MHz, H: 65.220 kHz, V: 60.00 Hz
	694	geometry 1440 1050 1440 1050 32
	695	timings 7993 248 96 33 1 152 3
	696	hsync high vsync high endmode mode "1600x900-60"
	697	# D: 118.250 MHz, H: 55.990 kHz, V: 60.00 Hz
	698	geometry 1600 900 1600 900 32
	699	timings 8415 256 88 26 3 168 5 endmode mode "1600x1024-60"
	700	# D: 136.358 MHz, H: 63.600 kHz, V: 60.00 Hz
	701	geometry 1600 1024 1600 1024 32 timings 7315 272 104 32 1 168 3 endmode
	702	#
	703	# 1600x1200, 60 Hz, Non-Interlaced (156.00 MHz dotclock)
	704	#
	705	# Horizontal Vertical
	706	# Resolution 1600 1200
	707	# Scan Frequency 76.200 kHz 60.00 Hz
	708	# Sync Width 1.026 us 0.105 ms
	709	# 20 chars 8 lines
	710	# Front Porch 0.205 us 0.131 ms
	711	# 4 chars 10 lines
	712	# Back Porch 1.636 us 0.682 ms
	713	# 32 chars 52 lines
	714	# Active Time 10.256 us 15.748 ms
	715	# 200 chars 1200 lines
	716	# Blank Time 2.872 us 0.866 ms
	717	# 56 chars 66 lines
	718	# Polarity negative negative
	719	#
	720	mode "1600x1200-60"
	721	# D: 156.00 MHz, H: 76.200 kHz, V: 60.00 Hz
	722	geometry 1600 1200 1600 1200 32 timings 6172 256 32 52 10 160 8 endmode
	723	#
	724	# 1600x1200, 75 Hz, Non-Interlaced (202.50 MHz dotclock)
	725	#
	726	# Horizontal Vertical
	727	# Resolution 1600 1200
	728	# Scan Frequency 93.750 kHz 75.00 Hz
	729	# Sync Width 0.948 us 0.032 ms
	730	# 24 chars 3 lines
	731	# Front Porch 0.316 us 0.011 ms
	732	# 8 chars 1 lines
	733	# Back Porch 1.501 us 0.491 ms
	734	# 38 chars 46 lines
	735	# Active Time 7.901 us 12.800 ms
	736	# 200 chars 1200 lines
	737	# Blank Time 2.765 us 0.533 ms
	738	# 70 chars 50 lines
	739	# Polarity positive positive
	740	#
	741	mode "1600x1200-75"
	742	# D: 202.50 MHz, H: 93.750 kHz, V: 75.00 Hz
	743	geometry 1600 1200 1600 1200 32
	744	timings 4938 304 64 46 1 192 3
	745	hsync high vsync high endmode mode "1680x1050-60"
	746	# D: 146.250 MHz, H: 65.290 kHz, V: 59.954 Hz
	747	geometry 1680 1050 1680 1050 32
	748	timings 6814 280 104 30 3 176 6
	749	hsync high vsync high endmode mode "1680x1050-75"
	750	# D: 187.000 MHz, H: 82.306 kHz, V: 74.892 Hz
	751	geometry 1680 1050 1680 1050 32
	752	timings 5348 296 120 40 3 176 6
	753	hsync high vsync high endmode mode "1792x1344-60"
	754	# D: 202.975 MHz, H: 83.460 kHz, V: 60.00 Hz
	755	geometry 1792 1344 1792 1344 32
	756	timings 4902 320 128 43 1 192 3
	757	hsync high vsync high endmode mode "1856x1392-60"
	758	# D: 218.571 MHz, H: 86.460 kHz, V: 60.00 Hz
	759	geometry 1856 1392 1856 1392 32
	760	timings 4577 336 136 45 1 200 3
	761	hsync high vsync high endmode mode "1920x1200-60"
	762	# D: 193.250 MHz, H: 74.556 kHz, V: 60.00 Hz
	763	geometry 1920 1200 1920 1200 32
	764	timings 5173 336 136 36 3 200 6
	765	hsync high vsync high endmode mode "1920x1440-60"
	766	# D: 234.000 MHz, H:90.000 kHz, V: 60.00 Hz
	767	geometry 1920 1440 1920 1440 32
	768	timings 4274 344 128 56 1 208 3
	769	hsync high vsync high endmode mode "1920x1440-75"
	770	# D: 297.000 MHz, H:112.500 kHz, V: 75.00 Hz
	771	geometry 1920 1440 1920 1440 32
	772	timings 3367 352 144 56 1 224 3
	773	hsync high vsync high endmode mode "2048x1536-60"
	774	# D: 267.250 MHz, H: 95.446 kHz, V: 60.00 Hz
	775	geometry 2048 1536 2048 1536 32
	776	timings 3742 376 152 49 3 224 4 hsync high vsync high endmode
	777	#
	778	# 1280x720, 60 Hz, Non-Interlaced (74.481 MHz dotclock)
	779	#
	780	# Horizontal Vertical
	781	# Resolution 1280 720
	782	# Scan Frequency 44.760 kHz 60.00 Hz
	783	# Sync Width 1.826 us 67.024 ms
	784	# 17 chars 3 lines
	785	# Front Porch 0.752 us 22.341 ms
	786	# 7 chars 1 lines
	787	# Back Porch 2.578 us 491.510 ms
	788	# 24 chars 22 lines
	789	# Active Time 17.186 us 16.086 ms
	790	# 160 chars 720 lines
	791	# Blank Time 5.156 us 0.581 ms
	792	# 48 chars 26 lines
	793	# Polarity negative negative
	794	#
	795	mode "1280x720-60"
	796	# D: 74.481 MHz, H: 44.760 kHz, V: 60.00 Hz
	797	geometry 1280 720 1280 720 32 timings 13426 192 64 22 1 136 3 endmode
	798	#
	799	# 1920x1080, 60 Hz, Non-Interlaced (172.798 MHz dotclock)
	800	#
	801	# Horizontal Vertical
	802	# Resolution 1920 1080
	803	# Scan Frequency 67.080 kHz 60.00 Hz
	804	# Sync Width 1.204 us 44.723 ms
	805	# 26 chars 3 lines
	806	# Front Porch 0.694 us 14.908 ms
	807	# 15 chars 1 lines
	808	# Back Porch 1.898 us 506.857 ms
	809	# 41 chars 34 lines
	810	# Active Time 11.111 us 16.100 ms
	811	# 240 chars 1080 lines
	812	# Blank Time 3.796 us 0.566 ms
	813	# 82 chars 38 lines
	814	# Polarity negative negative
	815	#
	816	mode "1920x1080-60"
	817	# D: 74.481 MHz, H: 67.080 kHz, V: 60.00 Hz
	818	geometry 1920 1080 1920 1080 32 timings 5787 328 120 34 1 208 3 endmode
	819	#
	820	# 1400x1050, 60 Hz, Non-Interlaced (122.61 MHz dotclock)
	821	#
	822	# Horizontal Vertical
	823	# Resolution 1400 1050
	824	# Scan Frequency 65.218 kHz 59.99 Hz
	825	# Sync Width 1.037 us 0.047 ms
	826	# 19 chars 3 lines
	827	# Front Porch 0.444 us 0.015 ms
	828	# 11 chars 1 lines
	829	# Back Porch 1.185 us 0.188 ms
	830	# 30 chars 33 lines
	831	# Active Time 12.963 us 16.411 ms
	832	# 175 chars 1050 lines
	833	# Blank Time 2.667 us 0.250 ms
	834	# 60 chars 37 lines
	835	# Polarity negative positive
	836	#
	837	mode "1400x1050-60"
	838	# D: 122.750 MHz, H: 65.317 kHz, V: 59.99 Hz
	839	geometry 1400 1050 1408 1050 32
	840	timings 8214 232 88 32 3 144 4 endmode mode "1400x1050-75"
	841	# D: 156.000 MHz, H: 82.278 kHz, V: 74.867 Hz
	842	geometry 1400 1050 1408 1050 32 timings 6410 248 104 42 3 144 4 endmode
	843	#
	844	# 1366x768, 60 Hz, Non-Interlaced (85.86 MHz dotclock)
	845	#
	846	# Horizontal Vertical
	847	# Resolution 1366 768
	848	# Scan Frequency 47.700 kHz 60.00 Hz
	849	# Sync Width 1.677 us 0.063 ms
	850	# 18 chars 3 lines
	851	# Front Porch 0.839 us 0.021 ms
	852	# 9 chars 1 lines
	853	# Back Porch 2.516 us 0.482 ms
	854	# 27 chars 23 lines
	855	# Active Time 15.933 us 16.101 ms
	856	# 171 chars 768 lines
	857	# Blank Time 5.031 us 0.566 ms
	858	# 54 chars 27 lines
	859	# Polarity negative positive
	860	#
	861	mode "1360x768-60"
	862	# D: 84.750 MHz, H: 47.720 kHz, V: 60.00 Hz
	863	geometry 1360 768 1360 768 32
	864	timings 11799 208 72 22 3 136 5 endmode mode "1366x768-60"
	865	# D: 85.86 MHz, H: 47.700 kHz, V: 60.00 Hz
	866	geometry 1366 768 1366 768 32
	867	timings 11647 216 72 23 1 144 3 endmode mode "1366x768-50"
	868	# D: 69,924 MHz, H: 39.550 kHz, V: 50.00 Hz
	869	geometry 1366 768 1366 768 32 timings 14301 200 56 19 1 144 3 endmode

+297

-0

debian/doc/kernel-doc/viafb.rst less more

	0	=======================================================
	1	VIA Integration Graphic Chip Console Framebuffer Driver
	2	=======================================================
	3
	4	Platform
	5	--------
	6	The console framebuffer driver is for graphics chips of
	7	VIA UniChrome Family
	8	(CLE266, PM800 / CN400 / CN300,
	9	P4M800CE / P4M800Pro / CN700 / VN800,
	10	CX700 / VX700, K8M890, P4M890,
	11	CN896 / P4M900, VX800, VX855)
	12
	13	Driver features
	14	---------------
	15	Device: CRT, LCD, DVI
	16
	17	Support viafb_mode::
	18
	19	CRT:
	20	640x480(60, 75, 85, 100, 120 Hz), 720x480(60 Hz),
	21	720x576(60 Hz), 800x600(60, 75, 85, 100, 120 Hz),
	22	848x480(60 Hz), 856x480(60 Hz), 1024x512(60 Hz),
	23	1024x768(60, 75, 85, 100 Hz), 1152x864(75 Hz),
	24	1280x768(60 Hz), 1280x960(60 Hz), 1280x1024(60, 75, 85 Hz),
	25	1440x1050(60 Hz), 1600x1200(60, 75 Hz), 1280x720(60 Hz),
	26	1920x1080(60 Hz), 1400x1050(60 Hz), 800x480(60 Hz)
	27
	28	color depth: 8 bpp, 16 bpp, 32 bpp supports.
	29
	30	Support 2D hardware accelerator.
	31
	32	Using the viafb module
	33	----------------------
	34	Start viafb with default settings::
	35
	36	#modprobe viafb
	37
	38	Start viafb with user options::
	39
	40	#modprobe viafb viafb_mode=800x600 viafb_bpp=16 viafb_refresh=60
	41	viafb_active_dev=CRT+DVI viafb_dvi_port=DVP1
	42	viafb_mode1=1024x768 viafb_bpp=16 viafb_refresh1=60
	43	viafb_SAMM_ON=1
	44
	45	viafb_mode:
	46	- 640x480 (default)
	47	- 720x480
	48	- 800x600
	49	- 1024x768
	50
	51	viafb_bpp:
	52	- 8, 16, 32 (default:32)
	53
	54	viafb_refresh:
	55	- 60, 75, 85, 100, 120 (default:60)
	56
	57	viafb_lcd_dsp_method:
	58	- 0 : expansion (default)
	59	- 1 : centering
	60
	61	viafb_lcd_mode:
	62	0 : LCD panel with LSB data format input (default)
	63	1 : LCD panel with MSB data format input
	64
	65	viafb_lcd_panel_id:
	66	- 0 : Resolution: 640x480, Channel: single, Dithering: Enable
	67	- 1 : Resolution: 800x600, Channel: single, Dithering: Enable
	68	- 2 : Resolution: 1024x768, Channel: single, Dithering: Enable (default)
	69	- 3 : Resolution: 1280x768, Channel: single, Dithering: Enable
	70	- 4 : Resolution: 1280x1024, Channel: dual, Dithering: Enable
	71	- 5 : Resolution: 1400x1050, Channel: dual, Dithering: Enable
	72	- 6 : Resolution: 1600x1200, Channel: dual, Dithering: Enable
	73
	74	- 8 : Resolution: 800x480, Channel: single, Dithering: Enable
	75	- 9 : Resolution: 1024x768, Channel: dual, Dithering: Enable
	76	- 10: Resolution: 1024x768, Channel: single, Dithering: Disable
	77	- 11: Resolution: 1024x768, Channel: dual, Dithering: Disable
	78	- 12: Resolution: 1280x768, Channel: single, Dithering: Disable
	79	- 13: Resolution: 1280x1024, Channel: dual, Dithering: Disable
	80	- 14: Resolution: 1400x1050, Channel: dual, Dithering: Disable
	81	- 15: Resolution: 1600x1200, Channel: dual, Dithering: Disable
	82	- 16: Resolution: 1366x768, Channel: single, Dithering: Disable
	83	- 17: Resolution: 1024x600, Channel: single, Dithering: Enable
	84	- 18: Resolution: 1280x768, Channel: dual, Dithering: Enable
	85	- 19: Resolution: 1280x800, Channel: single, Dithering: Enable
	86
	87	viafb_accel:
	88	- 0 : No 2D Hardware Acceleration
	89	- 1 : 2D Hardware Acceleration (default)
	90
	91	viafb_SAMM_ON:
	92	- 0 : viafb_SAMM_ON disable (default)
	93	- 1 : viafb_SAMM_ON enable
	94
	95	viafb_mode1: (secondary display device)
	96	- 640x480 (default)
	97	- 720x480
	98	- 800x600
	99	- 1024x768
	100
	101	viafb_bpp1: (secondary display device)
	102	- 8, 16, 32 (default:32)
	103
	104	viafb_refresh1: (secondary display device)
	105	- 60, 75, 85, 100, 120 (default:60)
	106
	107	viafb_active_dev:
	108	This option is used to specify active devices.(CRT, DVI, CRT+LCD...)
	109	DVI stands for DVI or HDMI, E.g., If you want to enable HDMI,
	110	set viafb_active_dev=DVI. In SAMM case, the previous of
	111	viafb_active_dev is primary device, and the following is
	112	secondary device.
	113
	114	For example:
	115
	116	To enable one device, such as DVI only, we can use::
	117
	118	modprobe viafb viafb_active_dev=DVI
	119
	120	To enable two devices, such as CRT+DVI::
	121
	122	modprobe viafb viafb_active_dev=CRT+DVI;
	123
	124	For DuoView case, we can use::
	125
	126	modprobe viafb viafb_active_dev=CRT+DVI
	127
	128	OR::
	129
	130	modprobe viafb viafb_active_dev=DVI+CRT...
	131
	132	For SAMM case:
	133
	134	If CRT is primary and DVI is secondary, we should use::
	135
	136	modprobe viafb viafb_active_dev=CRT+DVI viafb_SAMM_ON=1...
	137
	138	If DVI is primary and CRT is secondary, we should use::
	139
	140	modprobe viafb viafb_active_dev=DVI+CRT viafb_SAMM_ON=1...
	141
	142	viafb_display_hardware_layout:
	143	This option is used to specify display hardware layout for CX700 chip.
	144
	145	- 1 : LCD only
	146	- 2 : DVI only
	147	- 3 : LCD+DVI (default)
	148	- 4 : LCD1+LCD2 (internal + internal)
	149	- 16: LCD1+ExternalLCD2 (internal + external)
	150
	151	viafb_second_size:
	152	This option is used to set second device memory size(MB) in SAMM case.
	153	The minimal size is 16.
	154
	155	viafb_platform_epia_dvi:
	156	This option is used to enable DVI on EPIA - M
	157
	158	- 0 : No DVI on EPIA - M (default)
	159	- 1 : DVI on EPIA - M
	160
	161	viafb_bus_width:
	162	When using 24 - Bit Bus Width Digital Interface,
	163	this option should be set.
	164
	165	- 12: 12-Bit LVDS or 12-Bit TMDS (default)
	166	- 24: 24-Bit LVDS or 24-Bit TMDS
	167
	168	viafb_device_lcd_dualedge:
	169	When using Dual Edge Panel, this option should be set.
	170
	171	- 0 : No Dual Edge Panel (default)
	172	- 1 : Dual Edge Panel
	173
	174	viafb_lcd_port:
	175	This option is used to specify LCD output port,
	176	available values are "DVP0" "DVP1" "DFP_HIGHLOW" "DFP_HIGH" "DFP_LOW".
	177
	178	for external LCD + external DVI on CX700(External LCD is on DVP0),
	179	we should use::
	180
	181	modprobe viafb viafb_lcd_port=DVP0...
	182
	183	Notes:
	184	1. CRT may not display properly for DuoView CRT & DVI display at
	185	the "640x480" PAL mode with DVI overscan enabled.
	186	2. SAMM stands for single adapter multi monitors. It is different from
	187	multi-head since SAMM support multi monitor at driver layers, thus fbcon
	188	layer doesn't even know about it; SAMM's second screen doesn't have a
	189	device node file, thus a user mode application can't access it directly.
	190	When SAMM is enabled, viafb_mode and viafb_mode1, viafb_bpp and
	191	viafb_bpp1, viafb_refresh and viafb_refresh1 can be different.
	192	3. When console is depending on viafbinfo1, dynamically change resolution
	193	and bpp, need to call VIAFB specified ioctl interface VIAFB_SET_DEVICE
	194	instead of calling common ioctl function FBIOPUT_VSCREENINFO since
	195	viafb doesn't support multi-head well, or it will cause screen crush.
	196
	197
	198	Configure viafb with "fbset" tool
	199	---------------------------------
	200
	201	"fbset" is an inbox utility of Linux.
	202
	203	1. Inquire current viafb information, type::
	204
	205	# fbset -i
	206
	207	2. Set various resolutions and viafb_refresh rates::
	208
	209	# fbset <resolution-vertical_sync>
	210
	211	example::
	212
	213	# fbset "1024x768-75"
	214
	215	or::
	216
	217	# fbset -g 1024 768 1024 768 32
	218
	219	Check the file "/etc/fb.modes" to find display modes available.
	220
	221	3. Set the color depth::
	222
	223	# fbset -depth <value>
	224
	225	example::
	226
	227	# fbset -depth 16
	228
	229
	230	Configure viafb via /proc
	231	-------------------------
	232	The following files exist in /proc/viafb
	233
	234	supported_output_devices
	235	This read-only file contains a full ',' separated list containing all
	236	output devices that could be available on your platform. It is likely
	237	that not all of those have a connector on your hardware but it should
	238	provide a good starting point to figure out which of those names match
	239	a real connector.
	240
	241	Example::
	242
	243	# cat /proc/viafb/supported_output_devices
	244
	245	iga1/output_devices, iga2/output_devices
	246	These two files are readable and writable. iga1 and iga2 are the two
	247	independent units that produce the screen image. Those images can be
	248	forwarded to one or more output devices. Reading those files is a way
	249	to query which output devices are currently used by an iga.
	250
	251	Example::
	252
	253	# cat /proc/viafb/iga1/output_devices
	254
	255	If there are no output devices printed the output of this iga is lost.
	256	This can happen for example if only one (the other) iga is used.
	257	Writing to these files allows adjusting the output devices during
	258	runtime. One can add new devices, remove existing ones or switch
	259	between igas. Essentially you can write a ',' separated list of device
	260	names (or a single one) in the same format as the output to those
	261	files. You can add a '+' or '-' as a prefix allowing simple addition
	262	and removal of devices. So a prefix '+' adds the devices from your list
	263	to the already existing ones, '-' removes the listed devices from the
	264	existing ones and if no prefix is given it replaces all existing ones
	265	with the listed ones. If you remove devices they are expected to turn
	266	off. If you add devices that are already part of the other iga they are
	267	removed there and added to the new one.
	268
	269	Examples:
	270
	271	Add CRT as output device to iga1::
	272
	273	# echo +CRT > /proc/viafb/iga1/output_devices
	274
	275	Remove (turn off) DVP1 and LVDS1 as output devices of iga2::
	276
	277	# echo -DVP1,LVDS1 > /proc/viafb/iga2/output_devices
	278
	279	Replace all iga1 output devices by CRT::
	280
	281	# echo CRT > /proc/viafb/iga1/output_devices
	282
	283
	284	Bootup with viafb
	285	-----------------
	286
	287	Add the following line to your grub.conf::
	288
	289	append = "video=viafb:viafb_mode=1024x768,viafb_bpp=32,viafb_refresh=85"
	290
	291
	292	VIA Framebuffer modes
	293	=====================
	294
	295	.. include:: viafb.modes
	296	:literal:

-252

~~debian/doc/kernel-doc/viafb.txt~~ less more

0
1		VIA Integration Graphic Chip Console Framebuffer Driver
2
3		[Platform]
4		-----------------------
5		The console framebuffer driver is for graphics chips of
6		VIA UniChrome Family(CLE266, PM800 / CN400 / CN300,
7		P4M800CE / P4M800Pro / CN700 / VN800,
8		CX700 / VX700, K8M890, P4M890,
9		CN896 / P4M900, VX800, VX855)
10
11		[Driver features]
12		------------------------
13		Device: CRT, LCD, DVI
14
15		Support viafb_mode:
16		CRT:
17		640x480(60, 75, 85, 100, 120 Hz), 720x480(60 Hz),
18		720x576(60 Hz), 800x600(60, 75, 85, 100, 120 Hz),
19		848x480(60 Hz), 856x480(60 Hz), 1024x512(60 Hz),
20		1024x768(60, 75, 85, 100 Hz), 1152x864(75 Hz),
21		1280x768(60 Hz), 1280x960(60 Hz), 1280x1024(60, 75, 85 Hz),
22		1440x1050(60 Hz), 1600x1200(60, 75 Hz), 1280x720(60 Hz),
23		1920x1080(60 Hz), 1400x1050(60 Hz), 800x480(60 Hz)
24
25		color depth: 8 bpp, 16 bpp, 32 bpp supports.
26
27		Support 2D hardware accelerator.
28
29		[Using the viafb module]
30		-- -- --------------------
31		Start viafb with default settings:
32		#modprobe viafb
33
34		Start viafb with user options:
35		#modprobe viafb viafb_mode=800x600 viafb_bpp=16 viafb_refresh=60
36		viafb_active_dev=CRT+DVI viafb_dvi_port=DVP1
37		viafb_mode1=1024x768 viafb_bpp=16 viafb_refresh1=60
38		viafb_SAMM_ON=1
39
40		viafb_mode:
41		640x480 (default)
42		720x480
43		800x600
44		1024x768
45		......
46
47		viafb_bpp:
48		8, 16, 32 (default:32)
49
50		viafb_refresh:
51		60, 75, 85, 100, 120 (default:60)
52
53		viafb_lcd_dsp_method:
54		0 : expansion (default)
55		1 : centering
56
57		viafb_lcd_mode:
58		0 : LCD panel with LSB data format input (default)
59		1 : LCD panel with MSB data format input
60
61		viafb_lcd_panel_id:
62		0 : Resolution: 640x480, Channel: single, Dithering: Enable
63		1 : Resolution: 800x600, Channel: single, Dithering: Enable
64		2 : Resolution: 1024x768, Channel: single, Dithering: Enable (default)
65		3 : Resolution: 1280x768, Channel: single, Dithering: Enable
66		4 : Resolution: 1280x1024, Channel: dual, Dithering: Enable
67		5 : Resolution: 1400x1050, Channel: dual, Dithering: Enable
68		6 : Resolution: 1600x1200, Channel: dual, Dithering: Enable
69
70		8 : Resolution: 800x480, Channel: single, Dithering: Enable
71		9 : Resolution: 1024x768, Channel: dual, Dithering: Enable
72		10: Resolution: 1024x768, Channel: single, Dithering: Disable
73		11: Resolution: 1024x768, Channel: dual, Dithering: Disable
74		12: Resolution: 1280x768, Channel: single, Dithering: Disable
75		13: Resolution: 1280x1024, Channel: dual, Dithering: Disable
76		14: Resolution: 1400x1050, Channel: dual, Dithering: Disable
77		15: Resolution: 1600x1200, Channel: dual, Dithering: Disable
78		16: Resolution: 1366x768, Channel: single, Dithering: Disable
79		17: Resolution: 1024x600, Channel: single, Dithering: Enable
80		18: Resolution: 1280x768, Channel: dual, Dithering: Enable
81		19: Resolution: 1280x800, Channel: single, Dithering: Enable
82
83		viafb_accel:
84		0 : No 2D Hardware Acceleration
85		1 : 2D Hardware Acceleration (default)
86
87		viafb_SAMM_ON:
88		0 : viafb_SAMM_ON disable (default)
89		1 : viafb_SAMM_ON enable
90
91		viafb_mode1: (secondary display device)
92		640x480 (default)
93		720x480
94		800x600
95		1024x768
96		... ...
97
98		viafb_bpp1: (secondary display device)
99		8, 16, 32 (default:32)
100
101		viafb_refresh1: (secondary display device)
102		60, 75, 85, 100, 120 (default:60)
103
104		viafb_active_dev:
105		This option is used to specify active devices.(CRT, DVI, CRT+LCD...)
106		DVI stands for DVI or HDMI, E.g., If you want to enable HDMI,
107		set viafb_active_dev=DVI. In SAMM case, the previous of
108		viafb_active_dev is primary device, and the following is
109		secondary device.
110
111		For example:
112		To enable one device, such as DVI only, we can use:
113		modprobe viafb viafb_active_dev=DVI
114		To enable two devices, such as CRT+DVI:
115		modprobe viafb viafb_active_dev=CRT+DVI;
116
117		For DuoView case, we can use:
118		modprobe viafb viafb_active_dev=CRT+DVI
119		OR
120		modprobe viafb viafb_active_dev=DVI+CRT...
121
122		For SAMM case:
123		If CRT is primary and DVI is secondary, we should use:
124		modprobe viafb viafb_active_dev=CRT+DVI viafb_SAMM_ON=1...
125		If DVI is primary and CRT is secondary, we should use:
126		modprobe viafb viafb_active_dev=DVI+CRT viafb_SAMM_ON=1...
127
128		viafb_display_hardware_layout:
129		This option is used to specify display hardware layout for CX700 chip.
130		1 : LCD only
131		2 : DVI only
132		3 : LCD+DVI (default)
133		4 : LCD1+LCD2 (internal + internal)
134		16: LCD1+ExternalLCD2 (internal + external)
135
136		viafb_second_size:
137		This option is used to set second device memory size(MB) in SAMM case.
138		The minimal size is 16.
139
140		viafb_platform_epia_dvi:
141		This option is used to enable DVI on EPIA - M
142		0 : No DVI on EPIA - M (default)
143		1 : DVI on EPIA - M
144
145		viafb_bus_width:
146		When using 24 - Bit Bus Width Digital Interface,
147		this option should be set.
148		12: 12-Bit LVDS or 12-Bit TMDS (default)
149		24: 24-Bit LVDS or 24-Bit TMDS
150
151		viafb_device_lcd_dualedge:
152		When using Dual Edge Panel, this option should be set.
153		0 : No Dual Edge Panel (default)
154		1 : Dual Edge Panel
155
156		viafb_lcd_port:
157		This option is used to specify LCD output port,
158		available values are "DVP0" "DVP1" "DFP_HIGHLOW" "DFP_HIGH" "DFP_LOW".
159		for external LCD + external DVI on CX700(External LCD is on DVP0),
160		we should use:
161		modprobe viafb viafb_lcd_port=DVP0...
162
163		Notes:
164		1. CRT may not display properly for DuoView CRT & DVI display at
165		the "640x480" PAL mode with DVI overscan enabled.
166		2. SAMM stands for single adapter multi monitors. It is different from
167		multi-head since SAMM support multi monitor at driver layers, thus fbcon
168		layer doesn't even know about it; SAMM's second screen doesn't have a
169		device node file, thus a user mode application can't access it directly.
170		When SAMM is enabled, viafb_mode and viafb_mode1, viafb_bpp and
171		viafb_bpp1, viafb_refresh and viafb_refresh1 can be different.
172		3. When console is depending on viafbinfo1, dynamically change resolution
173		and bpp, need to call VIAFB specified ioctl interface VIAFB_SET_DEVICE
174		instead of calling common ioctl function FBIOPUT_VSCREENINFO since
175		viafb doesn't support multi-head well, or it will cause screen crush.
176
177
178		[Configure viafb with "fbset" tool]
179		-----------------------------------
180		"fbset" is an inbox utility of Linux.
181		1. Inquire current viafb information, type,
182		# fbset -i
183
184		2. Set various resolutions and viafb_refresh rates,
185		# fbset <resolution-vertical_sync>
186
187		example,
188		# fbset "1024x768-75"
189		or
190		# fbset -g 1024 768 1024 768 32
191		Check the file "/etc/fb.modes" to find display modes available.
192
193		3. Set the color depth,
194		# fbset -depth <value>
195
196		example,
197		# fbset -depth 16
198
199
200		[Configure viafb via /proc]
201		---------------------------
202		The following files exist in /proc/viafb
203
204		supported_output_devices
205
206		This read-only file contains a full ',' separated list containing all
207		output devices that could be available on your platform. It is likely
208		that not all of those have a connector on your hardware but it should
209		provide a good starting point to figure out which of those names match
210		a real connector.
211		Example:
212		# cat /proc/viafb/supported_output_devices
213
214		iga1/output_devices
215		iga2/output_devices
216
217		These two files are readable and writable. iga1 and iga2 are the two
218		independent units that produce the screen image. Those images can be
219		forwarded to one or more output devices. Reading those files is a way
220		to query which output devices are currently used by an iga.
221		Example:
222		# cat /proc/viafb/iga1/output_devices
223		If there are no output devices printed the output of this iga is lost.
224		This can happen for example if only one (the other) iga is used.
225		Writing to these files allows adjusting the output devices during
226		runtime. One can add new devices, remove existing ones or switch
227		between igas. Essentially you can write a ',' separated list of device
228		names (or a single one) in the same format as the output to those
229		files. You can add a '+' or '-' as a prefix allowing simple addition
230		and removal of devices. So a prefix '+' adds the devices from your list
231		to the already existing ones, '-' removes the listed devices from the
232		existing ones and if no prefix is given it replaces all existing ones
233		with the listed ones. If you remove devices they are expected to turn
234		off. If you add devices that are already part of the other iga they are
235		removed there and added to the new one.
236		Examples:
237		Add CRT as output device to iga1
238		# echo +CRT > /proc/viafb/iga1/output_devices
239
240		Remove (turn off) DVP1 and LVDS1 as output devices of iga2
241		# echo -DVP1,LVDS1 > /proc/viafb/iga2/output_devices
242
243		Replace all iga1 output devices by CRT
244		# echo CRT > /proc/viafb/iga1/output_devices
245
246
247		[Bootup with viafb]:
248		--------------------
249		Add the following line to your grub.conf:
250		append = "video=viafb:viafb_mode=1024x768,viafb_bpp=32,viafb_refresh=85"
251

+64

-0

debian/doc/kernel-doc/vt8623fb.rst less more

	0	===============================================================
	1	vt8623fb - fbdev driver for graphics core in VIA VT8623 chipset
	2	===============================================================
	3
	4
	5	Supported Hardware
	6	==================
	7
	8	VIA VT8623 [CLE266] chipset and its graphics core
	9	(known as CastleRock or Unichrome)
	10
	11	I tested vt8623fb on VIA EPIA ML-6000
	12
	13
	14	Supported Features
	15	==================
	16
	17	* 4 bpp pseudocolor modes (with 18bit palette, two variants)
	18	* 8 bpp pseudocolor mode (with 18bit palette)
	19	* 16 bpp truecolor mode (RGB 565)
	20	* 32 bpp truecolor mode (RGB 888)
	21	* text mode (activated by bpp = 0)
	22	* doublescan mode variant (not available in text mode)
	23	* panning in both directions
	24	* suspend/resume support
	25	* DPMS support
	26
	27	Text mode is supported even in higher resolutions, but there is limitation to
	28	lower pixclocks (maximum about 100 MHz). This limitation is not enforced by
	29	driver. Text mode supports 8bit wide fonts only (hardware limitation) and
	30	16bit tall fonts (driver limitation).
	31
	32	There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
	33	packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
	34	with interleaved planes (1 byte interleave), MSB first. Both modes support
	35	8bit wide fonts only (driver limitation).
	36
	37	Suspend/resume works on systems that initialize video card during resume and
	38	if device is active (for example used by fbcon).
	39
	40
	41	Missing Features
	42	================
	43	(alias TODO list)
	44
	45	* secondary (not initialized by BIOS) device support
	46	* MMIO support
	47	* interlaced mode variant
	48	* support for fontwidths != 8 in 4 bpp modes
	49	* support for fontheight != 16 in text mode
	50	* hardware cursor
	51	* video overlay support
	52	* vsync synchronization
	53	* acceleration support (8514-like 2D, busmaster transfers)
	54
	55
	56	Known bugs
	57	==========
	58
	59	* cursor disable in text mode doesn't work
	60
	61
	62	--
	63	Ondrej Zajicek <santiago@crfreenet.org>

-64

~~debian/doc/kernel-doc/vt8623fb.txt~~ less more

0
1		vt8623fb - fbdev driver for graphics core in VIA VT8623 chipset
2		===============================================================
3
4
5		Supported Hardware
6		==================
7
8		VIA VT8623 [CLE266] chipset and its graphics core
9		(known as CastleRock or Unichrome)
10
11		I tested vt8623fb on VIA EPIA ML-6000
12
13
14		Supported Features
15		==================
16
17		* 4 bpp pseudocolor modes (with 18bit palette, two variants)
18		* 8 bpp pseudocolor mode (with 18bit palette)
19		* 16 bpp truecolor mode (RGB 565)
20		* 32 bpp truecolor mode (RGB 888)
21		* text mode (activated by bpp = 0)
22		* doublescan mode variant (not available in text mode)
23		* panning in both directions
24		* suspend/resume support
25		* DPMS support
26
27		Text mode is supported even in higher resolutions, but there is limitation to
28		lower pixclocks (maximum about 100 MHz). This limitation is not enforced by
29		driver. Text mode supports 8bit wide fonts only (hardware limitation) and
30		16bit tall fonts (driver limitation).
31
32		There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
33		packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
34		with interleaved planes (1 byte interleave), MSB first. Both modes support
35		8bit wide fonts only (driver limitation).
36
37		Suspend/resume works on systems that initialize video card during resume and
38		if device is active (for example used by fbcon).
39
40
41		Missing Features
42		================
43		(alias TODO list)
44
45		* secondary (not initialized by BIOS) device support
46		* MMIO support
47		* interlaced mode variant
48		* support for fontwidths != 8 in 4 bpp modes
49		* support for fontheight != 16 in text mode
50		* hardware cursor
51		* video overlay support
52		* vsync synchronization
53		* acceleration support (8514-like 2D, busmaster transfers)
54
55
56		Known bugs
57		==========
58
59		* cursor disable in text mode doesn't work
60
61
62		--
63		Ondrej Zajicek <santiago@crfreenet.org>