How does the Linux Kernel Parameter "vga =" affect the display mode?

Linux Kernel Parameters & quot; vga & quot; how to affect the display mode-Linux general technology-Linux programming and kernel information, the following is a detailed description. If the "vga =" parameter is not specified, the system does not support the framebuffer device. Why? How does one implement it in the kernel code?
Check the system startup log kern. log and find that specifying "vga =" is a few more lines than not:

Apr 25 17:14:03 nmr107 kernel: vesafb: framebuffer at 0xd0000000, mapped to 0xe0880000, using 6144 k, total 65536 k
Apr 25 17:14:03 nmr107 kernel: vesafb: mode is 1024x768x32, linelength = 4096, pages = 1
Apr 25 17:14:03 nmr107 kernel: vesafb: protected mode interface info at c000: f6d0
Apr 25 17:14:03 nmr107 kernel: vesafb: pmi: set display start = c00cf715, set palette = c00cf79a
Apr 25 17:14:03 nmr107 kernel: pmi: ports = b4c3 b503 ba03 c003 c103 c403 c503 c603 c703 c803 c903 cc03 ce03 cf03 d003 d103 d203 d303 d403 d503 da03
Apr 25 17:14:03 nmr107 kernel: vesafb: scrolling: redraw
Apr 25 17:14:03 nmr107 kernel: vesafb: Truecolor: size = 8: 8: 8: 8, shift = 24: 16: 8: 0
We can see that the vesafb mode is set here.

The source code is searched and the above information is output by printk in the/drivers/video/vesafb. c function vesafb_probe.
So which function calls vesafb_probe? Continue searching .. It is found that this is only related to vesafb_probe.
Static struct platform_driver vesafb_driver = {
. Probe = vesafb_probe,
. Driver = {
. Name = "vesafb ",
},
};
Obviously, vesafb_probe must be called through "-> probe. The search keyword "-> probe" is irrelevant if there are only a few. To search for "> probe", this time there are still many. Remove some obviously impossible functions (such as pci and usb) and find the most likely driver_probe_device function (in the/drivers/base/Dd. c file ). Based on this idea, find _ driver_attach (call driver_probe_device) and driver_attach (call _ driver_attach)
Bus_add_driver (call driver_attach), driver_register (call bus_add_driver), platform_driver_register (call driver_register), vesafb_init (call handler), and finally module_init (vesafb_init)
The function specified by module_init will call do_basic_setup (call
Do_initcils), init (call do_basic_setup ). At this point, we finally figured out the call process of vesafb_probe.

Why didn't vesafb information be output? Is it interrupted in that step? Gradually tracking:
If (screen_info.orig_video_isVGA! = VIDEO_TYPE_VLFB)
Return-ENODEV;
As far as I know, screen_info is closely related to the "vga =" parameter! View VIDEO_TYPE_VLFB Definitions
# Define VIDEO_TYPE_VLFB 0x23/* vesa vga in graphic mode */
Exactly what you want.

Further verification, the screen_info element orig_video_isVGA is located at "0x0f" from the start point. Continue searching back,
Screen_info = SCREEN_INFO;
While
# Define PARAM (boot_params)
# Define SCREEN_INFO (* (struct screen_info *) (PARAM + 0 ))
Find this section in the/arch/i386/kernel/head. s file
/*
* Copy bootup parameters out of the way.
* Note: % esi still has the pointer to the real-mode data.
* With the kexec as boot loader, parameter segment might be loaded beyond
* Kernel image and might not even be addressable by early boot page tables.
* (Kexec on panic case). Hence copy out the parameters before initializing
* Page tables.
*/
Movl $ (boot_params-_ PAGE_OFFSET), % edi
Movl $ (PARAM_SIZE/4), % ecx
Cld
Rep
Movsl
Note: copy the startup parameter to the position pointed to by boot_params. In vedio. s, there is code to process the vesa driver.
Mopar_gr:
Leaw modelist + 1024, % di
Movb $0x23, % fs :( PARAM_HAVE_VGA)
......
PARAM_HAVE_VGA is defined
# Define PARAM_HAVE_VGA 0x0f

The "vga =" parameter is processed by grub, and the processing result is placed in the vidmode in the header of the kernel file vmlinuz.
Start from linux and read this value
Movw % fs :( 0x01fa), % ax # User selected video mode
Cmpw $ ASK_VGA, % ax # Bring up the menu
Jz vid2
Call mode_set # Set the mode
Here % fs :( 0x01fa) refers to the vidmode in the kernel Image
The kernel header can be seen in bootsect. s.
. Org 497
Setup_sects:. byte SETUPSECTS
Root_flags:. word ROOT_RDONLY
Syssize:. word SYSSIZE
Swap_dev:. word SWAP_DEV
Ram_size:. word RAMDISK
Vid_mode:. word SVGA_MODE
Root_dev:. word ROOT_DEV
Boot_flag:. word 0xAA55

Conclusion: After writing so much, it is estimated that few people can understand or read it. However, I only want to record a hard process of reading the core.
It takes a lot of effort to read the kernel code. It looks at thousands of lines of code and keeps tracking the function call process. At this time,
Be skillful and patient.