Again this has not been tested as I don't have any hardware with
Selector on an usable output path. My T61 does have Selectors but they
are not used for the internal speakers. The T61 does have mixers though
so they seem to be working fine!
Apparently USB device descriptor is allowed to have class
WirelessController if and only if it is a bluetooth controller(?) :D Now
we print ENOTSUP instead of EINVAL when encountering these
I was polling the wrong bit in read/write which lead to dead locks on
machines that used embedded controllers :D
Also EC GPEs are now only initialized AFTER the ACPI post initialization
is done. This fixes some issues where _GPE body was not fully available
yet
I don't really like this but its needed with the current architecture to
allow printing while interrupts are disabled. I was hitting a dead lock
on few real machines
This removes the race condition from `start-gui` not starting
WindowServer fast enough and leading to the apps crashing as they
timeout while connecting to the server
32 bit target could not use atomic ino_t when it was 32 bit. There isn't
really any reason to have 64 bit ino_t as there aren't really
filesystems with that large numbers :D
One of my USB mice is a boot protocol device but stalls on SET_PROTOCOL
request. USB HID is supposed to be in report protocol on initialization
so an error *should* not be an issue
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 :^)
Before this I was writing audio data to kernel in ~20 ms chuncks. This
feels like way too many syscalls, so now we allow sending upto 1 second
per syscall :D
Bananymous