Age | Commit message (Collapse) | Author |
|
Let's be explicit about what kind of lock this is meant to be.
|
|
|
|
|
|
|
|
Nobody excepts BochsGraphicsAdapter code uses these definitions, so
let's put them back into the BochsGraphicsAdapter.cpp file.
|
|
|
|
|
|
|
|
And fix an unsafe dereference in SharedInodeVMObject::try_clone()
to make it OOM-safe.
|
|
try_*() implies that it can fail (and they all return RefPtr with
nullptr signalling failure.)
|
|
It is not legal to resize a VMObject after it has been created.
As far as I can tell, this code would never actually run since the
object was already populated with physical pages due to using
AllocationStrategy::AllocateNow.
|
|
Instead of returning char const*, we can also give you a StringView.
|
|
The spec requires a flush after setting the new buffer resource id,
which is required by QEMUs SDL backend but not the GTK backend. This
brings us in line with the spec and makes it work for the SDL backend.
|
|
|
|
These functions are only used from within `dbgln_if` calls, so in
certain build configurations, they go unused. Similarly to variables, we
now signal to the compiler that we understand that these are not always
in use.
|
|
We were creating a new memory mapping every time WindowServer performed
a buffer flip. This was very visible in whole-system profiles, as the
mapping and unmapping of MMIO registers caused quite a bit of kmalloc()
and kfree() churn.
Avoid this problem by simply keeping the MMIO registers mapped.
|
|
This solves tearing issues and improves performance when updating the
VirtIOGPU framebuffers.
|
|
Some devices may require DMA transfers to flush the updated buffer
areas prior to flipping. For those devices we track the areas that
require flushing prior to the next flip. For devices that do not
support flipping, but require flushing, we'll simply flush after
updating the front buffer.
This also adds a small optimization that skips these steps entirely for
a screen that doesn't have any updates that need to be rendered.
|
|
|
|
Let's put the PCI IDs as enums in the PCI namespace so they're free to
pollute that namespace, but it's also more easier to use them.
|
|
|
|
We use a switch-case statements to ensure we try to find the best
suitable driver for a specific graphics card. In case we don't find
such, we use the default statement to initialize the graphics card as a
generic VGA adapter, if the adapter is VGA compatible.
If we couldn't initialize the driver, we don't touch this adapter
anymore.
Also, GraphicsDevice should not be tied to a PCI::Address member, as it
can be theortically be used with other buses (e.g. ISA cards).
|
|
These small changes fix the remaining warnings that come up during
kernel compilation with Clang. These specific fixes were for benign
things: unused lambda captures and braces around scalar initializers.
|
|
|
|
We regularily need to flush many rectangles, so instead of making many
expensive ioctl() calls to the framebuffer driver, collect the
rectangles and only make one call. And if we have too many rectangles
then it may be cheaper to just update the entire region, in which case
we simply convert them all into a union and just flush that one
rectangle instead.
|
|
Also, only allocate the amount of memory we actually need for the given
resolution.
|
|
This creates /dev/fbX devices for each physical output, owned by the
parent VirtIOGPU instance. This allows mapping and setting resolutions
independently for each output.
|
|
|
|
Currently, Kernel::Graphics::FramebufferConsole is written assuming that
the underlying framebuffer memory exists in physically contiguous
memory. There are a bunch of framebuffer devices that would need to use
the components of FramebufferConsole (in particular access to the kernel
bitmap font rendering logic). To reduce code duplication, framebuffer
console has been split into two parts, the abstract
GenericFramebufferConsole class which does the rendering, and the
ContiguousFramebufferConsole class which contains all logic related to
managing the underling vm object.
Also, a new flush method has been added to the class, to support devices
that require an extra flush step to render.
|
|
This also removes a lot of CPU.h includes infavor for Sections.h
|
|
If we have a VGA-capable graphics adapter that we support, we should
prefer it over any legacy VGA because we wouldn't use it in legacy VGA
mode in this case.
This solves the problem where we would only use the legacy VGA card
when both a legacy VGA card as well as a VGA-mode capable adapter is
present.
|
|
This is needed for VirtualBox, because it doesn't support controlling
the device with MMIO.
Fixes #7558.
|
|
|
|
If we are printing strings in the critical path, handling new lines
require us to break abstraction a bit to print new lines.
Fixes #7562.
|
|
If we happen to print a string, we could use a StringView instead. For
now, let's remove them entirely.
|
|
It seems like overly-specific classes were written for no good reason.
Instead of making each adapter to have its own unique FramebufferDevice
class, let's generalize everything to keep implementation more
consistent.
|
|
|
|
|
|
When mmaping a Framebuffer from userspace, we need to check whether the
framebuffer device is actually enabled (e.g. graphical mode is being
used) or a textual VirtualConsole is active.
Considering the above state, we mmap the right VMObject to ensure we
don't have graphical artifacts if we change the resolution from
DisplaySettings, changed to textual mode and after the resolution change
was reverted, we will see the Desktop reappearing even though we are
still in textual mode.
|
|
If we tried to change the resolution before of this patch, we triggered
a kernel crash due to mmaping the framebuffer device again.
Therefore, on mmaping of the framebuffer device, we create an entire new
set of VMObjects and Regions for the new settings.
Then, when we change the resolution, the framebuffersconsole needs to be
updated with the new resolution and also to be refreshed with the new
settings. To ensure we handle both shrinking of the resolution and
growth of it, we only copy the right amount of available data from the
cells Region.
|
|
|
|
This fixes a bug that was reported on this discord server by
@ElectrodeYT - due to the confusion of passing arguments in different
orders, we messed up and triggered a page fault due to faulty sizes.
|
|
|
|
If we create a VGACompatibleAdapter object with a preset framebuffer,
Always assign the console so we can use it.
This is useful for modesetting done by a Multiboot loader, like GRUB.
|
|
|
|
As we removed the support of VBE modesetting that was done by GRUB early
on boot, we need to determine if we can modeset the resolution with our
drivers, and if not, we should enable text mode and ensure that
SystemServer knows about it too.
Also, SystemServer should first check if there's a framebuffer device
node, which is an indication that text mode was not even if it was
requested. Then, if it doesn't find it, it should check what boot_mode
argument the user specified (in case it's self-test). This way if we
try to use bochs-display device (which is not VGA compatible) and
request a text mode, it will not honor the request and will continue
with graphical mode.
Also try to print critical messages with mininum memory allocations
possible.
In LibVT, We make the implementation flexible for kernel-specific
methods that are implemented in ConsoleImpl class.
|
|
We simply modeset the resolution after determining the preferred
resolution after getting the EDID from the attached display.
|
|
This new subsystem is replacing the old code that was used to
create device nodes of framebuffer devices in /dev.
This subsystem includes for now 3 roles:
1. GraphicsManagement singleton object that is used in the boot
process to enumerate and initialize display devices.
2. GraphicsDevice(s) that are used to control the display adapter.
3. FramebufferDevice(s) that are used to control the device node in
/dev.
For now, we support the Bochs display adapter and any other
generic VGA compatible adapter that was configured by the boot
loader to a known and fixed resolution.
Two improvements in the Bochs display adapter code are that
we can support native bochs-display device (this device doesn't
expose any VGA capabilities) and also that we use the MMIO region,
to configure the device, instead of setting IO ports for such tasks.
|