Apparently some keyboards can have led control on another interface from
the one where input is received. Now led mask is global to the usb
devices instead of per keyboard instance.
If we cannot determine current scancode set because either the keyboard
does not respond or responds with bogus value, assume scancode set 1 and
mark the scancode set as uncertain. If we receive the byte 0xF0 while
having the uncertain flag set, swap to scancode set 2. 0xF0 is unused in
scancode set 1 but indicates key release in scancode set 2, so it will
be sent after every key press.
If we cannot find PS/2 devices in the acpi namespace check 8042 bit in
FADT. Also if user explicitly specified PS/2 scancode set, assume that
we do have a PS/2 controller even when other detection mechanisms fail
This makes insertion to block list O(log n) instead of O(n) when
blocking with wake time. This is more heavy and currently slower than
the previous implementation, but that is just because we don't really
have too many threads running at any given time. This will be more
scalable in the future and even allows implementing priorities if I ever
wish so
Now modifying Scheduler.h or Thread.h doesnt trigger practically a full
kernel rebuild. This required moving Mutex and RWLock of of line but
that should be fine :^)
We now use the correct PIN interrupt from the interrupt line field
instead of writing to it, this had no effect :D
PIN interrupts are now mapped as shared and level triggered, this
properly allows PIN interrupt sharing with multiple devices
There is no need to pass the current mode as an argument as ACPI has
access to that info either way.
Only route INTx objects when using ACPI, they won't be used otherwise
There was a lot of stuff wrong with this driver and it was only getting
speeds of ~2.5 MB/s. Now 4K blocks get ~17 MB/s which is not good but
definitely better. I'm pretty sure the issue is qemu's emulation as 85%
of time is spent between sending the command and it to complete.
Large blocks are now supported too, qemu with block size 1M gets around
600 MB/s read speeds.
The old SpinLockAsMutex was pretty confusing first of all. It also was
causing the issue thats been around for maybe a year now which is the
only consistently happening kernel panic. I've been pretty confused
about this and finally figured out what was causing this.
The main issue was that we were accidentally enabling interrupts when
blocking a thread that passed SpinLockAsMutex from normally interrupt
enabled context. This led to receiving IPI for thread unblock while
we were actively blocking the thread. I'm very suprized this had't
caused any more serious issues than occasional kernel panics :^)
Don't wake up threads when getting the next timer deadline.
If we are idling this can: remove thread from block list, get the
deadline for the next blocked thread, return to idle thread. This will
end up sleeping until the next wake up condition which in the worst
case would be rebalance, or indefinitely when not running SMP.
Make sure we always set the next timer deadline. I was not doing that if
the timer interrupt did not lead to a yield
Scheduler will now set a timer interrupt deadline for when it should get
interrupted next. This fixes a big issue I've had for a long time where
sleeping on an idle core would have to wait for the next periodic
interrupt to wake up. This could cause 1 ms sleeps to be close to 10 ms.
This currently only supports lapic timers and will still fallback to
periodic interrupts when running with PIC. I should add deadline support
to PIT/HPET but why would you run with APIC disabled ;)
Bananymous