This fixes a weird bug that when sometimes a user tried to switch to
console mode, the screen was frozen on graphics mode. After a hour of
debugging this, it became apparent that the problem was that we left the
y offset of the bochs graphics device in an invalid state, so it was not
zero because the WindowServer changed it, and the framebuffer console
code is not aware of horizontal and vertical offsets of the framebuffer
screen, leading to the problem that the framebuffer console updates the
first framebuffer (y offset = 0), but hardware was indicated to show the
second framebuffer (y offset = first framebuffer height).
Therefore, when doing a switch between these modes, always set the y
offset to be zero.
This exposes the child processes for a process as a directory
of symlinks to the respective /proc entries for each child.
This makes for an easier and possibly more efficient way
to find and count a process's children. Previously the only
method was to parse the entire /proc/all JSON file.
This in turn makes the built-in kernel console much more nicer to look
into, so let's remove the support for 8x8 bitmap and instead add 8x16
font bitmap.
The old methods are already can be considered deprecated, and now after
we removed framebuffer devices entirely, we can safely remove these
methods too, which simplfies the GenericGraphicsAdapter class a lot.
Instead of letting the user to determine whether framebuffer devices
will be created (which is useless because they are gone by now), let's
simplify the flow by allowing the user to choose between full, limited
or disabled functionality. The determination happens only once, so, if
the user decided to disable graphics support, the initialize method
exits immediately. If limited functionality is chosen, then a generic
DisplayConnector is initialized with the preset framebuffer resolution,
if present, and then the initialize method exits. As a default, the code
proceeds to initialize all drivers as usual.
This ioctl is more appropriate when the hardware supports flushing of
the entire framebuffer, so we use that instead of the previous default
FB_IOCTL_FLUSH_HEAD_BUFFERS ioctl.
We shouldn't expose the VirtIO GPU3DDevice constructor as public method,
so instead, let's use the usual pattern of a static construction method
that uses the constructor within the method.
Such mechanism will be used by the Intel Graphics driver, because we
lack support of changing the resolution on this driver currently, so,
when WindowServer will try to mode-set the display then it will fail,
and will use the safe mode-setting call instead to be able to show
something on screen.
The DisplayConnector class is meant to replace the FramebufferDevice
class. The advantage of this class over the FramebufferDevice class is:
1. It removes the mmap interface entirely. This interface is unsafe, as
multiple processes could try to use it, and when switching to and from
text console mode, there's no "good" way to revoke a memory mapping from
this interface, let alone when there are multiple processes that call
this interface. Therefore, in the DisplayConnector class there's no
implementation for this method at all.
2. The class uses a new real-world structure called ModeSetting, which
takes into account the fact that real hardware requires more than width,
height and pitch settings to mode-set the display resolution.
3. The class assumes all instances should supply some sort of EDID,
so it facilitates such mechanism to do so. Even if a given driver does
not know what is the actual EDID, it will ask to create default-generic
EDID blob.
3. This class shifts the responsibilies of switching between console
mode and graphical mode from a GraphicsAdapter to the DisplayConnector
class, so when doing the switch, the GraphicsManagement code actually
asks each DisplayConnector object to do the switch and doesn't rely on
the GraphicsAdapter objects at all.
Since kmalloc() now works, we can actually load the kernel symbol table!
This in turn allows us to call dump_backtrace(), and actually get a
useful backtrace in the aarch64 Kernel.
These functions are called by kmalloc, and since there is no support for
threading in the aarch64 build yet, we can simply remove the
VERIFY_NOT_REACHED().
The code in Spinlock.h has no architectural specific logic, thus can be
moved to the Arch directory. This contains no functional change.
Also add the Spinlock.cpp file for aarch64 which contains stubs for the
lock and unlock functions.
Previously the embedmap.sh script generated a warning, since there was
no section defined where the actual kernel.map could be stored. This is
necesarry for generating kernel backtraces.
This compiler builtin abstracts away the specifics of fetching the frame
pointer. This will allow the KSyms.cpp to be build for the aarch64
target. While we're here, lets also change the
PerformanceEventBuffer.cpp to not rely on x86_64 specifics.
Previously in the aarch64 Kernel, this would cause dbgln() to actually
print more characters of the next string in memory, because strings in
the Kernel are not zero terminated by default. Prevent this by using the
passed in length of the string.
