Syncing input and output devices on multihead machines

Syncing input and output devices on multihead machines

Some problems tend to bounce around inside my head for years, even if they were never really my problem to solve. This can lead to some decidedly odd results when the original problem ceases to exist due to technology moving forward or when users abandon a given platform. My idea for how to do bitwise ops on a calculator without AND and OR was one such example.

Here's another one. Back in my days of working at a school district, I got to see the inside of a great many computer labs: elementary, middle, and high schools, plus the occasional alternative school, teacher/staff training room, and so forth. I saw a lot of space pressed into use as computer labs which had never been designed for that kind of equipment.

One room I will never forget was tiny. It was an oddly-shaped room in a site which had been built in the '70s as an "open plan school". Yep, at some point they actually had this notion that walls were bad, and so they built them as wide open spaces. The walls they added later (when this turned out to be a disaster) were thin and oddly placed.

The resulting computer room had to accommodate a bunch of kids all working on their own stations. Every one had a minitower, a 15" CRT monitor, a pair of rather large speakers, and the usual keyboard/mouse. There just wasn't enough room on the tables for all of this stuff. Teachers are an enterprising bunch, however, and the computer teacher at this school made it work by stacking the minitowers on top of each other. They'd be two or three high in places, with the monitor/keyboard/mouse cables stretched as far as they could go to reach the actual seating position.

This got me thinking about what they actually did on those things and what sort of horsepower it needed. Most of the time, they ran things like Kid Pix or Number Crunchers. Other times, they went into Word and learned a little about word processing. (Side note: having the screen scroll up when you hit the bottom while typing is interesting when your user doesn't have "object permanence" down quite yet. It's a thing with really little ones. Look it up.)

Nothing they did needed the full power of those machines. Granted, they were "just" Pentium II or III machines back then, but still! It was tons of power compared to what we had just a few years before, and most of it was being used to heat the room. They should have killed a couple of birds with one stone and figured something out: multihead multiuser systems.

It should have been possible to get two or three different kids running their stuff on a single physical machine. The problem would have been figuring out how to do a 2 or 3-way video setup while keeping the keyboards and mice straight. They should be completely separate sessions, and they should have no idea they are actually using the same physical box.

Of course, actually doing that would be a nontrivial affair. It looks like people have been attempting that on Linux boxes over the years, and they may have figured out some of it. I can only wonder, though: what did they do about the keyboard + mouse + monitor sync issue? If it involved some magic incantation of plugging things into Just The Right Ports, I bet they actually created more trouble for the hapless computer teacher who gets stuck with these things. The same goes if you have to buy magic hardware, since that stuff is bound to be crazy expensive and hard to replace. This needs to work with the same commodity stuff everyone else uses: monitors, keyboards, mice and USB hubs alike.

That got me to thinking: how, exactly, could you make a system which figured these things out intelligently? You'd obviously need to have some kind of calibration process where you let it figure out the associations before you go about doing "real work" - the aforementioned Kid Pix and so forth. It would need to locate all of the displays and input devices and then go about making the connections with the help of the users.

I haven't pondered this at length, but it seems like it should be possible to have a system which allows for a resync even with mischievous entropy sources (kids) present at all of the consoles. First, you'd put up a prompt on each of the screens, asking the user to type in a certain combo. Each screen would get a different combination. As they are entered, you can be reasonably sure of the keyboard/screen mapping.

What about the mice, though? That's where it gets really crazy. You'd want something where each screen gets a separate target and the user is invited to click on it. The idea is that only one pointer will make it to any given target, so the one which manages to click on it must be associated with that screen.

Trouble is, you know that kids are going to be whipping those things around just to watch the little arrows move. They might even be clicking while doing this. You can't just accept a click and assume all is well. It's going to take some more back-and-forth before you can be sure which one is which.

Some might say that this calibration process should be done by the teacher or admin and then left alone. Here's why that's no good. Keyboards, mice, and monitors get unplugged. Why would you unplug them? Maybe they got dirty and needed to be cleaned. Maybe there was a serious knot and that was the best way to fix things up. Perhaps a piece of hardware broke and had to be replaced in a hurry.

Also, I wouldn't guarantee the ordering of devices as seen by a USB subsystem, especially when you have a classroom with 30 kids who really all just want their Reader Rabbit. If there's any way for those USB mappings to change, assume that they will. Having a quick and solid way to set things straight in the middle of class seems like the only way to maintain sanity for all involved.

Maybe I'm wrong. Fortunately, this isn't my problem any more.