C H A P T E R 9 |
Multihead Administration |
The multihead feature on Sun Ray DTUs enables users to control separate applications on multiple screens, or heads, using a single keyboard and pointer device attached to the primary DTU. Users can also display and control a single application, such as a spreadsheet, on multiple screens. System administrators create multihead groups that may be accessed by users. A multihead group, consisting of between two and 16 DTUs controlled by one keyboard and mouse, may be composed of any mix of Sun Ray DTUs, such as Sun Ray 1, Sun Ray 100, Sun Ray 150, and Sun Ray 170, for instance. Each DTU presents an X screen of the multihead X display.
Note - Regional hotdesking is not enabled for multihead groups. |
A multihead group is comprised of a set of associated Sun Ray DTUs controlled by a primary DTU to which a keyboard and pointer device, such as a mouse, are connected. This group, which can contain a maximum of 16 DTUs, is connected to a single session.
Unless XINERAMA is enabled (see XINERAMA for more details), sessions will have a separate CDE toolbar (with separate workspaces) per screen. A window cannot be moved between screens.
The primary DTU hosts the input devices, such as a keyboard and a pointer device, and the USB devices associated with the session. The remaining DTUs, called the secondaries, provide the additional displays. All peripherals are attached to the primary DTU, and the group is controlled from the primary DTU.
Multihead groups can be created easily by using a smart card to identify the terminals with the utmhconfig GUI utility.
However, if you disconnect the secondary DTUs without deleting the multihead group to which they belong, the screens are not displayed on the single primary DTU. The primary DTU is still part of the multihead group, and the mouse seems to get lost when it goes to the disconnected secondary DTU. To recover from this situation, you can either reconnect the missing DTU or delete the multihead group using the utmhconfig or utmhadm command, or you can delete the multihead group, replace the missing DTU, and create a new multihead group that incorporates the replacement DTU.
A multihead group can have its screens arranged in various configurations. For example, a user can arrange a multihead group of four screens as two rows of two screens (2x2) or as a single row of four screens (4x1). By default, when a user logs into a multihead group, the session uses the number of screens available; the layout, or geometry. of these displays is generated automatically. You can use the -R option to utxconfig to manipulate the automatic geometry, as in the following examples:
To override the automatic geometry, where geometry is expressed as columns x rows. type:
To restore the automatic geometry on the next login:
When the mouse pointer is moved past the edge between two screens, it moves from one screen to the next. The geometry of the multihead group determines which screen is displayed at that point.
Screen dimensions for the multihead group are automatically set, by default, to the largest supported by the primary DTU. The primary DTU is the one that controls the other DTUs in the group and to which all peripherals are attached.
To override the automatic sizing of screen dimensions, use the -r option to utxconfig:
To override automatic sizing, where dimensions are expressed as width x height (for example, 1280 x 1024):
To restore automatic sizing behavior on the next login:
Note - If explicit screen dimensions are chosen, the user may experience panning or black-band effects. |
To explicitly choose not to use multiple displays for a session, type:
Note - If the resolutions of the monitors differ, you may have problems with unwanted on-screen movement called panning, or large black bands around the visible screen area. |
When the multihead feature is used, a small window indicating the current session on each screen is displayed with the current screen highlighted for easy identification. This window is automatically displayed for users during session creation. For example, the display in XINERAMA indicates that the user is on the second screen of a three-screen display.
The administration tool for the multihead feature displays the current multihead groups and enables you to create new groups.
On the command-line interface, type:
This enables the multihead policy for the failover group and restarts Sun Ray Server Software with the new policy on the local server without disrupting existing sessions.
Tip - Issue the utrestart command on every server in the failover group. |
1. Bring up the Administration Tool by typing the following URL into your browser's location field:
2. Select Admin from the navigation menu on the left side of the tool.
4. Next to Multihead feature enabled, click the Yes radio button.
6. Under Admin in the lefthand menu, select Reset Services.
This sets the multihead policy for all servers and restarts Sun Ray Server Software on all servers.
1. On the command-line interface, type:
2. On the initial screen, click Create New Group.
The Create New Multiheaded Group pop-up dialog box is displayed. The number of rows and the number of columns you enter are displayed as the group geometry when the group has been created.
3. Enter the information for the group.
Enter a name for the group and the number of rows and columns.
5. Select the DTUs within the multihead group and insert a smart card in each Sun Ray DTU in turn to establish the order of the group.
The Finish button, which was previously grayed out, is now active.
7. Exit the session or disconnect by removing your card.
The XINERAMA extension to X11creates one single large screen displayed across several monitors. With XINERAMA only one toolbar is displayed, and a window can be moved smoothly from one part of the screen to the next. XINERAMA is supported in both the Solaris 8 and Solaris 9 operating environments.
A single CDE toolbar (and set of workspaces) manages the configured monitors. A window can span monitors, since they are still within the same screen. This includes the CDE toolbar itself.
Users enable or disable XINERAMA as part of their X preferences. The utxconfig command handles this on an individual token basis. The user must log off for this to take effect.
The XINERAMA feature is enabled using the following command:
The XINERAMA feature is disabled using the following command:
To enable as default for a single system or failover group, as superuser, type the following command:
If you hot desk from a multihead group to a DTU that is not part of a multihead group--that is, a DTU with a single head--all the screens created in the original multihead group can be viewed on the single screen or head by panning to each screen in turn. This is called screen flipping.
The TerminalGroup policy module extends the Authentication Manager to support multihead groups. When a DTU connects to the Authentication Manager or a new smart card is inserted, the TerminalGroup module queries its database to determine whether the DTU is part of a multihead group and, if so, whether the DTU is a primary or secondary DTU of that group. If it is not identified as part of a multihead group, the DTU is treated normally.
If the DTU is determined to be part of a multihead group and it is the multihead group's primary DTU, a normal session placement occurs. If a session does not exist on the current server, but there is a preexisting session for the DTU or smart card on another server in the failover group, the primary DTU will be redirected to that server. If there is no session on any server, the request for a session is directed to the least-loaded server and a session is created there.
If a DTU is determined to be part of a multihead group and it is a multihead group secondary DTU, the TerminalGroup module determines if the multihead- group primary DTU is locally attached to a session. If it is, it tells the Session Manager to allow the secondary DTU to also attach to that session. If the primary DTU is not attached locally, the TerminalGroup module determines if the primary DTU is attached to another server in the failover group (if any), and if it is, it redirects the secondary DTU to that server.
If the primary DTU is determined to not be attached to any server in the failover group at that moment, a "waiting for primary" icon is displayed on the DTU, and further activity is blocked on that DTU until the primary is discovered. The secondary DTU is redirected to the server to which the primary is attached.
Copyright © 2004, Sun Microsystems, Inc. All Rights Reserved.