*cracks knuckles* Device driver experience here, including USB HID, so sit back and prepare to get confused.
First of all, USB keyboards do not have drivers. They have a standard definition called a HID - Human Interface Device. The HID standard defines things like the scan codes. Because of the way USB and the protocol is designed, any return codes (that is: a message sent to the keyboard in response to a keystroke) are duplicated to
all devices using the same HID. That's why if you hit NumLock on one keyboard, it triggers on all of them - that's because the STATE has to propagate.
Code: Select all
struct kbdmux_state
{
char ks_inq[KBDMUX_Q_SIZE]; /* input chars queue */
unsigned int ks_inq_start;
unsigned int ks_inq_length;
struct task ks_task; /* interrupt task */
struct callout ks_timo; /* timeout handler */
#define TICKS (hz) /* rate */
int ks_flags; /* flags */
#define COMPOSE (1 << 0) /* compose char flag */
#define POLLING (1 << 1) /* polling */
#define TASK (1 << 2) /* interrupt task queued */
int ks_mode; /* K_XLATE, K_RAW, K_CODE */
int ks_state; /* state */
int ks_accents; /* accent key index (> 0) */
u_int ks_composed_char; /* composed char code */
u_char ks_prefix; /* AT scan code prefix */
SLIST_HEAD(, kbdmux_kbd) ks_kbds; /* keyboards */
KBDMUX_LOCK_DECL_GLOBAL;
};
That's from the kbdmux(4) driver in FreeBSD. It might not be entirely obvious what it does throughout, but you can see the key points. All keyboard HIDs will poll at the same rate by necessity. Flags internally identify what keyboard types (kbdmux can mux PS/2 + USB, so it's more complicated). It shares the ks_state and the accent key index. This is true for all USB keyboards because any muxing driver must also share state across all devices, and any USB HID keyboard is automatically a muxing driver.
There is not, however, an upper limit on how many USB HID devices can be attached to a single system unless imposed by the driver implementation. e.g. kbdmux(4) can theoretically handle 256 keyboards on a single system. Why you would, who knows, but it could do it. Maybe.
However, you could not assign different keys to different boards unless one of them uses a non-HID driver explicitly. The system cannot actually differentiate between the two keyboards from an input perspective; all it ultimately knows is that a keyboard sent a keystroke. It doesn't know which, because there's no provision for it. Most backlight controllers with PC control are actually implemented as secondary USB devices on the same downstream port
or an internal USB hub a la vUSB. It's a fully separate addressable device with a separate driver.
Theoretically you could do a custom HID driver that used the DEVID+VENID to distinguish a second keyboard, but you'd basically have to fully reinvent the wheel there and that's just the starting point. It wouldn't be as much difficult as very annoying and very one-off, since trying to go order of arrival will never work (it's inconsistent.)
BTW, Windows HID drivers distinguish by the upstream port - not the downstream. That's why if you install with a USB keyboard on the front panel, relocate it to a rear port and reboot, that keyboard won't work at the login screen. Which is so much more annoying than you could possibly believe. ;P
