6    Window System Software Notes

This chapter contains notes about issues and known problems with the windowing software and, whenever possible, provides solutions or workarounds to those problems. The following topics are discussed in this chapter:


6.1    Hardware Notes and Restrictions

The following notes apply to graphics hardware restrictions.


6.1.1    Qvision Graphics Display Error

Different versions of Qvision graphics boards demonstrate fillsolid drawing problems, leaving a line at the bottom of the screen, which is evident when running CDE blank lock screen. The line varies in color and intensity depending on the version of the Qvision board.


6.1.2    Graphic Adapter Changes Needed to Support EV6 Linear Space Addressing

Graphics adapters that support sparse space addressing must be modified to support linear (byte) space addressing to run on EV6 class systems. This support has been provided for the S3Trio graphics adapter supplied in DIGITAL UNIX. Generic VGA support is also provided.

If you develop support for a graphics adapter that uses linear space addressing, you must modify the device driver and DDX library to support linear space addressing on the EV6 class of systems.

Note that the following information pertains only to graphics adapters that support both sparse and linear space addressing.

In addition to the specific changes required in the DDX library, you must compile routines that perform I/O with the -arch ev56 switch to take advantage of the linear (byte) addressing capabilities of the system. Because this results in two versions of some routines, you must decide if you want to implement your solution as a single DDX library or as two libraries. The S3Trio and generic VGA DDX layers use the two library option.


6.1.2.1    Single and Two DDX Library Issues

The following lists a general issues and possible implementations for the single or two library approach. Note that this is not an exhaustive list.


6.1.2.2    Required Changes to Drivers

This section provides a general description of the driver and DDX library changes needed to support both linear and sparse space addressing for the same graphics adapter.

Within the X server environment, the driver is responsible for mapping memory. Before the memory is mapped, the driver must determine if the system supports sparse or linear space addressing. One method of doing this is to use the get_info kernel interface, as shown in Example 6-1.

Example 6-1: Determining the Type of Space Addressing

#define IOH_FLAGS       (HANDLE_BYTE | HANDLE_SPARSE_SPACE)
#define IOL_FLAGS       (HANDLE_LINEAR_SPACE)

 
int map_flags = 0;
 
request.next_function = NULL; request.out_flags = 0; request.in_flags = 0; request.function = BYTEWORD_IO_CAPABLE;
 
if ((get_info(&request) == NOT_SUPPORTED) || (request.rtn_status == NOT_SUPPORTED)) map_flags = IOH_FLAGS; else map_flags = IOL_FLAGS;

Note that this example defaults to sparse space.

If you have chosen the single DDX library solution, you must provide a mechanism for the driver to inform the DDX layer which routines to load or run. Typically, this would be done during the DDX initialization phase.

If you have chosen the two DDX library solution, then you can use the mechanism provided with the X server to load the appropriate library during the initialization phase. To use this mechanism, you must notify the DDX layer about which type of mapping mapping (sparse or linear) to use.

The driver must set the reserved1 field of the ws_descriptor structure to identify the mapping type.

Note that this value must be set before the X server makes the GET_WORKSTATION_INFO ioctl call. Placing this step in the attach routine will ensure this. A value of 1 instructs the X server to load the sparse space library while a value of 2 instructs it to load to load the linear space library. A value of 0 loads the current default.

Example 6-2 shows a sample attach routine to identify and set the mapping type.

Example 6-2: Informing the DDX Layer of the Mapping Type

#define SPARSE_SPACE    1
#define LINEAR_SPACE    2
#define IOH_FLAGS       (HANDLE_BYTE | HANDLE_SPARSE_SPACE)
#define IOL_FLAGS       (HANDLE_LINEAR_SPACE)
(map_flags defined above)
ws_info *wi = &ws_softc[0];

 
if (map_flags == IOL_FLAGS) wi->ws.reserved1 = LINEAR_SPACE; else if (map_flags == IOH_FLAGS) wi->ws.reserved1 = SPARSE_SPACE; else wi->ws.reserved1 = 0;

Note

