beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-21 23:20:20 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6

Kernel/Graphics: Simplify initialization flow explanation comment

Browse source 
Most of it was not relevant anymore to what we do in the initialization
method anyway, and now it represents it quite well and "to the point".
This commit is contained in:
Liav A 2022-07-09 09:13:00 +03:00 committed by Linus Groh
parent 5824f30752
commit 4771917184
Notes: sideshowbarker 2024-07-17 09:28:15 +09:00 
Author: https://github.com/supercomputer7
Commit: https://github.com/SerenityOS/serenity/commit/4771917184
Pull-request: https://github.com/SerenityOS/serenity/pull/14520
Reviewed-by: https://github.com/linusg
1 changed files with 8 additions and 35 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

43
Kernel/Graphics/GraphicsManagement.cpp
View file

@ -174,45 +174,18 @@ UNMAP_AFTER_INIT void GraphicsManagement::initialize_preset_resolution_generic_d
UNMAP_AFTER_INIT bool GraphicsManagement::initialize()
{
/* Explanation on the flow when not requesting to force not creating any
* framebuffer devices:
* If the user wants to use a Console instead of the graphical environment,
* they doesn't need to request text mode.
* Graphical mode might not be accessible on bare-metal hardware because
* the bootloader didn't set a framebuffer and we don't have a native driver
* to set a framebuffer for it. We don't have VBE modesetting capabilities
* in the kernel yet, so what will happen is one of the following situations:
* 1. The bootloader didn't specify settings of a pre-set framebuffer. The
* kernel has a native driver for a detected display adapter, therefore
* the kernel can still set a framebuffer.
* 2. The bootloader specified settings of a pre-set framebuffer, and the
* kernel has a native driver for a detected display adapter, therefore
* the kernel can still set a framebuffer and change the settings of it.
* In that situation, the kernel will simply ignore the Multiboot pre-set
/* Explanation on the flow here:
*
* If the user chose to disable graphics support entirely, then all we can do
* is to set up a plain old VGA text console and exit this function.
* Otherwise, we either try to find a device that we natively support so
* we can initialize it, and in case we don't find any device to initialize,
* we try to initialize a simple DisplayConnector to support a pre-initialized
* framebuffer.
* 2. The bootloader specified settings of a pre-set framebuffer, and the
* kernel does not have a native driver for a detected display adapter,
* therefore the kernel will use the pre-set framebuffer. Modesetting is not
* available in this situation.
* 3. The bootloader didn't specify settings of a pre-set framebuffer, and
* the kernel does not have a native driver for a detected display adapter,
* therefore the kernel will try to initialize a VGA text mode console.
* In that situation, the kernel will assume that VGA text mode was already
* initialized, but will still try to modeset it. No switching to graphical
* environment is allowed in this case.
*
* By default, the kernel assumes that no framebuffer was created until it
* was proven that there's an existing framebuffer or we can modeset the
* screen resolution to create a framebuffer.
*
* Special cases:
* 1. If the user disabled PCI access, the kernel behaves like it's running
* Note: If the user disabled PCI access, the kernel behaves like it's running
* on a pure ISA PC machine and therefore the kernel will try to initialize
* a variant that is suitable for ISA VGA handling, and not PCI adapters.
*
* If the user requests to force no initialization of framebuffer devices
* the same flow above will happen, except that no framebuffer device will
* be created, so SystemServer will not try to initialize WindowServer.
*/
auto graphics_subsystem_mode = kernel_command_line().graphics_subsystem_mode();