Summarized, your original goal was a cross between "the poor man's lots-of-monitors" - which enslaves external computers to run them, rather than hosting an implausible number of on-board video cards - and a normal KVM. The combination would allow you simultaneous control of many machines via a single mouse/keyboard/etc., and simultaneously give _all_ of them a hugely extended desktop.
Some further observations:
(1) You have cut so much from your initially proposed scope that it is now merely a very inefficient KVM, with a great deal of work invested to - in effect - eliminate important pieces of its functionality while distributing the remainder amongst high-cost peripherals, placed one per machine.
(2) With your original concept, which was a useful and entirely plausible target, there are some design considerations that I don't believe you had completely analyzed for your proposed implementation. For example, "input goes to the machine currently hosting the mouse pointer" is a bit of a disaster with respect to both ergonomics and control logic. While I was thinking on this I also tripped over a few others that are not immediately coming to mind, but as the design needs to be changed anyway, they are not terribly important.
(3) As I analyze the original concept, I see the following as natural design partitions:
- In terms of hardware:
H1. The master unit, which connects to the user's I/O peripherals (keyboard, mouse, joystick(s), headset, thumb-drive / SD-card / etc. reader, disability-assistance thingumabobs, ...) and controls the entire system.
H2. The per-machine slave - "dongle" - unit, which must be as simple as possible while still supporting whatever I/O is to be included. Ideally, it would be bus-powered and/or leech off of the host machine it's attached to; this could be achieved by, for example, leeching just enough bus power to listen for a "Hey! You! Fire up your host machine!" signal whenever said CPU isn't already running.
H3. Some sort of network connecting all of the dongle units to the master unit.
- In terms of software:
S1. The master unit needs to be able to:
a: Interface to whichever I/O peripherals (see examples at point (3)H1 above) are to be supported.
b: Send instructions/data to (and ideally receive data from) the dongle units, both individually and en masse. (Ideally, the latter would accommodate multicasting [to multiple individual targets] as well as broadcasting [to all dongles].)
c: Maintain sufficient understanding of the user session's overall state to be able to send the correct commands to the correct dongles' hosts.
d: Have a well-defined conceptual structure behind the (high-level) user session and (low-level) per-host commands mentioned in point (3)S1.c above. Without that, it will be much harder to design the software in the first place, and an intolerable headache to make major changes during development.
S2. The dongle units need to be able to:
a: Emulate (any subset of) the user I/O peripherals chosen for point (3)H1 above.
b: Interpret whatever control signals from the master unit are ultimately defined within this system. Ideally, data transfers to and from the master unit would be supported; that would enable a range of functionality from keyboard LEDs and force-feedback game controllers (at the low end) to SD cards and thumb drives (at the high end).
S3. The control network needs to be:
a: As cheap and simple as possible; ideally, using only two physical wires and very simple, freely-available protocols.
b: Indifferent to the state and/or level of functionality of individual connected units - with the possible exception of the Master Unit, as the system has by definition fallen over _anyway_ if that one is not running.
(4) If you ignore the proposed two-wire cabling restriction, the foregoing analysis bears a startling resemblance to a USB device tree; which is natively supported to some extent by a lot of microcontrollers, and I suspect most of us already own a good number of old 1.1-era hubs and such for. It isn't like vintage hardware has much use for higher speeds than that anyway, is it?
(5) Point (4) is a bit of a double-edged knife. If you borrow off-the-shelf USB functionality for the interface between the master unit and the dongles, on the software side you need only concern yourself with the actual architecture, command, and protocol definitions, and on the hardware side emulating the user peripherals for each dongle-host machine needs no more work than you were already going to be doing; but USB support requires much more capable microcontrollers in the dongle units than would be the case with a simpler choice.
. Also avoids the bootstrapping problem.