You can also include this code within Example 6-1 as long as you ensure that the reserved1 field is set before the X server makes the GET_WORKSTATION_INFO ioctl call.

Once the the driver has determined the type of addressing to use it can map the memory, as shown in Example 6-3.

Example 6-3: Mapping Memory

io_handle_t handle;
caddr_t temp;
int nbytes;
(map_flags defined above)

 
handle = vp->mem_handle; temp = (caddr_t) iohandle_to_phys(handle, map_flags); temp = (caddr_t) PHYS_TO_KSEG(temp);
 
nbytes = iohandle_to_phys(handle + vp->mem_size, map_flags) - iohandle_to_phys(handle + 0 , map_flags);
 
dp->pixmap = ws_map_region(temp, NULL, nbytes, 0600, (int *)NULL);
 
if ( dp->pixmap == (caddr_t) NULL ) return(ENOMEM);
 
handle = busphys_to_iohandle(IOREGS_BASE, BUS_IO, ctlr); temp = (caddr_t) iohandle_to_phys(handle, map_flags); temp = (caddr_t) PHYS_TO_KSEG(temp);
 
nbytes = iohandle_to_phys(handle + IOREGS_SIZE, map_flags) - iohandle_to_phys(handle + 0, map_flags);
 
dp->plane_mask = ws_map_region(temp, NULL, nbytes, 0600, (int *)NULL);
 
if (dp->plane_mask == (caddr_t)NULL) return(ENOMEM);
 
handle = busphys_to_iohandle(ENHANCED_REG_BASE, BUS_MEMORY,ctlr); temp = (caddr_t) iohandle_to_phys(handle, map_flags); temp = (caddr_t) PHYS_TO_KSEG(temp);
 
nbytes = iohandle_to_phys(handle + ENHANCED_REG_SIZE, map_flags) - iohandle_to_phys(handle + 0 , map_flags);
 
dp->physaddr = ws_map_region(temp, NULL, nbytes, 0600, (int *)NULL);
 
if (dp->physaddr == (caddr_t)NULL) return(ENOMEM);
 
SET_VGA_MAPPED(vp);


6.1.2.3    Required Changes to the DDX Library

Regardless of which DDX layer solution you choose, you must modify all I/O routines to take advantage of the byte addressing capabilities with linear space addressing. In general, you must change I/O variables to bytes and compile your code with the -arch ev56 switch.

If you have chosen the single DDX library solution, you must provide a mechanism for the driver to inform the DDX layer which routines to load. Typically, this is done during the DDX initialization phase. You can choose to load the appropriate I/O routine addresses into the DDX data structures during this phase or you can set an internal flag to select the appropriate I/O routine at run time. Only those DDX routines that perform I/O needs two versions: one for sparse space, and one for linear space that is compiled with the -arch ev56 switch.

If you have chosen the two DDX library solution, you can use the mechanism provided with the X server to load the appropriate library. To use this mechanism, you must create two DDX libraries for the same graphics adapter.

The linear space version of the library must be compiled with the -arch ev56 switch. The linear space libraries must have the same name as the sparse space version but with _linear appended to the library name. The X server attempts to load the linear version if the reserved1 field is set to LINEAR_SPACE as previously described.

For the two library solution you must also add an entry for the second (linear space) library in the Xserver.conf file. The device name must be devnameLINEAR with the library name as shown in the following example.

S3Trio DDX library names:
sparse space  - lib_dec_s3.so
linear space  - lib_dec_s3_linear.so

The devname must match the name used for the sparse space library in Xserver.conf.


6.2    X Servers

The following notes apply to X servers.


6.2.1    Limited Multiscreen Display Support with CDE

CDE provides limited support for X servers with more than one screen. While a multiscreen environment is possible, a number of inconsistencies are noticeable. For example, colors in secondary screens may not be correct, icons may not display properly, and applications may not appear on the screen where they are invoked. DIGITAL is currently working with OSF to resolve issues related to multiscreen environments for future releases of CDE.


6.2.2    Do Not Modify the keymaps.dir File

The final revision of the X Keyboard Extension, XKB Version 1.0, will be different from XKB Version 0.65, shipping with this release. The format of /usr/lib/X11/xkb/keymaps.dir will change. Do not modify this file as it will not be preserved with future updates of the operating system.

