CLX, remote X screens, and X server facilities on Genera

Open Genera 2.0 / Genera 8.5

The release roster identifies Open Genera 2.0 as Genera 8.5, released 7 October 1998, and lists:

The X-Documentation 421/422 patch-directory pair and the roster's 422.0 are not necessarily contradictory: one expresses released versus latest major generations, while the roster names the selected system version. They are both recorded because the media itself retains both notions.

The Open Genera Beta II notes list CLX, X Remote Screen, and X Documentation among the source systems on the CD. They list CLX-CLIM among optional loadable systems. They do not list X-Server. That omission agrees with the local source-tree and release-roster search, but it does not prove that no separate historical distribution ever supplied the server.

Genera 8.3 and the historical hardware server

The Genera 8.3 installation guides describe the server as an optional restored system with these conditions:

• it works only on non-embedded Symbolics machines;
• MacIvory and UX systems should instead use an X server on the embedding host;
• X-Server has no other loadable-system dependency, but its component C-Runtime must have been restored from the source tape and is loaded automatically;
• the X-SERVER-FONTS files must be restored for the standard server fonts; and
• Load System X-Server installs the application, whose default Select binding is Select Square.

The restriction matters for this museum. The VLM is an embedded Open Genera environment, so a documented inability to run the historical server there is a platform rule, not merely a missing command in the saved world.

The same installation guide calls X Remote Screen the client side, requires RPC, Embedding-Support, and IP-TCP, and says most Genera 8.3 worlds contain it. The inspected 8.5 declaration requires only Embedding-Support and IP-TCP. The evidence does not establish whether RPC became transitive, became unnecessary, or was simply omitted from the newer declaration; it establishes a release-level dependency difference.

Source-file generations versus the release component

The X Remote Screen 448 component directory names keyboards source generation 43 and x-program generation 22. The physical source tree also retains newer generations 44 and 23. The newer keyboard file adds a PCXAL-AA signature and mapping; the released generation 43 does not contain it. The five-command audit below uses the only present x-program body, generation 23. The Genera 8.5 VLOD contains all five command names and patch-load strings for 448.1 through 448.3, but a string occurrence is not executable proof.

Accordingly:

• the default keyboard table and all families through DEC LK401-AA are bounded to released source generation 43;
• PCXAL-AA is labeled newer local source only;
• the three commands also described in the manual have independent manual support; and
• the two source-only command additions remain unverified in a live 448.3 world.

Public API facility map

The ANSI-style XLIB package declaration in the inspected source exports 559 unique names. The count includes types, accessors, conditions, constants, functions, and macros. Its facility coverage agrees with the 15 substantive API chapters of the CLX Programmer's Reference:

This is a protocol-level toolkit, not an application framework. CLX does not by itself create a Genera program frame, choose a user-interface policy, or turn a Lisp listener into an X server. X Remote Screen and CLX-CLIM are two different higher layers built on it.

open-display and Genera connection paths

The inspected public entry point has this option surface:

On Genera, the implementation-dependent stream opener behaves as follows:

1. With display 0 and no explicit protocol, it invokes the generic X-WINDOW-SYSTEM byte-stream service on the host.
2. If a protocol is specified, or the display is greater than zero, it bypasses generic service selection.
3. The default explicit/network path is TCP on port 6000 + display.
4. The DNA path uses contact name X$X<display>.
5. On a VLM, protocol VLM uses the console channel supplied by life support.

All paths still lead to the ordinary X11 setup handshake and the same CLX object model. The transport changes; the client/server role does not.

The VLM console channel

The VLM-only source describes the console channel as a direct life-support interface to the host's X server. Genera asks it to read or write raw X data. The output path uses a coprocessor call to avoid VLM scheduling overhead; the input path queues bounded transfers and wakes the waiting Genera process. X Remote Screen starts this path with protocol VLM when a console channel is available.

This is the historical guest-side half of the Open Genera display path. It is not Xvfb, and it is not the host compatibility preload. The repository harness's current direct trace shows that the VLM also relays the principal guest X11 byte stream through host writes. The harness handles only narrowly pinned compatibility cases and delegates nonmatching X writes unchanged; it does not implement CLX or the Genera display device.

Complete direct command inventory

The newest inspected x-program source defines exactly five commands in the User command table. There is no private editor-like command loop or separate keymap for the framework itself.

