S??bastien Bourdeauducq wrote: > I don't see a use case for 3/6 of the USB ports (so having 4 is > already a compromise) nor for any of the USB LEDs.
For now, the idea is that you'll probably have 2-4 devices connected. But ... one may be internal. Example, "classical" setup: - external keyboard (e.g. the rubber thing), - external mouse, - external MIDI device (e.g., something with a pad), and - another external MIDI device (e.g., something with lots of non-pad controls). The industry seems to be moving to USB-MIDI in a hurry, so we should expect that most people who get new MIDI equipment for their Milkmist will connect it via USB, not via MIDI. Now, Wolfgang and I are thinking about replacing the rubber keyboard with something a little nicer. E.g., one of these little RF combo keyboards: http://www.riitek.com/product_Info.asp?id=72 This needs an RF dongle. Dongles have a few issues, e.g., - they're small and easy to lose, - they're small and easy to overlook ... and - they make a decent lever to wreck your USB port. Hence the idea of having an internal port for things like such an RF dongle. A simple scenario with an RF dongle would look like this: - internal RF dongle for keyboard and touch pad, and - external MIDI device. People who move between studio and stage may also just keep the dongle inside even though using a "classical" configuration at the studio. But even if we have have only the two scenarios outlined above we get: - external = max(4, 1) - internal = max(0, 1) There's little point in trying to devise a solution that lets you somehow have a port play an internal or external role, since this would almost certainly end up being more expensive and more fragile than just keeping them separate. Now, why two internal ports ? Two reasons: 1) That's the most common configuration industry uses. So we'd just follow the well-trodden road of economy of scale. 2) There may be a use for a second internal port in the future. E.g., someone may have separate wireless mouse and wireless keyboard. And the day Linux runs on M1 with proper USB support, pretty much everyone will want to use a WLAN dongle. If we provide that port now, it'll save us a lot of explaining ;-) Regarding the USB LEDs, I'm less sure. A potential use would be - dark = port is not in use (or maybe used by a device that only draws power but doesn't wish to talk), - lit = port is in use and we have a driver for the device, - slow blink = overcurrent, - fast blink = something is connected but it doesn't work well or we can't figure out what to do with it. Now, what speaks against this is that quite a lot of USB devices already come with their own LED(s), making it a bit less useful to have M1 repeat part of the information available there. Of course, M1 would usually have more precise information about the status. E.g., a device may just light the LED when there's power, even if it fails to enumerate. And overcurrent would simply mean darkness. With the internal USB ports, the case for having status LEDs would be even weaker, since you'd typically install/debug the USB device once and then use it without further change - and hopefully without further trouble - for a long time. - Werner _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode
