X Windows
From OpenAlchemy.org
Contents |
X Windows
The X Windows system is the foundation for all graphical input and output on the Amida. The function of the X windows system is to isolate all applications from the details of the device used for display, whether monochrome, STN or TFT, and from the input device, whether it is touch screen, mouse or others. It also provides various primitives for window management, various rendering primitives and font management.
The architecture of the X Window System is based on a 'client-server' model. The system is divided into two distinct parts: 'display servers' and 'client programs'. Acting as intermediaries between the client application programs and local display hardware, display servers provide capabilities and keep track of user input. Client programs are those application programs that perform specific tasks and make requests communicated to the hardware display by the user.
This division within the X architecture enables the client programs and display servers to work together on the same machine or to reside on different machines connected by a network. Clients and servers talk using the Xlib protocol.
There are a lot of programs available in the public domain for Linux which use the X windows framework. By adopting the X windows framework, one can expect thousands of programs already available for porting. This is one of the main reasons for choosing the X windows framework for the Amida over alternative frameworks. In addition to this, the framework allows the flexibility of multiple widget sets and choice of a window manager, which makes it one of the most modular and flexible frameworks available. The current Amida alchemy framework is based on the X framework.
The X Windows system on the Amida is based on the XFree8.6 4.3 code base. The X Server is compiled to use a variant called the Tiny X Server. Tiny-X is a small footprint X Window server implementation for embedded systems. It was developed by Keith Packard of the XFree86 Core Team, sponsored by SuSE, Inc. The goal was to create something that would work well in a small memory footprint and more importantly, be robust in near out-of-memory situations. Typical X servers based on Tiny-X can fit in less than 1MB on x86 CPUs. Whereas the X servers on the PCs can occupy up to 100M in certain conditions.
Tiny-X uses new frame buffer code which is quite small and runs 1, 4, 8, 16, 24, and 32 bpp in the same code. The Tiny-X also handles an out-of-memory condition without failure. On the Amida, the Tiny-X server opens the kernel's frame buffer device (/dev/fb0) and maps its to its own memory (using mmap() system call). Thus, any writes to the mapped memory location are directly sent to the LCD controller using DMA by the kernel's frame buffer driver. Thus the X Server merely concentrates on correctly populating the mapped memory region whereas the kernel's frame buffer driver concentrates entirely on displaying the pixels on the LCD.
The Tiny-X server has an intermediate buffer called the shadow frame buffer, which is responsible for scaling and rotation of the frame buffer image so that it correctly suits the hardware orientation of the LCD.
The kernel's touch screen driver reports the user's taps on the touch screen along as a (position, pressure, duration) triplet to the X Server. The X Server constructs a valid XEvent structure for this and sends the event to be handled by the X clients which are interested in these events.
The kernel's button driver reports various button presses and releases performed on the Amida to the user. The X Server constructs a valid XEvent structure for this and sends the event to be handled by the X clients which are interested in these events.
Programming to the X framework
Like most GUI programming, X programming is also 'event-driven' , i.e. asynchronous. To elaborate, the rough sequence of an X program will be:
1. Perform initialization
2. Connect to the X server
3. Perform X-related initialization
4. While not finished:
* Receive the next event from the X server.
* Handle the event, possibly sending various drawing requests to the X server.
* If the event was a quit message, exit the loop.
5. Close down the connection to the X server.
6. Perform cleanup operations.
The X Display
The major notion of using Xlib is the X display. This is a structure representing the connection we have open with a given X server. It hides a queue of messages coming from the server, and a queue of pending requests that our client intends to send to the server. In Xlib, this structure is named 'Display'. When we open a connection to an X server, the library returns a pointer to such a structure. Later, this pointer is supplied to any Xlib function that should send messages to the X server or receive messages from this server.
The Window
The Window id is an identifier for an application created draw-able area on which the application can request the X Server to draw graphics, text or receive user input. An X application can create 0 or more windows. Windows have a parent-children relationship. All windows are children of the 'Root' window, which the X Server creates by default on startup. The entire set of windows for a given displayed can be represented as a rooted tree.
The GC - Graphics Context
When performing various drawing operations (graphics, text, etc), various options may be specified for controlling how the data will be drawn - what foreground and background colors to use, how line edges will be connected, what font to use when drawing some text, etc). In order to avoid the need to supply numerous parameters to each drawing function, a graphical context structure, of type 'GC' is used. Various drawing options are set in this structure, and then a pointer to this structure is passed to any drawing routines. This is convenient for performing several drawing requests with the same options. Thus, a graphical context is initialized, with the desired options, and passed to all drawing functions.
Events
A structure of type XEvent is used to pass events received from the X server. Xlib supports a large amount of event types. The XEvent structure contains the type of event received, as well as the data associated with the event (e.g. position on the screen where the event was generated, mouse button associated with the event, region of screen associated with a 'redraw' event, etc). The way to read the event's data depends on the event type. Thus, an XEvent structure contains a C language union of all possible event types. Examples of XEvents include XExpose event, XButton event, XMotion event, etc.
Compiling Xlib-Based Programs in Linux
Compiling Xlib-Based programs requires linking them with the Xlib library. This is done using a compilation command like this:
gcc prog.c -o prog -lX11
If the compiler complains that it cannot find the X11 library, adding a '-L' flag may help, like this:
cc prog.c -o prog -L/usr/X11R6/lib -lX11
If you are cross-compiling for the Amida, then you would use arm-linux-gcc as the C compiler. Note that you also need to have the X libraries compiled for the Amida available.
References and links
- The XFree86 Home Page, http://www.xfree86.org
- Various X Windows Links, http://www.rahul.net/kenton/xsites.html
- The X Window programming manual pages on Linux
- The X Window system, http://tronche.com/gui/x/
