You must be using some hubs. The results you get will depend on the
type of hub you use.
Not just that; it also is a question of scheduling. The uhci-hcd
driver isn't very clever about scheduling, and it tries to put all the
packets into the same frame. If the packets were distributed among
multiple frames then the limit would be considerably higher (eight
times higher in this case).
I'm not sure of the scheduling details in the ohci-hcd driver; they
might well be more flexible than in uhci-hcd. In which case a single
OHCI controller would be able to handle up to 32 of these keyboards,
even though it is no faster than a UHCI controller.
You should realize that Aivils _does_ have an EHCI controller. He just
isn't using it, because his hubs are old. So the easiest approach for
him would be to buy USB-2.0 hubs.
If he doesn't want to do that there are a few ways, but they mostly
boil down to getting more controllers. If he is good at kernel
programming, he could upgrade the scheduling algorithm in uhci-hcd --
but that will be a messy job and probably not worth the time spent
(which is why I've never done it).
Like I said above, it depends on the type of hub you use. If you have
hubs with multiple Transaction Translators then the bandwidth limit
will be very high. I don't know how high exactly, but probably higher
than other limits, like the maximum number of USB devices on a single
bus (127).
If you have hubs with only a single Transaction Translator then the
limit will be lower, but still pretty high. Certainly you would be
able to connect no more than four keyboards to each hub, but you could
have many hubs. The details would depend on the scheduling algorithm
in ehci-hcd, which I'm also not familiar with.
If you have only full-speed hubs (i.e., USB-1.1 hubs rather than
USB-2.0) then you won't be able to make use of the EHCI controller at
all. That's the situation Aivils is in.
Alan Stern
--