To force the server to use a specific XKB keymap, add the -xkbmap option to the server options line in /usr/lib/X11/Xserver.conf. Refer to the Xdec reference page on for more information.


6.2.3    CDE Does Not Work Properly With More than Seven Graphics Heads

If you are using more than seven graphics heads with the DMCC platform, you must use the XDM window manager. CDE does not operate properly on this configuration.


6.3    X Clients

The following notes apply to X clients.


6.3.1    The dxmail and mh Applications Require New MailScanFormat File

The /usr/lib/X11/app-defaults/MailScanFormat file, used by dxmail and other mh-based mailers, has been updated to support Year 2000 dates. Use of an old MailScanFormat file will result in date display problems and possible mail filename corruption. Therefore, you must replace any local, customized copies of the MailScanFormat file with the new file.

You should also update and review all local dxmail resource and .mh_profile files to verify that no other old versions of configuration files are being referenced.


6.3.2    X Window Colormap Resources

Color rich applications, such as Netscape, exhaust a large number of colormap resources. This results in problems with other graphical applications. For example, you may notice that icons normally displayed by the CDE Application Manager are not displayed when a color rich application is currently running on the system. Graphics applications and online help volumes may also be affected. The icon editor, dticon, may not be able to open a pixmap that contains a large number of colors.

In most cases this is a visual problem, and it may not be necessary to take any corrective actions. You can use the CDE icon labels in the same way as the icon for user actions such as drag-and-drop, and single and double click.

The simplest solution is to exit the color rich application. There are several alternate actions:


6.3.3    Old X Environment

If the XDM graphical login environment is selected instead of the default CDE environment, you may need to install the OSFOLDX11425 subset to regain the expected user environment. If this subset is missing, the default X session will consist of a single xterm window and the twm window manager instead of the more familiar DIGITAL session manager.


6.4    CDE Clients

The following notes apply to CDE clients.


6.4.1    Inaccessible Dialog Buttons

When running CDE with 640 x 480 graphics resolution, the OK, Apply, Cancel, and Help buttons of some application dialogs may be inaccessible. If this happens, you can correct it by setting the DXmfitToScreenPolicy resource to as_needed in the application's defaults file or, for systemwide problems, in the /usr/dt/config/$LANG/sys.resources file.


6.4.2    Screen Savers Prevent Efficient Power Management

When the screen on a DPMS-capable monitor is switched to standby, suspend, or off mode, the X server continues to run the screen saver. In CDE, where there are a number of active screen savers, this may defeat the CPU slowdown features for power management on certain Energy Star-compliant platforms. To minimize power consumption, DIGITAL recommends that you discontinue use of active screen savers by doing any of the following steps:


6.4.3    Remote Invocation of CDE File Manager dtfile

File Manager, Application Manager, and Trash Manager are different views supported by the dtfile application. Avoid invoking dtfile from a remote system with the DISPLAY environment variable set appropriately. This restriction is necessary because of the client-server model used by the dtfile application and its close interaction with the tooltalk messaging system.

In the event of an unexpected behaviour from any of these utilities, close down all windows associated with the File Manager, Application Manager, and Trash Manager. Then kill all processes associated with dtfile. You can get the pid for each process by using the following command:

ps -aef | grep dtfile


6.4.4    The dtmail Application

The following notes apply to the dtmail application.


6.4.4.1    MAILLOCKING Environment Variable

The dtmail application does not honor the user configurable mail-locking environment variable, MAILLOCKING. If you are using NFS, you must have NFS locking enabled on both client and server systems.


6.4.4.2    Tooltalk Locking Disabled by Default

The dtmail application disables tooltalk locking by default. To enable it, select the following option from the Mail Options->Advance dialog box:

Use network aware mail file locking

Alternatively, set the following option in your $HOME/.mailrc file:

cdenotooltalklock='f'

If tooltalk locking is enabled, and the rpc.ttdbserverd daemon is not running, you will get the following message:

