Multiple monitors as display devices

As near as I can tell (without having done any research in particular, which bias I readily admit), current trends in single-computer multiple-video output come in four general trends: Multiple terminals, Extended desktop, Display clones, and Custom solutions (the last being reserved for, for example, usb devices such as the Pertelian display). I think most people who have a second monitor get the same itchy feeling at least once--what else can we do with it? There's no good language to describe, or tool implementing, a properly flexible solution (IHNRTS*).

The idea has been itching in my mind for a while that the same windowing system should be able to run different display managers on different displays (where "the desktop" is an example of a display manager, as is any full-screen application, in particular ones that change the display resolution, such as full-screen games or video, or presentations). This effect can be mimicked with the extended desktop to a limited degree, but the extended desktop is limited for one very important reason: there is exactly one meaningful way of switching input focus from one monitor to the next, which is limited by the metaphor of the extended desktop which is broken when an application other than the desktop takes exclusive control of the input.

It's been technically possible to connect two or more keyboards or mice to the same computer for ages, but there has never been a good reason--unless you want to run a mainframe with multiple sessions running, the clutter is meaningless and adds to frustration and confusion more than anything else. There is little reason not to have only one full-sized keyboard--you will only be doing one thing that needs full access to it at once, unless you're a mythical prodigy typing on four keyboards with your hands and feet and mousing with your knees and elbows, or are doing independent work in more than one context, in which case it is likely that more than one computer is a viable solution.

Imagine, however, that you have a second--or third--monitor which doesn't have the capabilities of a full desktop, and is merely a display to which you send tool windows and other informative applications so that they do not clutter your workspace. When running in an extended desktop situation, it is fine to use your primary mouse between the monitors to click options and rearrange the windows a bit--however, run a full-screen game on your primary monitor and you'll see, among other things, that your primary input is now captured and you have no feasable way to interact with it without the dreaded resolution switch back to the desktop, wasting precious seconds and interrupting whatever internal context the game may have. Surely a second mouse could have a use here, but as it stands the primary display manager captures all input, and the tertiary display manager on your other monitor has no independent ability to strip the primary display of the input focus of even redundant input devices.

Thus we get to the proposed solution: a meta-display manager behind the desktop, which is reponsible for determining which display managers have control over what output devices, and which manages input devices configurably--including switching the primary input devices between contexts, and assigning a secondary input device to the nonprimary display, and changing input and output mappings when a new program gains or loses control of one or more resources.

Unfortunately, it may require new APIs as well. Imagine, for example, that you wanted your instant messaging program to have a tool window on a tertiary display while its main window remains on the desktop. Even assuming that the same window-drawing capabilties are granted to the display manager on the tertiary display, how do you programmatically determine or specify which output device you want the new tool to be displayed on? If the tool-window display manager is not part of the operating system, or otherwise not part of the basic windowing library, then any windowing operations will have to be done through its own set of libraries instead of directly through the windowing system. Although this will create increased overhead, most likely these tool windows will not be graphically taxing or real-time, so it is not likely that a slight performance hit will be problematic.

As it is currently envisioned, the only principle problem that this solves is maintaining user interactivity across multiple contexts when one context takes full control of normal user I/O, although it also offers an API which unifies control of non-primary display devices in a way that is not fundamentally different from the APIs used to manipulate primary displays. Whether more can come of this solution is a question that might best be answered in the process of its implementation.

Irrespective, it is an idea to be taken seriously, and a potential that could be fascinatingly useful.

(* I Have Not Researched This Statement)