Technically, interrupts are still often involved… just from the USB controller on the state of the polling instead of the keyboard directly on a keypress
Some keyboards implement the USB Boot Keyboard profile specified in the USB Device Class Definition for Human Interface Devices (HID) v1.11 and are explicitly configured to use the boot protocol. These are limited to 6-key rollover (6KRO) and will interrupt the CPU every time the keyboard is polled (even if there is no state change) unless the USB controller is programmed to tell the keyboard to respond with negative acknowledgments, which the USB controller discards in hardware without interrupting the CPU, when there are no state changes to report
So if i created my own keyboard from scratch on a open hardware microcontroller, could i implement this?
There’s also the case of Bluetooth dongle keyboards not working in UEFI (except that one) but USB always do. Is it this or just the UEFI not having drivers?
So if i created my own keyboard from scratch on a open hardware microcontroller, could i implement this?
The USB controller that interrupts the CPU lives on the other side of the connection, so you’d just be building hardware that responses to the polling. If you’re curious what that looks like, Ben Eater has a cool video looking at what that looks like for a USB 2 keyboard https://youtu.be/wdgULBpRoXk
There’s also the case of Bluetooth dongle keyboards not working in UEFI (except that one) but USB always do. Is it this or just the UEFI not having drivers?
I am no USB Keyboard expert, but through the power of looking it up it seems like most of these do not operate as a HID (human interface device, like mouse and keyboard) so need driver support, but some start up with a basic HID proxy which might be you have one that works. From an older thread about BIOSes rather than UEIFs
A keyboard using Bluetooth cannot access the BIOS. Logitech Bluetooth keyboards get around this by having a dongle that pairs with the keyboard in a more basic, non-Bluetooth mode until the driver kicks in and switches modes. Microsoft might be similar mode with their keyboards and dongles, but I cannot confirm that.
Technically, interrupts are still often involved… just from the USB controller on the state of the polling instead of the keyboard directly on a keypress
https://en.wikipedia.org/wiki/USB_human_interface_device_class#Keyboards
So if i created my own keyboard from scratch on a open hardware microcontroller, could i implement this?
There’s also the case of Bluetooth dongle keyboards not working in UEFI (except that one) but USB always do. Is it this or just the UEFI not having drivers?
The USB controller that interrupts the CPU lives on the other side of the connection, so you’d just be building hardware that responses to the polling. If you’re curious what that looks like, Ben Eater has a cool video looking at what that looks like for a USB 2 keyboard https://youtu.be/wdgULBpRoXk
I am no USB Keyboard expert, but through the power of looking it up it seems like most of these do not operate as a HID (human interface device, like mouse and keyboard) so need driver support, but some start up with a basic HID proxy which might be you have one that works. From an older thread about BIOSes rather than UEIFs
https://superuser.com/questions/242457/use-a-bluetooth-keyboard-to-access-edit-the-bios