All users of this mechanism have been switched to anonymous files and
passing file descriptors with sendfd()/recvfd().
Shbufs got us where we are today, but it's time we say good-bye to them
and welcome a much more idiomatic replacement. :^)
Let's keep things consistent, .diff is the name we use pretty much
everywhere. Also tweak the glob in .port_includes.sh to be
'patches/*.patch' rather than just 'patches/*'.
decode_png_chunks() is not handling "critical" chunks, unlike
decode_png_size() for example. When we encounter a chunk decoding
failure, e.g. because not enough bytes were left to read, just continue
with decoding the bitmap - which will fail on its own, if we're missing
some required chunk(s).
Fixes#4984.
These are 2x the smallest 4 resolutions. When picking one of these
in 1x and then half the size in 2x, the window server adjust the
ui scale factor, but the actual framebuffer size doesn't change.
2560x1440 also happens to be 5k resolution and monitors with that
resolution do exist -- so that seems like a good upper limit :)
For now, only support 1x and 2x scale.
I tried doing something "smarter" first where the UI would try
to keep the physical resolution constant when toggling between
1x and 2x, but many of the smaller 1x resolutions map to 2x
logical resolutions that Compositor rejects (e.g. 1024x768 becomes
512x384, which is less than the minimum 640x480 that Compositor
wants) and it felt complicated and overly magical.
So this instead just gives you a 1x/2x toggle and a dropdown
with logical (!) resolutions. That is, 800x600 @ 2x gives you
a physical resolution of 1600x1200.
If we don't like this after trying it for a while, we can change
the UI then.
To support this, the GUI process and the WebContent service will now
coordinate their backing store bitmaps. Each backing store can be
referred to by a serial ID, and we don't need to keep resending it
as a file descriptor.
We should probably do something similar in WindowServer. :^)
This 'data loss' was introduced in 809a8ee693, because
I hoped we could eventually outlaw overlong paths entirely. This sparked some discussion:
https://github.com/SerenityOS/serenity/discussions/4357
Among other things, we agree that yeah, the Kernel can and should be able to return
paths of arbitrary length. This means that the 'arbitrary' maximum of PATH_MAX in
UserspaceEmulator should be considered to be unnecessary data loss, and as such, needs to
be fixed.
The realpath syscall can attempt to return arbitrarily long paths, in particular
paths that are longer than PATH_MAX. The only way to detect this case is
checking whether 'rc', the true length of the returned path including NUL byte,
exceeds our buffer length. In such a case, the buffer contains invalid data.
All Serenity code calls LibC's realpath() with a nullptr buffer, meaning that
realpath is supposed to allocate memory on its own. All Serenity code can handle
arbitrarily long paths returned by LibC's realpath, so it is safe to "do the
dance" and repeat the syscall with a new buffer.
Ports are likely to be graceful in this regard, too. If a Port calls realpath()
with a pre-allocated buffer, however, there is nothing better we can do than
return a truncated buffer.
Now that WindowServer broadcasts the system theme using an anonymous
file, we need clients to pledge "recvfd" so they can receive it.
Some programs keep the "shared_buffer" pledge since it's still used for
a handful of things.
I've reached out to all of these authors asking if they would like to
claim the bounty and no one did. Let's list them on the website anyway
since it's fun to read about them. :^)
The priority boosting mechanism has been broken for a very long time.
Let's remove it from the codebase and we can bring it back the day
someone feels like implementing it in a working way. :^)