The source explicitly suppresses an Output Destination keyword for Start X Screen. The other typeout commands participate in the normal Command Processor environment where applicable; no additional facility-specific output switches are defined in this file.

The public manual lists Protocol as a Start X Screen keyword. The newest Command Processor definition does not expose it, although the underlying CLX and X-screen implementation still accepts a protocol and the VLM startup path passes VLM. This is a manual/source interface discrepancy, not evidence that protocol selection ceased to exist internally.

Adjacent keyboard-layout command

The X user guide also documents the general Genera command Show Keyboard Layout. It is not one of the five commands defined by X Remote Screen, but it is the graphical companion to the X mapping reporter.

The Keyboard Control activity's Hardcopy Keyboard Layout operation is the manual's route to a landscape template. That hardcopy operation is not treated as an X Remote Screen command.

Start behavior and defaults beyond the manual

The underlying start function accepts host, display, screen, reuse, geometry, initial state, remote program, activity, foreground, background, border color, border width, who-line, restartable, and compatible-color options. It rejects an activity whose activity object says it cannot work on a single-activity X screen.

For a generic Genera X Screen, source-visible defaults are:

• X resource name genera and class Genera;
• title Genera on <local-host> and icon name Genera;
• black foreground, white background, black border, border width 0;
• normal rather than iconic initial state;
• the root visual depth, capped by any requested depth;
• a who line by default for the generic console;
• minimum size 640 by 320 with a who line, or 320 by 160 without one;
• maximum size equal to the selected X screen; and
• absent resource or geometry overrides, an origin 5 percent from the top and left with width and height equal to 90 percent of the X screen.

The last rule is the implementation behind the manual's less precise “covers most of the console” description. Width and height are clamped to the minimum and maximum bounds.

The created X window asks for key press/release, button press/release, exposure, visibility, structure, pointer motion, keymap state, enter/leave, and focus events. It requests backing store and installs normal ICCCM window-manager properties, including resource names, icon data, size hints, initial state, and user- versus program-specified geometry.

X resource database surface

The screen reads the root resource database and consults these application resources:

Compatible color is not a generic “color display” flag. The source enables it only if requested and an 8-bit pseudo-color visual is available. Otherwise it falls back to the root visual and default colormap.

Screen reuse and loss of connection

By default, Start X Screen asks to reuse resources from an old disconnected X screen. The manual names explicit halt, warm boot, and network failure as ways a screen can become reusable. Reuse No forces a new screen instead. This can preserve expensive Dynamic Windows histories, bitmaps, and screen objects while replacing the network-visible X connection.

The Genera 8.1 release notes record three behavior fixes that reveal practical remote-screen edges not conveyed by the command synopsis:

• the X client already spoke the X11 Release 4 protocol when the historical X server was upgraded to R4;
• Symbolics-keyboard recognition between the Symbolics client and server was repaired;
• Namespace Editor windows invoked from a remote console were fixed to appear on that remote console rather than the main console; and
• a timed-out local X connection was fixed so it no longer entered the Debugger.

These are release-note facts about 8.1. They do not prove that every later remote application is console-correct.

Complete portable function-key layer

This is the default X Remote Screen map, not a claim that the host desktop or museum automation layer sends every function key unchanged. The harness's own key translation must be verified separately for each runtime claim.

Complete portable keypad and named-key layer

The manual names the Keyboard character set as the bridge used by Dynamic Windows and Zmacs for arrows, by cut-buffer operations for Undo/Cut/Copy/Paste, and by the hardcopy facility for Print. #\Keyboard:Cut is the documented Lisp notation pattern. This translation layer makes the same physical key usable by presentation-based applications and editor commands without making those commands part of X Remote Screen itself.

Hardware signatures and mappings

Released keyboard source generation 43 registers these signatures:

Newer physical source generation 44 adds a PCXAL-AA signature and mapping for a Digital UNIX DECwindows server. Because the release component names generation 43, PCXAL-AA is not counted as released 448 source behavior here.

Detection compares the server vendor name and version plus its reported keysyms, allows a keycode offset, scores differences, and chooses a known signature only above the implementation's threshold. Heavily customized server maps can therefore fall back to the portable default. Set X Keyboard Mapping provides a manual override in the newer source; Show X Keyboard Mapping exposes the effective result.

