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.
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.
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.
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.
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.
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.
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.
