If we define a property with just a setter/getter (not both) we must:
- take the previous getter/setter if defined on the actual object
- overwrite the other to nullptr if it is from a prototype
The types for asm_signal_trampoline and asm_signal_trampoline_end
were incorrect. They both point into the text segment but they're
not really functions.
This isn't particularly useful because by the time we've entered
init() the CPU had better support x86_64 anyway. However this shows the
CPU flag in System Monitor - even in 32-bit mode.
Without this the ProcessBase class is placed into the padding for the
ProtectedProcessBase class which then causes the members of the
RefCounted class to end up without the first 4096 bytes of the Process
class:
BP 1, Kernel::Process::protect_data (this=this@entry=0xc063b000)
205 {
(gdb) p &m_ref_count
$1 = (AK::Atomic<unsigned int, (AK::MemoryOrder)5> *) 0xc063bffc
Note how the difference between 'this' and &m_ref_count is less than
4096.
QEMU appears to always relay absolute mouse coordinates relative to the
screen that the mouse is pointed to, without any way for us to know
what screen it was. So, when dealing with multiple displays force using
relative coordinates only.
Negative numeric properties are not a thing (and we even VERIFY()'d this
in the constructor). It still allows using types with a negative range
for now as we have various places using int for example (without
actually needing the negative range, but that's a different story).
u32 is the internal type of `m_number` already, so this now allows us to
leverage the full u32 range for numeric properties.
Requires a bunch of find-and-replace updates across LibJS, but
constructing a PropertyName from a nullptr Symbol* should not be
possible - let's enforce this at the compiler level instead of using
VERIFY() (and already dereference Symbol pointers at the call site).
This allows specifying how many screens we should use. This also then
only enables virtio-gpu if more than one display is requested.
This also adds an environment variable SERENITY_QEMU_DISPLAY_BACKEND
which allows overriding the default qemu display backend, as it may
not be available.
An Overlay is similar to a transparent window, but has less overhead
and does not get rendered within the window stack. Basically, the area
that an Overlay occupies forces transparency rendering for any window
underneath, which allows us to render them flicker-free.
This also adds a new API that allows displaying the screen numbers,
e.g. while the user configures the screen layout in DisplaySettings
Because other things like drag&drop or the window-size label are not
yet converted to use this new mechanism, they will be drawn over the
screen-number currently.