The public X guide emphasizes Sun Type 3/4 and NCD diagrams and its general Show Keyboard Layout list includes several Mac families. The 8.5 source has a different concern: signatures actually used for automatic recognition. A graphical layout supported by the general keyboard-control database is not automatically proof of a signature in X Remote Screen.

Three font paths

The manual and source agree on a priority order:

1. If the X server has native Genera fonts, use them.
2. Otherwise, map character styles to standard 75 dpi X fonts when possible.
3. For a glyph with no usable server font, create an X pixmap from the resident Genera raster glyph and copy that image to the window.

The source inventories server fonts matching genera-*. Its standard family mapping is complete and small:

The named size mapping is tiny 6, very-small 8, small 10, normal 12, large 14, very-large 18, and huge 24. It maps the standard character set to ISO 8859-1 where possible and can compose server fonts with Symbol or local pixmap fallback glyphs. Show X Font Mapping exists precisely because one Genera character style can become a composite of these paths.

Native X font files and fallback pixmaps are delivery mechanisms for the same logical Genera font choices; they do not establish vector fonts inside the Genera display system. The separate Genera font extraction study documents the resident raster fonts and the distinct outline hardcopy subsystem.

Color

On a color X server, ordinary Genera graphics color and gray-level arguments can be realized through the X display device. The manual permits named basic colors, RGB triples in the range zero through one, or Genera color objects. Compatible color is a narrower indexed-color compatibility mode requiring an 8-bit pseudo-color visual, as described above.

Temporary pixmaps and a source-only failure mode

The X screen implementation defaults to allocating server-side pixmaps for temporary Genera bit arrays. That accelerates screen copies, particularly on color displays. A source-visible switch can disable this path and keep temporary storage out of the X server.

The implementation comment explains why: memory-limited X terminals can fail poorly near server-memory exhaustion. Disabling remote temporary pixmaps avoids that failure mode at a performance cost. This tradeoff is more specific than the manual's general discussion of choosing host/server versus Ivory memory for off-screen images.

Complete documented X11 Server controls

The implementation is unavailable, so “complete” in this table means every control named by the contemporary X guide. The manual gives no arguments or keyword options for them; hidden or release-specific options remain unknown.

The two start names and two halt names are documented with the same semantics. Without source or runtime evidence, this page does not invent a distinction. In switched mode, ordinary Genera key meanings are routed to the remote X client; the manual's example says Select L then selects a Listener inside a Genera Remote Screen running as an X client, rather than the local Listener.

Server fonts and maintenance commands

The distribution historically included a standard X font set in Server Native Format (SNF). Local Bitmap Distribution Format (BDF) files could be converted by loading the BDFtoSNF support and using the ordinary Compile File command. Create X Font Directory invoked the MkFontDir program to rebuild fonts.dir after SNF files were added or removed. Its directory argument had to be a Genera logical pathname.

These SNF files belong to the historical X Server product and are not the same as the resident Genera raster-font objects recovered from the world. No X Server fonts are extracted or published here.

Capture-specific TODOs

• TODO — X Remote Screen: after repairing the sandbox executable binding, start a fresh isolated session and use the current X screen to run Show X Keyboard Mapping and Show X Font Mapping. Capture a narrowly cropped, non-prose-heavy state that proves command availability and effective mapping. Starting a second remote screen requires a deliberately contained reachable X endpoint; the harness currently exposes no external route.
• TODO — activity-specific screen: in a containment design that can expose a second private X endpoint, start one activity-specific screen and verify its title, geometry, who-line state, Select-key behavior, and shutdown/reuse cycle.
• TODO — X11 Server: use a licensed non-embedded Symbolics system with the actual X-Server and X-SERVER-FONTS media. The Open Genera VLM is excluded by the contemporary platform rule and lacks the implementation.
• TODO — CLX-CLIM: load CLIM and CLX-CLIM from a private guest-visible source in a newly isolated world, then run a minimal frame through the CLX port. The preserved base world has no loaded CLIM system.

Any future selected image requires the image- and use-specific screenshot publication review. A single narrow screenshot beside analysis of mapping, remote-screen geometry, or the historical server workflow could support scholarship under a documented four-factor fair-use conclusion. A decorative console image, a gallery, or a screen full of licensed Help prose would not meet this page's evidence need.