Documentation/fb/cyblafb/usage - LeafOS-Devices/android_kernel_samsung_gta4xl - Gitiles

 CyBlaFB is a framebuffer driver for the Cyberblade/i1 graphics core integrated
 into the VIA Apollo PLE133 (aka vt8601) south bridge. It is developed and
 tested using a VIA EPIA 5000 board.

 Cyblafb - compiled into the kernel or as a module?
 ==================================================

 You might compile cyblafb either as a module or compile it permanently into the
 kernel.

 Unless you have a real reason to do so you should not compile both vesafb and
 cyblafb permanently into the kernel. It's possible and it helps during the
 developement cycle, but it's useless and will at least block some otherwise
 usefull memory for ordinary users.

 Selecting Modes
 ===============

 	Startup Mode
 	============

 	First of all, you might use the "vga=???" boot parameter as it is
 	documented in vesafb.txt and svga.txt. Cyblafb will detect the video
 	mode selected and will use the geometry and timings found by
 	inspecting the hardware registers.

 		video=cyblafb vga=0x317

 	Alternatively you might use a combination of the mode, ref and bpp
 	parameters. If you compiled the driver into the kernel, add something
 	like this to the kernel command line:

 		video=cyblafb:1280x1024,bpp=16,ref=50 ...

 	If you compiled the driver as a module, the same mode would be
 	selected by the following command:

 		modprobe cyblafb mode=1280x1024 bpp=16 ref=50 ...

 	None of the modes possible to select as startup modes are affected by
 	the problems described at the end of the next subsection.

 	Mode changes using fbset
 	========================

 	You might use fbset to change the video mode, see "man fbset". Cyblafb
 	generally does assume that you know what you are doing. But it does
 	some checks, especially those that are needed to prevent you from
 	damaging your hardware.

 		- only 8, 16, 24 and 32 bpp video modes are accepted
 		- interlaced video modes are not accepted
 		- double scan video modes are not accepted
 		- if a flat panel is found, cyblafb does not allow you
 		  to program a resolution higher than the physical
 		  resolution of the flat panel monitor
 		- cyblafb does not allow xres to differ from xres_virtual
 		- cyblafb does not allow vclk to exceed 230 MHz. As 32 bpp
 		  and (currently) 24 bit modes use a doubled vclk internally,
 		  the dotclock limit as seen by fbset is 115 MHz for those
 		  modes and 230 MHz for 8 and 16 bpp modes.

 	Any request that violates the rules given above will be ignored and
 	fbset will return an error.

 	If you program a virtual y resolution higher than the hardware limit,
 	cyblafb will silently decrease that value to the highest possible
 	value.

 	Attempts to disable acceleration are ignored.

 	Some video modes that should work do not work as expected. If you use
 	the standard fb.modes, fbset 640x480-60 will program that mode, but
 	you will see a vertical area, about two characters wide, with only
 	much darker characters than the other characters on the screen.
 	Cyblafb does allow that mode to be set, as it does not violate the
 	official specifications. It would need a lot of code to reliably sort
 	out all invalid modes, playing around with the margin values will
 	give a valid mode quickly. And if cyblafb would detect such an invalid
 	mode, should it silently alter the requested values or should it
 	report an error? Both options have some pros and cons. As stated
 	above, none of the startup modes are affected, and if you set
 	verbosity to 1 or higher, cyblafb will print the fbset command that
 	would be needed to program that mode using fbset.


 Other Parameters
 ================


 crt		don't autodetect, assume monitor connected to
 		standard VGA connector

 fp		don't autodetect, assume flat panel display
 		connected to flat panel monitor interface

 nativex 	inform driver about native x resolution of
 		flat panel monitor connected to special
 		interface (should be autodetected)

 stretch 	stretch image to adapt low resolution modes to
 		higer resolutions of flat panel monitors
 		connected to special interface

 center		center image to adapt low resolution modes to
 		higer resolutions of flat panel monitors
 		connected to special interface

 memsize 	use if autodetected memsize is wrong ...
 		should never be necessary

 nopcirr 	disable PCI read retry
 nopciwr 	disable PCI write retry
 nopcirb 	disable PCI read bursts
 nopciwb 	disable PCI write bursts

 bpp		bpp for specified modes
 		valid values: 8 || 16 || 24 || 32

 ref		refresh rate for specified mode
 		valid values: 50 <= ref <= 85

 mode		640x480 or 800x600 or 1024x768 or 1280x1024
 		if not specified, the startup mode will be detected
 		and used, so you might also use the vga=??? parameter
 		described in vesafb.txt. If you do not specify a mode,
 		bpp and ref parameters are ignored.

 verbosity	0 is the default, increase to at least 2 for every
 		bug report!

 vesafb		allows cyblafb to be loaded after vesafb has been
 		loaded. See sections "Module unloading ...".


 Development hints
 =================

 It's much faster do compile a module and to load the new version after
 unloading the old module than to compile a new kernel and to reboot. So if you
 try to work on cyblafb, it might be a good idea to use cyblafb as a module.
 In real life, fast often means dangerous, and that's also the case here. If
 you introduce a serious bug when cyblafb is compiled into the kernel, the
 kernel will lock or oops with a high probability before the file system is
 mounted, and the danger for your data is low. If you load a broken own version
 of cyblafb on a running system, the danger for the integrity of the file
 system is much higher as you might need a hard reset afterwards. Decide
 yourself.

 Module unloading, the vfb method
 ================================

 If you want to unload/reload cyblafb using the virtual framebuffer, you need
 to enable vfb support in the kernel first. After that, load the modules as
 shown below:

 	modprobe vfb vfb_enable=1
 	modprobe fbcon
 	modprobe cyblafb
 	fbset -fb /dev/fb1 1280x1024-60 -vyres 2662
 	con2fb /dev/fb1 /dev/tty1
 	...

 If you now made some changes to cyblafb and want to reload it, you might do it
 as show below:

 	con2fb /dev/fb0 /dev/tty1
 	...
 	rmmod cyblafb
 	modprobe cyblafb
 	con2fb /dev/fb1 /dev/tty1
 	...

 Of course, you might choose another mode, and most certainly you also want to
 map some other /dev/tty* to the real framebuffer device. You might also choose
 to compile fbcon as a kernel module or place it permanently in the kernel.

 I do not know of any way to unload fbcon, and fbcon will prevent the
 framebuffer device loaded first from unloading. [If there is a way, then
 please add a description here!]

 Module unloading, the vesafb method
 ===================================

 Configure the kernel:

 	<*> Support for frame buffer devices
 	[*]   VESA VGA graphics support
 	<M>   Cyberblade/i1 support

 Add e.g. "video=vesafb:ypan vga=0x307" to the kernel parameters. The ypan
 parameter is important, choose any vga parameter you like as long as it is
 a graphics mode.

 After booting, load cyblafb without any mode and bpp parameter and assign
 cyblafb to individual ttys using con2fb, e.g.:

 	modprobe cyblafb vesafb=1
 	con2fb /dev/fb1 /dev/tty1

 Unloading cyblafb works without problems after you assign vesafb to all
 ttys again, e.g.:

 	con2fb /dev/fb0 /dev/tty1
 	rmmod cyblafb
	CyBlaFB is a framebuffer driver for the Cyberblade/i1 graphics core integrated
	into the VIA Apollo PLE133 (aka vt8601) south bridge. It is developed and
	tested using a VIA EPIA 5000 board.

	Cyblafb - compiled into the kernel or as a module?
	==================================================

	You might compile cyblafb either as a module or compile it permanently into the
	kernel.

	Unless you have a real reason to do so you should not compile both vesafb and
	cyblafb permanently into the kernel. It's possible and it helps during the
	developement cycle, but it's useless and will at least block some otherwise
	usefull memory for ordinary users.

	Selecting Modes
	===============

	Startup Mode
	============

	First of all, you might use the "vga=???" boot parameter as it is
	documented in vesafb.txt and svga.txt. Cyblafb will detect the video
	mode selected and will use the geometry and timings found by
	inspecting the hardware registers.

	video=cyblafb vga=0x317

	Alternatively you might use a combination of the mode, ref and bpp
	parameters. If you compiled the driver into the kernel, add something
	like this to the kernel command line:

	video=cyblafb:1280x1024,bpp=16,ref=50 ...

	If you compiled the driver as a module, the same mode would be
	selected by the following command:

	modprobe cyblafb mode=1280x1024 bpp=16 ref=50 ...

	None of the modes possible to select as startup modes are affected by
	the problems described at the end of the next subsection.

	Mode changes using fbset
	========================

	You might use fbset to change the video mode, see "man fbset". Cyblafb
	generally does assume that you know what you are doing. But it does
	some checks, especially those that are needed to prevent you from
	damaging your hardware.

	- only 8, 16, 24 and 32 bpp video modes are accepted
	- interlaced video modes are not accepted
	- double scan video modes are not accepted
	- if a flat panel is found, cyblafb does not allow you
	to program a resolution higher than the physical
	resolution of the flat panel monitor
	- cyblafb does not allow xres to differ from xres_virtual
	- cyblafb does not allow vclk to exceed 230 MHz. As 32 bpp
	and (currently) 24 bit modes use a doubled vclk internally,
	the dotclock limit as seen by fbset is 115 MHz for those
	modes and 230 MHz for 8 and 16 bpp modes.

	Any request that violates the rules given above will be ignored and
	fbset will return an error.

	If you program a virtual y resolution higher than the hardware limit,
	cyblafb will silently decrease that value to the highest possible
	value.

	Attempts to disable acceleration are ignored.

	Some video modes that should work do not work as expected. If you use
	the standard fb.modes, fbset 640x480-60 will program that mode, but
	you will see a vertical area, about two characters wide, with only
	much darker characters than the other characters on the screen.
	Cyblafb does allow that mode to be set, as it does not violate the
	official specifications. It would need a lot of code to reliably sort
	out all invalid modes, playing around with the margin values will
	give a valid mode quickly. And if cyblafb would detect such an invalid
	mode, should it silently alter the requested values or should it
	report an error? Both options have some pros and cons. As stated
	above, none of the startup modes are affected, and if you set
	verbosity to 1 or higher, cyblafb will print the fbset command that
	would be needed to program that mode using fbset.


	Other Parameters
	================


	crt don't autodetect, assume monitor connected to
	standard VGA connector

	fp don't autodetect, assume flat panel display
	connected to flat panel monitor interface

	nativex inform driver about native x resolution of
	flat panel monitor connected to special
	interface (should be autodetected)

	stretch stretch image to adapt low resolution modes to
	higer resolutions of flat panel monitors
	connected to special interface

	center center image to adapt low resolution modes to
	higer resolutions of flat panel monitors
	connected to special interface

	memsize use if autodetected memsize is wrong ...
	should never be necessary

	nopcirr disable PCI read retry
	nopciwr disable PCI write retry
	nopcirb disable PCI read bursts
	nopciwb disable PCI write bursts

	bpp bpp for specified modes
	valid values: 8 \|\| 16 \|\| 24 \|\| 32

	ref refresh rate for specified mode
	valid values: 50 <= ref <= 85

	mode 640x480 or 800x600 or 1024x768 or 1280x1024
	if not specified, the startup mode will be detected
	and used, so you might also use the vga=??? parameter
	described in vesafb.txt. If you do not specify a mode,
	bpp and ref parameters are ignored.

	verbosity 0 is the default, increase to at least 2 for every
	bug report!

	vesafb allows cyblafb to be loaded after vesafb has been
	loaded. See sections "Module unloading ...".


	Development hints
	=================

	It's much faster do compile a module and to load the new version after
	unloading the old module than to compile a new kernel and to reboot. So if you
	try to work on cyblafb, it might be a good idea to use cyblafb as a module.
	In real life, fast often means dangerous, and that's also the case here. If
	you introduce a serious bug when cyblafb is compiled into the kernel, the
	kernel will lock or oops with a high probability before the file system is
	mounted, and the danger for your data is low. If you load a broken own version
	of cyblafb on a running system, the danger for the integrity of the file
	system is much higher as you might need a hard reset afterwards. Decide
	yourself.

	Module unloading, the vfb method
	================================

	If you want to unload/reload cyblafb using the virtual framebuffer, you need
	to enable vfb support in the kernel first. After that, load the modules as
	shown below:

	modprobe vfb vfb_enable=1
	modprobe fbcon
	modprobe cyblafb
	fbset -fb /dev/fb1 1280x1024-60 -vyres 2662
	con2fb /dev/fb1 /dev/tty1
	...

	If you now made some changes to cyblafb and want to reload it, you might do it
	as show below:

	con2fb /dev/fb0 /dev/tty1
	...
	rmmod cyblafb
	modprobe cyblafb
	con2fb /dev/fb1 /dev/tty1
	...

	Of course, you might choose another mode, and most certainly you also want to
	map some other /dev/tty* to the real framebuffer device. You might also choose
	to compile fbcon as a kernel module or place it permanently in the kernel.

	I do not know of any way to unload fbcon, and fbcon will prevent the
	framebuffer device loaded first from unloading. [If there is a way, then
	please add a description here!]

	Module unloading, the vesafb method
	===================================

	Configure the kernel:

	<*> Support for frame buffer devices
	[*] VESA VGA graphics support
	<M> Cyberblade/i1 support

	Add e.g. "video=vesafb:ypan vga=0x307" to the kernel parameters. The ypan
	parameter is important, choose any vga parameter you like as long as it is
	a graphics mode.

	After booting, load cyblafb without any mode and bpp parameter and assign
	cyblafb to individual ttys using con2fb, e.g.:

	modprobe cyblafb vesafb=1
	con2fb /dev/fb1 /dev/tty1

	Unloading cyblafb works without problems after you assign vesafb to all
	ttys again, e.g.:

	con2fb /dev/fb0 /dev/tty1
	rmmod cyblafb