Linux, X, Desktops, Graphics and Enlightenment


The Rasterman (Carsten Haitzler) - raster@rasterman.com


This tutorial will cover:



The underlying graphics subsystem for Linux


Until kernel 2.2.0 Linux's subsystem for graphics was... well there wasn't one. Kernels 2.2.0 and beyond provide what you would call a simple framebuffer driver - it supports all VESA2.0 compliant cards (note that many older cards are not VESA 2.0 cards - they may just do VESA1.2 or earlier), and VGA modes. If you do not have a VESA2.0 card this will limit your graphics modes to 640x480 at 16 colors at best (and of course going down to 320x240 at 256 colors etc.). If you have a VESA2.0 card you will be able to get "better" modes - whatever modes your card supports (up to 1600x1200) and in other bit depths (8, 15, 16, 24, 32).


Of course this is only a dumb framebuffer - no acceleration at all. It's a memory region the processor can write data to and read data from. The only method of acceleration is by using the now memory-mapped register space of the card the fbcon 2.2.x device gives you. This is the memory space used by the graphics card's registers used to control its acceleration features. Of course this varies from card to card. The application using this memory space must know what every part of it means and does.


Basically now the kernel provides a very primitive method of accessing a display device - all the intelligence is still up to the application - thus things haven't changed too much. This is where we still require X.


The X Window System


The X Window System is the base graphics accelerator, driver and input device handler and event dispatch system the vast majority of UNIX platforms use today. This is also the de-facto graphics subsystem for Linux.


What many people mightn't know is that X actually doesn't have many policies - it does not, for the most part, dictate any form of behavior for applications, environments, widgets etc. It leaves this completely up the the application level, rather than imposing this on clients. X is also at a fairly low level. It simply handles input device management (when you move your mouse, press or release a key, press a mouse button etc.) and then dispatches an event to the interested "clients". In the X world all applications using the X Server to display something are referred to as clients.


A few basics of X.


As for display in X - everything is a drawable. A drawable pretty much boils down to being a Pixmap or a Window. A Window is an actual visible drawable element (normally rectangular - the shape extension allows you to modify the shape of this Window). A Pixmap is an off-screen chunk of memory you can draw to but in itself is never visible.


Windows can have child windows that are placed inside their parent and are clipped by the bounding area of their parent (which is the parents rectangle and shape mask if it has a shape mask). Windows can be moved, resized, masks changed, reparented to other Windows, mapped (once you create a Window it is not visible until mapped), unmapped (you can hide Windows by unmapping them), destroyed etc.


Both Windows and Pixmaps can be drawn on using several primitive drawing functions X provides. This, amongst others, include the drawing of lines, rectangles, filled rectangles, arcs, filled arcs, polygons, copyarea (copy section of one drawable to a another drawable) and of course "PutImage".


Each Window can have an event mask set on it to select what events that Window will accept (which will then be delivered to the client application when it asks for the next event in the queue) such as button press, release, key press, release, mouse motion events, expose events, resize and move events (combined known as configure events) and so on. Whenever an "event" happens to a Window X will send that event to the client requesting that event in an event mask on that Window (for those of you who know X well I am skipping the event propagation to parents here for simplicity sake).


X also allows you to attach data to Windows (via properties) and send and receive messages via these windows as well (using client message events). X works locally and over TCP/IP across a network. It provides lots of flexibility and allows anyone to build something on top of it. To aid in this there is a standard called ICCCM (Inter Client Communication Conventions Manual) that defines how clients applications can hint / suggest their windows be displayed and manipulated by another special client in X called the Window Manager. This will be the next topic.


Conventions, rules and subsystems on top of X


X itself does not impose many policies on programs - X is mechanism, not policy. The closest it gets to this is ICCCM. The Inter Client Communication Conventions Manual defines how a Client can interact with a Window Manager in order to get some level of guaranteed behavior. This defines ways in which a program can hint to the Window Manager in what increments to resize a window, minimum and maximum sizes and aspect ratios, titles, names, icons, position, size, etc.


From this diagram you can see that "Applications" or Clients sit both on top of and and in line with where ICCCM defines the Window Manager to be in the X hierarchy. It is a fairly simple system where Clients use X calls to talk to the Window Manager and via the ICCCM standard get a set of behavior. They also talk with X directly to perform all rendering inside of their own windows, and also handle events and get feedback from the ICCCM system. The Window Manager also communicates with X directly via X calls, and will respond to ICCCM requests (implicitly generated by X calls) by using more X calls. All the REAL traffic of communication ALWAYs goes through the X Server. The communication path between Application and Window Manager is implicit or fictitious as it is merely a definition of X calls that make up the ICCCM standard.


In the past it has been convention that the Window Manager provides not just simple window management, but also provides a method of launching programs, as the Window Manager has always been the first and normally only thing launched on logging into X since it is almost compulsory in order to actually manage ones windows. Thus they have had launching capabilities from their menus, or button bars, or icons, or anywhere else the Window Manager sees fit to make launching abilities available to users.


Applications traditionally have not ventured outside of their application windows. They tend to remain inside their top-level window(s) (top-level being the base window(s) of the application that are then reparented and managed by the Window Manager). Whenever an application ventures outside of its windows, or a Window Manager ventures into the windows of applications there generally has resulted in incompatibilities between WM's and Clients. Although this isn't stated in ICCCM it is still an good rule of thumb to follow when developing for X - never venture outside of your "zone" - if you want to you should use an established interface (in this case ICCCM is the only "official" established interface).



Window Managers and Desktops - what is the difference?


There seems to be a level of confusion about Window Managers and Desktops. KDE is a Desktop, CDE is one. Windowmaker, Enlightenment, FVWM etc. are pseudo-desktops (I shall refer to these as Desktop Shells), GNOME is not a Desktop - it's an application framework.


What is the difference.


To be a Desktop you must in your package provide a Desktop Shell AND an Application Framework. This means you provide a Window Manager, a file manager, an application launcher, which comprise the Desktop Shell, and an application framework (common look, feel, ay of communicating etc. for applications and an easy way to build these, and store their existence as an application on the system).


GNOME is not a Desktop as it is missing one crucial component - a Window Manager. Enlightenment is not a Desktop as it is missing an Application Framework.



Where is Enlightenment heading?


Enlightenment is heading to become a Desktop Shell. Once this is done and it is all cleaned up, optimized, debugged and so on E will reach version 1.0. until then there is a lot of work to be done.


So far Enlightenment has pagers, virtual desktops, themes, configuration dialogues, image loading back-end, actual window management, menus, program launching, minimal dock app support and lots of eye candy. What has yet to be added is a good app launching system, a decent dock app / applet system, filemanager and much more configurability. There are some plans being looked at at putting a Window Manager into the X server itself via an X extension. This would give a great increase in performance since there are no more server round-trips, direct access to framebufer and acceleration, with no context switches and hopefully less data duplication between X and the Window Manager client process. This would also involve an Image processing and rendering extension (Imlib) being put into the server as well.

This would be a big benefit to not just a Window Manager but all applications that use images in any way or from, saving memory copies and possibly accelerating transformations and rendering using hardware.


The move of a WM from client space into the Server would probably mean a HUGE overhaul, but ultimately would be worth it. This is still under investigation.