| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Commit f285241c replaced the line that sets regs.fs with a line that
sets regs.gs, but not vice versa.
|
|
Instead of asserting, just return reasonable error back to userland.
|
|
The Qemu I8042 controller does not send one IRQ per event, it sends
over four since it will not stop trying to emulate the PS/2 mouse.
If the VMWare backdoor is active, a fake I8042 mouse event will be sent
that we can then use to check if there are VMWare mouse events present.
However, we were only processing one mouse event at a time, even though
multiple events could have been queued up. Luckily this does not often
lead to issues, since after the first IRQ we would still get three
additional interrupts that would then empty the queue.
This change makes sure we always empty the event queue immediately,
instead of waiting on the next interrupt to happen. Functionally this
changes nothing - it could merely improve latency by not waiting for
new interrupts to come in.
Coincidently, this brings our implementation closer to how Linux deals
with the VMMouse.
|
|
No functional changes.
|
|
This reverts commit 4131b3585164761e3841bb1c9609b302658ee2c0.
We're swallowing way too many mouse events from QEMU with this code
enabled. Something is not right, so let's revert it for now.
|
|
This is minor progress on removing the `AK::String` API from the Kernel
in the interest of improving OOM safety.
|
|
This removes some code dupe from the constructors.
By removing this duplicate constructor we can utilize the main
VirtualConsole::create factory implementation and call that from the
VirtualConsole::create_with_preset_log factory method.
|
|
These are constants, they don't need to be dynamically allocated.
Another minor step towards removing `AK::String` from the Kernel
and improving OOM safety.
|
|
Dumping perfcore would always fail with EEXIST. This regressed in #10707
because of an incorrect indentation in the for loop.
|
|
|
|
|
|
This is much simpler and more embeddable version than libGFX one.
Solely purpose is to draw initial boot logo on screen before kernel
is even booted.
|
|
It initializes framebuffer and exposes access to its properties.
|
|
The goal was to reduce common setup of messages. Changes:
* MailBox turned into singleton to follow existing patterns
* Removed device specific messages from MailBox requiring
clients to know the details instead
* Created base Message class which clients should deriver from
It really simplify the usage for more complicated message queues
like framebuffer setup - see followup commits.
|
|
Added dbgln() and warnln() debug functions to help bootstraping.
Eventually they are going to be replaced by AK/Format.h implementation.
|
|
This FIXME does not seem to apply anymore. Yes, symbolic links in all
filesystems appear to be slightly broken, but that has nothing to do
with File::absolute_path. Let's remove the wrong FIXME instead of adding
to the confusion.
|
|
Found due to smelly code in InodeFile::absolute_path.
In particular, this replaces the following misleading methods:
File::absolute_path
This method *never* returns an actual path, and if called on an
InodeFile (which is impossible), it would VERIFY_NOT_REACHED().
OpenFileDescription::try_serialize_absolute_path
OpenFileDescription::absolute_path
These methods do not guarantee to return an actual path (just like the
other method), and just like Custody::absolute_path they do not
guarantee accuracy. In particular, just renaming the method made a
TOCTOU bug obvious.
The new method signatures use KResultOr, just like
try_serialize_absolute_path() already did.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We were accidentally casting the pointer to m_ttl from an u8* to an int*
which resulted in copying of 3 extra unrelated bytes (which turned out
to be padding in this case).
|
|
|
|
This matches the current forward-click terminology.
|
|
We create a base class called GenericFramebufferDevice, which defines
all the virtual functions that must be implemented by a
FramebufferDevice. Then, we make the VirtIO FramebufferDevice and other
FramebufferDevice implementations inherit from it.
The most important consequence of rearranging the classes is that we now
have one IOCTL method, so all drivers should be committed to not
override the IOCTL method or make their own IOCTLs of FramebufferDevice.
All graphical IOCTLs are known to all FramebufferDevices, and it's up to
the specific implementation whether to support them or discard them (so
we require extensive usage of KResult and KResultOr, together with
virtual characteristic functions).
As a result, the interface is much cleaner and understandable to read.
|
|
We already use the term adapter for instances of this class, so let's
better represent this class by changing its name to what it really is.
|
|
As suggested by @ccapitalK, it makes the interface more neat and clean.
The proper order is to get ScanoutID first, then ResourceID and after it
everything else that is needed to complete the operation successfully.
|
|
A VirtIO graphics adapter is really the VirtIO GPU, so the virtualized
hardware has no distinction between both components so there's no
need to put such distinction in software.
We might need to split things in the future, but when we do so, we must
take proper care to ensure that the interface between the components
is correct and use the usual codebase patterns.
|
|
We never used that type method except in initialization in
GraphicsManagement, and we used it there to query whether the device is
VGA compatible or not.
|
|
The distinction is not justified because a VirtIO Framebuffer device
acts much more like a regular FramebufferDevice than a pure BlockDevice.
|
|
|
|
|
|
|
|
This reduces test-js runtime by over 40% on my machine.
(And once again we find another way to defer writing a better kernel
heap allocator..)
|
|
We were taking and releasing the lock repeatedly instead of holding it
across the entire remap operation.
|
|
This allows clients to check whether TimeManagement is available before
trying to ask it about time related things.
|
|
|
|
'bootmode' now only controls which set of services are started by
SystemServer, so it is more appropriate to rename it to system_mode, and
no longer validate it in the Kernel.
|
|
Bootmode used to control panic behavior and SystemServer.
This patch factors panic behavior control into a separate flag.
|
|
Bootmode used to control framebuffers, panic behavior, and SystemServer.
This patch factors framebuffer control into a separate flag.
Note that the combination 'bootmode=self-test fbdev=on' leads to
unexpected behavior, which can only be fixed in a later commit.
|
|
Some ports (like `bc` with history enabled) sensibly set the termios
character size to 8 bits.
Previously, we left the character size value (given by the bitmask
CSIZE) as zero by default (meaning 5 bits per character), and returned
ENOTIMPL whenever someone modified it. This was dumb.
|
|
Bit 3 is set here:
https://github.com/qemu/qemu/blob/c5b2f559814104f4145f8bc310f4d33c7ead8f49/hw/input/ps2.c#L736
Spurious mouse packets can be received without this bit set, for
example when double-clicking and keeping the mouse button depressed
instead of releasing it the second time (i.e. mousedown > mouseup >
mousedown). We should not process such packets.
This makes interaction with our buttons much smoother!
Fixes #5881.
|
|
Instead of detecting which flag was set in the status register, we can
use the instrument type passed to us. This works because the mouse and
keyboard use different IRQs.
|
|
This makes the code much easier to read.
|
|
The System V ABI requires that the stack is 16-byte aligned on function
call. Confusingly, however, they mean that the stack must be aligned
this way **before** the `CALL` instruction is executed. That instruction
pushes the return value onto the stack, so the callee will actually see
the stack pointer as a value `sizeof(FlatPtr)` smaller.
The signal trampoline was written with this in mind, but `setup_stack`
aligned the entire stack, *including the return address* to a 16-byte
boundary. Because of this, the trampoline subtracted too much from the
stack pointer, thus misaligning it.
This was not a problem on i686 because we didn't execute any
instructions from signal handlers that would require memory operands to
be aligned to more than 4 bytes. This is not the case, however, on
x86_64, where SSE instructions are enabled by default and they require
16-byte aligned operands. Running such instructions raised a GP fault,
immediately killing the offending program with a SIGSEGV signal.
This issue caused TestKernelAlarm to fail in LibC when ran locally, and
at one point, the zsh port was affected too.
Fixes #9291
|
|
Instead, just ensure we pick the m_access_lock and then m_scan_lock when
doing a scan/re-scan of the PCI configuration space so we know nobody
can actually access the PCI configuration space during the scan.
The m_scan_lock is now a Spinlock, to ensure we cannot yield to other
process while we do the PCI configuration space scanning.
|
|
|
