The Y Window System: A Quick Look From 10,000 Feet

Y is a new window system. It's name was chosen for two very simple reasons:

  1. In the latin alphabet, it's the letter following X.
  2. It's not a latin character. It's cyrillic, and it's not pronounced "why". It's pronounced "oo".

The Y Window System consists of three distinct pieces:

The Micro Server
Responsible for initializing and shutting down the graphics hardware, setting up the initial root window, and send input device events to interested clients.
The Client Library
The library used to do anything in Y. It has three possible connection types. Local, which means it talks directly to the hardware; Network, which means it talks to a remote Network Server; and Memory, which means it draws directly to some area of memory (a YImage.)
The Network Server

Y attempts to address several limitations in the design of X. These include:

  • The developer must keep in mind different Visual types when writing her application. If there isn't code to handle a particular visual class, it doesn't work with that visual.
  • You have to constantly be aware of color handling. Applications have to write code to gracefully handle the event that a color isn't available, or that a colormap is full, etc. For this reason some applications, such as netscape, grab as many colors as possible on startup. While this usually means netscape has enough colors, other applications suffer.
  • X requires clients on the local machine to use the same protocol as those on distant networks. There are extensions, such as XShm, that help to alleviate this situation somewhat, but they are more a bandaid than a fix.
  • Any machine on a network running an X server is susceptable to any number of security holes. Also, there is no way to "turn off networking" in an X server. Even if you only want to run local clients, your X server can be contacted from remote machines.
  • X has had authentication mechanisms grafted onto it after the fact, trying to fix the relative lack of security present in the initial release. These solutions are more bandaids to fix problems that weren't properly addressed in the initial design.

To address the above, Y has the following features:

  • There are no visual types. Every Y display, regardless of color resolution, is available to the developer as 32 bit RGBA color. If the graphics hardware doesn't directly support this color depth, software dithering is performed. Also, alpha-compositing is performed in software if unavailable for a given graphics device.
  • There is practically no communication between the clients and the server (called the Micro Server) running on the local machine. The client asks the Micro Server for some information on startup (what devices it is using, what the ID of the root window is, etc.) and the Micro Server sends events from keyboard(s) and mouse(mice) back to the clients. Everything that would normally involve an X protocol request being generated is handled directly by the client, using shared memory and direct access to the video hardware. This includes any drawing operations, operations that affect the window heirarchy, etc.
    In the event of an operation that results in a window heirarchy change, the client causing the change notifies all the clients that have expressed interest in the changed windows.
  • The easiest way to lock out network connections in Y is to just not run the Network Server. The Network Server is the only program that accepts connections from remote machines and turns them into Y drawing operations.
  • If the Network Server is needed, there are varying levels of authentication available, provided with plugable security modules. They range from a simple password challenge to ssh-styled public key authentication. Sessions can optionally be encrypted, again using the same method as ssh.
    These security modules are configured by the individual running the server. In addition, the Network Server can be configured to display a warning dialog when someone attempts to connect from a remote host. The user can at that time decide to allow the communication to proceed, or can terminate the connection. Also, the Network Server can provide a list of clients that are connected from remote machines, including information regarding the connecting entity (login, full name, time connected, etc.). The user running the Network Server can then terminate a connection if they so wish.

copyright © 1998 Christoph Toshok
Last modified: Fri Feb 6 01:53:26 PST 1998