This commit un-deprecates DeprecatedString, and repurposes it as a byte
string.
As the null state has already been removed, there are no other
particularly hairy blockers in repurposing this type as a byte string
(what it _really_ is).
This commit is auto-generated:
$ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \
Meta Ports Ladybird Tests Kernel)
$ perl -pie 's/\bDeprecatedString\b/ByteString/g;
s/deprecated_string/byte_string/g' $xs
$ clang-format --style=file -i \
$(git diff --name-only | grep \.cpp\|\.h)
$ gn format $(git ls-files '*.gn' '*.gni')
The Kernel/API directory in general shouldn't include userspace code,
but structure definitions that both are shared between the Kernel and
userspace.
All users of the ioctl API obviously use LibC so LibC is the most common
and shared library for the affected programs.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
In case of possible framebuffer mapping overflow, just fallback to the
safe mode-setting of the DisplayConnector, because in that state we know
for sure that we can map a usable framebuffer (otherwise it is a bug in
the Kernel, and not WindowServer).
This value will be used later on by WindowServer to reject resolutions
that will request a mapping that will overflow the hardware framebuffer
max length.
If we don't support double buffering for a certain type of hardware,
don't try to map with size calculated with (pitch * height * 2), as it
will result in trying to map more memory than is available in the
framebuffer memory range.
This header file represents the entire interface between the kernel and
userland, and as such, no longer should be called FB.h but something
that represents the whole graphics subsystem.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
All DisplayConnectors should support the mmap interface and it should
provide better performance now, so let's just use it and drop support
for the DisplayConnector's write interface from the WindowServer side.
This became apparent when using the VirtIO graphics device, because the
HardwareScreenBackend object needs to allow flushing of the framebuffer
constantly, and due to incorrect if-else flow, even a non-error response
from the ioctl was leading to a debug spam.
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.
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 ScreenBackend is a thin wrapper around the actual screen hardware
connection. It contains all the variables specific to that hardware and
abstracts away operations that deal with controlling the hardware. The
standard ScreenBackend implementor is HardwareScreenBackend, which
contains all the existing frame buffer & ioctl handling code of Screen.
I took this opportunity to introduce ErrorOr wherever sensible.
