| db41cd0e | 20-Dec-2019 |
Kyle Evans <[email protected]> |
Kill off dummy kbd drivers
As far as I can tell, these are an artifact of times when linker sets
couldn't be empty, otherwise the kernel build would fail due to unresolved
symbols. hselasky fixed th
Kill off dummy kbd drivers
As far as I can tell, these are an artifact of times when linker sets
couldn't be empty, otherwise the kernel build would fail due to unresolved
symbols. hselasky fixed this in r268138, and I've audited the kbd portions
to make sure nothing would blow up due to the empty linker set and
successfully compiled+ran a kernel with no keyboard support at all.
Kill them off now since they're no longer required.
MFC after: 1 week
show more ...
|
| 5d7c109f | 01-Apr-2017 |
Oleksandr Tymoshenko <[email protected]> |
[versatilepb] Fix keyboard driver after switching to upstream DTS
FreeBSD's DTS contained only one PL050 node and driver considered it to
be PS/2 keyboard. In reality PL050 is a PS/2 port that pushe
[versatilepb] Fix keyboard driver after switching to upstream DTS
FreeBSD's DTS contained only one PL050 node and driver considered it to
be PS/2 keyboard. In reality PL050 is a PS/2 port that pushes bytes to/from
the periphers connected to it. New DTS contains two nodes and QEMU emulates
keyboard connected to port #0 and mouse connected to port #1. Since there
is no way to say what's connected to port by checking DTS we hardcode
this knowledge in the driver: it assumes keyboard on port #0 and ignores
port #1 altogether.
Also QEMU defaults emulated keyboard to scan code set 2 while driver used
to work with scan code set 1 so when initializing driver make sure keyboard
is switched to scan code set 1
show more ...
|