Mailer is unable to obtain exclusive access to this
mailbox because the system is not responding.

 
For this time only, you can choose to open this mailbox read-only, or to open it read-write without exclusive access (use only if no one else is using this mailbox).

You can either quit and start the rpc.ttdbserverd daemon, or click on read-write, which allows you to continue without tooltalk lock.

If you are running the automount daemon, the dtmail application may not be able to access your new mail inbox and you will see a dialog box showing the following message:

Unable to access an object required to complete the operation

If you see this message, copy the contents of your current mail inbox to a temporary file as a backup and perform the following steps:

  1. Check that the following line is in your .mailrc file:

    set cdenotooltalklock

  2. If the line is not in your .mailrc file, edit the file to include it.

Alternatively, you can use the following method while in dtmail:

  1. From the Mailbox pull down menu, select Mail Options

  2. From the Mail Options dialog box, select the category Advanced.

  3. From the Advanced options, click on the option named: Use network aware mail file locking. This action should remove the check mark.

  4. Close all dialog boxes and restart the dtmail application. Check the contents of your current mailbox and the backup mailbox to ensure that no mail was lost during this process.


6.4.4.3    Row and Column Display

Changing the values for rows and columns in the Mail Options->Message View does not take effect immediately when you click on OK or APPLY. Exit from dtmail and restart it again from the control panel, command line, or file manager.


6.4.4.4    Attachments Are Not Included

If you compose a mail message by selecting one of the following from the dtmail main window, attachments will not be included:

Include the attachments manually by using the drag and drop feature.


6.4.4.5    dtmail Startup

Incorrect default permissions on /dev/zero prevent dtmail from starting.

You may see the following message when starting dtmail:

No memory available for operation

If you see this message, set the permission mode on /dev/zero to 666, as follows:

chmod 666 /dev/zero


6.4.5    CDE's Static Dependency on the Network

CDE has a static dependency on the state of the network configuration. For more information, see Section 4.4.6.


6.4.6    The xnlLanguage Resource Settings May Cause Problems with CDE

CDE users should remove any xnlLanguage resource settings from their .Xdefaults files. Those settings are typically left over from one of the user's earlier DECwindows sessions, where the user selected a language from the session manager's language menu and then saved that setting.

The xnlLanguage settings should be removed because they override whatever language you select from the language menu in the CDE login window.


6.4.7    Possible Failure in the XOpenDisplay Call

When logging in to the CDE desktop, not all of the applications you want may restart. The X server process may not be able to handle all of the requests for new open connections, causing some to fail in the XOpenDisplay call. Some applications, like xterm, log startup errors in the dxconsole window, such as the following error:

xterm error: can't open display :0

To avoid this problem, add the following resource to your $HOME/.Xdefaults file:

Dtsession*contManagement:   2

This resource enables a handshake protocol between the CDE session manager and window manager during the login phase to control the appearance of new windows. While it may marginally increase the time before the login completes, it better assures that all applications will be restarted.

For a multiuser system, this resource can be added to the /usr/dt/app-defaults/C/Dtsession file to make the change for all users automatically.


6.5    Windows Programming

The following note applies to windows programming.


6.5.1    X11 Font Problem

In the Lucida-Typewriter-medium-R-normal fonts, the glyphs for multiplication and division are reversed. The multiplication symbol is where the division symbol should be, and vice versa. If the representation of these glyphs are important to your application, use a different font.


6.6    Internationalization

The following notes apply to restrictions on use of internationalization features in the windowing environments.


6.6.1    Use of PC-style Keyboard with Asian Input Method

When using a PC-style keyboard, the Hanyu, Hanzi and Hangul input method servers may not recognize the Backspace key as the key to delete the previous character in the preedit area of the input method. In this case, you should use the Delete key to delete the previous character.

The default Alt-space key for activating and deactivating the input methods may not work under CDE. If that happens, go to the Input Method Customization dialog box and change the Start Input Method and End Input Method keys to other key sequence like Ctrl-space.


6.6.2    Japanese Keyboard Support

DIGITAL UNIX now supports two new Japanese keyboard types (JIS and ANSI) on AlphaStation and AlphaServer systems.

