Some hardware controllers might reset when trying to do self-test, so
keep the configuration byte to restore it later on.
To ensure we are not missing the response from the i8042 controller,
bump the attempts count to 20 times after initiating self-test check.
Also, try to drain the i8042 controller output buffer as it might be a
early good indication on whether i8042 is present or not.
To ensure we drain all the output buffer, we attempt to read from the
buffer 50 times and not 20 times.
This is very similar to the change that was done in 32053e8, except it
turned out that the new limit of 50 iterations was not enough when
testing on bare metal - most IO operations would succeed in the first or
second iteration, but two of them took 140 and 150 iterations
respectively.
Increase the limit from 50 to 250 to account for this, and have some
additional headroom.
This caused an initialization failure of the i8042 when I tested on
bare metal. We cannot entirely get rid of this method as QEMU for
example doesn't indicate the existence of an i8042 via ACPI, but we can
get away with only doing the manual probing if ACPI is disabled or we
didn't get a 'yes' from it.
Increasing the number of maximum loops did eventually lead to a
successful return from the function, but would later fail the actual
self test.
Since we're in an IRQ each of these evaluate_block_conditions() calls
enqueues a new deferred call, so to save on some space in the deferred
call queue let's just do it once.
Apparently on VirtualBox the keyboard device refused to complete the
reset sequence. With longer delays and more attempts before giving up,
it seems like the problem is gone.
Not only does it makes the code more robust and correct as it allows
error propagation, it allows us to enforce timeouts on waiting loops so
we don't hang forever, by waiting for the i8042 controller to respond to
us.
Therefore, it makes the i8042 more resilient against faulty hardware and
bad behaving chipsets out there.
If we don't do so, we just hang forever because we assume there's i8042
controller in the system, which is not a valid assumption for modern PC
hardware.
We currently support the left super key. This poses an issue on
keyboards that only have a right super key, such as my Steelseries 6G.
The implementation mirrors the left/right shift key logic and
effectively considers the right super key identical to the left one.
This was easily done, as the Kernel and Userland don't actually share
any of the APIs exposed by it, so instead the Kernel APIs were moved to
the Kernel, and the Userland APIs stayed in LibKeyboard.
This has multiple advantages:
* The non OOM-fallible String is not longer used for storing the
character map name in the Kernel
* The kernel no longer has to link to the userland LibKeyboard code
* A lot of #ifdef KERNEL cruft can be removed from LibKeyboard
Previously, one could put '\b' in a keymap, but in non-Terminal
applications, it would just insert a literal '\b' character instead of
behaving like backspace. This patch modifes
`visible_code_point_to_key_code` to include backspace, as well as
renaming it to `code_point_to_key_code` since '\b' is not a visible
character. Additionally, `KeyboardDevice::key_state_changed` has been
rearranged to apply the user's keymap before checking for things like
caps lock.
This was a premature optimization from the early days of SerenityOS.
The eternal heap was a simple bump pointer allocator over a static
byte array. My original idea was to avoid heap fragmentation and improve
data locality, but both ideas were rooted in cargo culting, not data.
We would reserve 4 MiB at boot and only ended up using ~256 KiB, wasting
the rest.
This patch replaces all kmalloc_eternal() usage by regular kmalloc().
Before, only KeyEvent::code_point took the user's keyboard layout
into consideration, while KeyEvent::key was hardcoded QWERTY. This
affected, among other things, Vim Emulation.
Now, KeyEvent::key respects the user's keyboard layout, so will be the
same as KeyEvent::code_point for visible (alphanumeric + symbol) keys.
Co-Authored-By: Ben Wiederhake <BenWiederhake.GitHub@gmx.de>
As soon as we enable the first PS/2 port on the I8042 controller, the
output buffer may become full. We need to drain it before attempting
any new commands with the controller (such as enabling the second PS/2
port).
Fixes#10872.
We now use AK::Error and AK::ErrorOr<T> in both kernel and userspace!
This was a slightly tedious refactoring that took a long time, so it's
not unlikely that some bugs crept in.
Nevertheless, it does pass basic functionality testing, and it's just
real nice to finally see the same pattern in all contexts. :^)
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.
This reverts commit 4131b35851.
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.
Bit 3 is set here:
c5b2f55981/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.
Previously there was a mix of returning plain strings and returning
explicit string views using `operator ""sv`. This change switches them
all to standardized on `operator ""sv` as it avoids a call to strlen.
Currently, writing anything to `/dev/mouse0` or `/dev/keyboard0` causes
the Kernel to panic. The reason for this is that
`[Mouse,Keyboard]Device::write` always returns 0, which is explicitly
prohibited by `VERIFY` macro in `Process::sys$write`. The fix seems
trivial; `write` should return EINVAL instead (as is the case with, for
example, `KCOVDevice`).
This singleton simplifies many aspects that we struggled with before:
1. There's no need to make derived classes of Device expose the
constructor as public anymore. The singleton is a friend of them, so he
can call the constructor. This solves the issue with try_create_device
helper neatly, hopefully for good.
2. Getting a reference of the NullDevice is now being done from this
singleton, which means that NullDevice no longer needs to use its own
singleton, and we can apply the try_create_device helper on it too :)
3. We can now defer registration completely after the Device constructor
which means the Device constructor is merely assigning the major and
minor numbers of the Device, and the try_create_device helper ensures it
calls the after_inserting method immediately after construction. This
creates a great opportunity to make registration more OOM-safe.
This will somwhat help unify them also under the same SysFS directory in
the commit.
Also, it feels much more like this change reflects the reality that both
ACPI and the BIOS are part of the firmware on x86 computers.
Instead of doing so in the constructor, let's do immediately after the
constructor, so we can safely pass a reference of a Device, so the
SysFSDeviceComponent constructor can use that object to identify whether
it's a block device or a character device.
This allows to us to not hold a device in SysFSDeviceComponent with a
RefPtr.
Also, we also call the before_removing method in both SlavePTY::unref
and File::unref, so because Device has that method being overrided, it
can ensure the device is removed always cleanly.
These methods are no longer needed because SystemServer is able to
populate the DevFS on its own.
Device absolute_path no longer assume a path to the /dev location,
because it really should not assume any path to a Device node.
Because StorageManagement still needs to know the storage name, we
declare a virtual method only for StorageDevices to override, but this
technique should really be removed later on.
The default template argument is only used in one place, and it
looks like it was probably just an oversight. The rest of the Kernel
code all uses u8 as the type. So lets make that the default and remove
the unused template argument, as there doesn't seem to be a reason to
allow the size to be customizable.
This commit moves the KResult and KResultOr objects to Kernel/API to
signify that they may now be freely used by userspace code at points
where a syscall-related error result is to be expected. It also exposes
KResult and KResultOr to the global namespace to make it nicer to use
for userspace code.
Previous implementation sometimes didn't release the key after pressing
and holding shift due to repeating key updates when holding keys. This
meant repeating updates would set/unset `m_both_shift_keys_pressed`
repeatedly, sometimes resulting in shift still being considered pressed
even after you released it.
Simplify left and right shift key pressed logic by tracking both key
states separately and always updating modifiers based on them.
It's easy to forget the responsibility of validating and safely copying
kernel parameters in code that is far away from syscalls. ioctl's are
one such example, and bugs there are just as dangerous as at the root
syscall level.
To avoid this case, utilize the AK::Userspace<T> template in the ioctl
kernel interface so that implementors have no choice but to properly
validate and copy ioctl pointer arguments.
