Summary

This specification describes a graphical user interface or part of such to 'configure a multiseat workstation as detailed as possible' using the mathematical concept of graphs.

Rationale

Multiseat workstations allow us to save energy and space. But in order for multiseat configurations to be actually used, the tools should allow easy configuration and flexibility.

Flexibility is an important requirement because user requirements to multiseat configurations can vary depending on the hardware they have available and the way they wish to collaborate with other users on the same system.

The advantages of using a graph for modeling a multiseat configuration are that you can easily model N:M relations (a session can run on multiple monitors, but multiple sessions can also run on one monitor) and thus cover many use-cases.

Use Cases

2 users play a game in split screen mode that doesn't support split screen natively, but networking.

2 users work independently in their own session, but on the same screen, because no additional monitor is available.

2 users work independently on their own screens.

2 users work on the same document using their own mousepointer, while a third user works on its own and on its own screen.

A user uses both the keyboard of his notebook and a remote-keyboard to control the system on the couch (trivial case, covered these days)

Design

This section covers the basic concept, explanatory examples and specific concepts

Graph

For a user to model a desired multiseat situation a graph is used.

Mathematically that graph would be

• directed
• no cycles
• every path, that goes from a source to a sink has the same length as every other path that goes from a source to a sink.
• every edge has length 1 (together with the rule above this means, every path visits the same amount of nodes)
• it is not necessarily connected.

The source nodes of the graph are input devices (each mouse and each keyboard has its own node)

The sink nodes of the graph are output devices (each monitor (and if you extend this concept to any output device each pair of speakers and each force feedback device) has its own node)

The remaining nodes are entities that exist on the Operating System, such as: Session, Representation of Input Device (Pointer, Keyboard Focus). It also applies: each item has its own node.

Each path of the graph from a source to a sink would then consist of:

one input device -> one representation of the input device -> one session -> one output device

Depending on the capabilities of the underlying system certain and by eliminating use-cases that don't exist in the real world certain additional restrictions make sense. Some of the restrictions are relaxed later, because they don't affect the complexity of the problem.

• an input device normally cannot point to multiple representations of input devices (it makes no sense to control 2 pointers with one mouse, it may make sense to control 2 pointers sequentially without relinking the mouse over the graph interface - see Splitting rules for further discussion)
• a representation of an input device cannot point to multiple sessions

Example graph

Example graph drawn as a non-UML-conform object diagram using gaphor class diagram. Schematically this would also be the User-Interface of the "multiseat-administrator". The users are only displayed for better understanding.

multiseatadmin_scheme.png

The whole graph belongs to a single computer system.

keyboard-mouse pairs that belong together go to the same pointer in this example. This spec doesn't cover how that detail should be implemented.

In this case 4 users are using the computer.

User3 and User4 share a session. They have their own mousepointers and keyboard "pointers". They are playing a network game in their own windows together (as a substitute for the lack of native split screen support of that game) or editing a document together. They are working on a single monitor.

User1 and User2 also have their own mousepointers and keyboardpointers. User1 additionally uses the touchpad of the computer (which is a laptop for example) in order to control his pointer. They both work independently in their own session, but User1 spans his session over one and a half monitor while user2 uses the rest, which is currently all that user needs.

User Interface

The user interface could be embedded into existing applications that cover similar tasks.

The application should start with a graph representing the current situation. The user should be able to connect new devices which then appear in the graph (depending on event handling setup) it either directly connects to the existing graph in an appropriate place or spawns new graph nodes (Sessions, Pointers) or let the new node remain unconnected.

The user interface doesn't allow the user to make certain changes:

• changes that result in the user being unable to revert to the previous situation (for example all paths deleted)
• connect nodes that are incompatible (such as connect a mouse to a monitor)
• changes that violate rules mentioned above

Example User Interface

basicPrototype.png

This shows how the user interface could look like conceptually. Instead of the buttons "drag & drop" should be used and links should be selectable. Use icons for devices, add a context menu for each node to edit splitting rules or call appropriate tools to configure devices)

Session View

(Optional)

For non-administrator user a sub-graph should be displayed, where the current session, all connected nodes and free devices the session is allowed to be connected are visible. All other nodes are either grayed out or invisible.

Since such a sub-graph always only displays one session, it makes sense to have it appear as a central item of the UI.

Splitting rules

(Partially optional)

Splitting rules are required when a node points to multiple nodes or is being pointed to by multiple nodes. e.g. 2 sessions on 1 monitor or, 1 session on 2 monitors, 2 pointers requesting events from one input device.

A splitting rule would then define how the resource is split up. e.g. the monitor/the session is split horizontally/vertically. keyboard-pointer1 gets the numpad of the keyboard while keyboard-pointer2 gets the rest.

Splitting rules are defined per node.

Concurrent splitting rules

A concurrent splitting rule is a splitting rule that allows a resource to be used by multiple requesters at the same time such as the rules above.

Non concurrent splitting rules

A non concurrent splitting rule is a splitting rule where a resource is split up by sharing it sequentially. e.g. session1 and session2 share a monitor, when the user types Alt+F8 the monitor displays the second session.

Diamond case

(Optional)

In the diamond case it doesn't make sense to apply non concurrent splitting rules to an input device while applying a concurrent one to an output device and vice versa.

The diamond case exists if there are two paths that only have the source and sink node in common.

The software should detect this case and apply splitting rules accordingly.

Splitting rules tree structure

(Optional)

Example:

3 sessions could use one monitor.

2 of them share the monitor non-concurrently while the 3rd session is always displayed. OR 2 of them share the monitor concurrently while the 3rd session is displayed when the other 2 sessions pause.

This results in a tree structure of splitting rules.

(To be explained in detail)

Event handling

(Optional)

Instead of or in addition to setting up the graph manually, the graph could expand automatically by reacting on events as defined by the user.

Examples:

• Event: Session quits (User logs out), Event handling examples: Other sessions are expanded to the freed monitor space, are expanded only when session was on the same monitor.
• Event: Input device added, Event-Handling examples: Input device is attached to a certain existing pointer, new pointer created and attached to an existing session, new session is created.
• Event: Monitor removed, Event-Handling examples: Sessions attached to the monitor are moved to another monitor applying a certain splitting rule.

Implementation

This section covers how it should be implemented. (TODO)

Unresolved issues

Various backends in order to implement this user interface are probably not yet ready for certain cases of the graph structure and splitting rules. However, implementation of a prototype with certain restrictions should be possible.