To use JIS-type Japanese keyboards, like the PCXAJ-AA and LK411-JJ, you must set the language console environment variable to 50, as in the following example:

>>>  set language 50

To use ANSI-type Japanese keyboards, like the LK411-AJ, you must set the language console environment variable to 52, as in the following example:

>>>  set language 52

Japanese keyboard support is not available on TURBOchannel-based machines. See Section 6.6.3 for instructions on how to load Japanese keymaps when the language is not available at the system console.


6.6.3    Default Keyboard Mapping

The X server automatically chooses a keymap based on the language and keyboard settings of the system console. If your locale is not available on the system console, or you want the server to load a different keymap, you must set the system default keyboard map. The default keyboard map is specified by adding the -xkbmap option to the args list in the /usr/var/X11/Xserver.conf file. Add the -xkbmap option by using the following syntax:

! you specify command line arguments here
args <
-pn -xkbmap <keymap_file_name>_<keymap_name>
>

For example:

-pn -xkbmap digital_japanese_lk411aj

The available keymap files are located in /usr/lib/X11/xkb/keymap, where there is one file for each locale. The individual keymaps for the locale are in the keymap file, and are specified by the keyword xkb_keymap. For example, the /usr/lib/X11/xkb/keymap/digital_japanese keymap file contains an entry for the LK411-AJ keymap.

In addition, you can change keymaps after logging in by running the Keyboard Options desktop application /usr/dt/bin/dxkeyboard if you are using CDE. Use the keyboard setting option of the session manager if you are using xdm.


6.6.4    Lithuanian and Slovene Language Support

The following instructions are for modifying some system files to allow for some support of Lithuanian and Slovene.


6.6.4.1    Mnemonics in Lithuanian and Slovene DX Applications

DX applications in this release do not support the use of mnemonics in Lithuanian and Slovene language variants.


6.6.4.2    DX Applications Integrated to CDE Desktop (Application Manager)

To make the Visual Differences application /usr/bin/X11/dxdiff display differences between two text files written in Lithuanian or Slovene language, locate the following line in the /usr/lib/X11/app-defaults/DxDiff resource file:

*dxdiff*textdisplay*fontList:           fixed

Change the line, as follows:

*dxdiff*textdisplay*fontList:   -*-terminal-medium-r-narrow--18-*-*-*-c-*-*-*

You need superuser (root) privileges to make this change.


6.6.4.3    DX Applications Not Integrated into the CDE Desktop (Application Manager)

Some DX applications that are not integrated as part of the CDE desktop, but can be invoked using the File Manager or command line, do not set all display fonts according to the locale in use. If users want these applications to provide full Lithuanian and/or Slovene language support, they must perform the following corrective actions on the system with the Lithuanian and/or Slovene language variant installed.

Note that the superuser must perform all of these actions.


6.6.4.4    Lithuanian Language Variant

If you use the Lithuanian language variant and you want to operate in the DXsession environment, you must specify the default user interface font by adding the following line to the .Xdefaults file located in your home directory and logging in again for the change to take effect:

*FontList:      -*-*-*-r-Normal--*-120-*-*-*-*-*-*

If you operate in a multilingual user interface environment, this corrective action will cause other language variants to display using a default font that is slightly different than the font family used before this action was performed.

If you want to use the default user interface font with the Motif window manager, locate the following line in the /usr/lib/X11/app-defaults/Mwm resource file:

Mwm*fontList: -*-Menu-Medium-R-Normal--*-120-*-*-P-*-ISO8859-1

Change the line, as follows:

Mwm*fontList: -*-*-*-R-Normal--*-120-*-*-P-*-*-*

You need superuser (root) privileges to make this change.


6.6.5    Dxterm Does Not Support Latin-2, Latin-4 and Latin-Cyrillic Characters

The dxterm application is not able to display Latin-2, Latin-4 and Latin-Cyrillic Characters even when the locale is set correctly. Therefore, dxterm should not be used for displaying the following languages: Czech, Hungarian, Lithuanian, Polish, Russian, Slovak, and Slovene. The dtterm application should be used in this case.