Archive for the ‘Linux’ Category

Knowledge for Linux Graphic Driver Stack

You Linux Video Card driver is not a single blob of code. As with any sufficiently large piece of software, things need to be broken up into discrete components for both technical and maintainability reasons.  And, there is no doubt a complete graphics stack is large: the AMD Catalyst driver is a 93MB download.  That’s over one hundred Mega bytes of executable code and supporting data.  In that humongous pile of bytes are roughly half a dozen different components working together to deliver your polygonal needs, without counting the configuration tools.  This, unfortunately, is not common knowledge.

In the open source world, our drivers are much more svelte, partly because less features are supported, and also because application-specific optimizations are omitted.  Unlike the proprietary drivers, however, the boundaries of separation are clearly visible.  In respect to “driver” code that is specific to a particular hardware, there are, more or less, three separate components involved:

  • X display driver
  • Mesa DRI driver
  • Kernel DRM driver

Indeed, in true UNIX fashion, all of these are actually worked on as completely separate projects, albeit with significant overlap in the personnels involved.

1. DDX: People’s Favorite Barking Tree

When the words “Linux video card driver” are invoked, the DDX is what people typically think of.  And, for good reason: historically, when configuring X11, the DDX was one of the few things that had to be configured by the user, and could be selected. This is your radeonhd, radeon, nv, and intel.

The main function of these drivers is to provide mode setting: that is, selecting the screen resolution, colour depth, turning outputs on and off, etc. The X server uses the DDX to perform basic, essential hardware manipulation so that you can have a graphical display at all.  Each DDX is hardware-specific: indeed, it stands for Device Dependent X (but this trivia is not very important.)

A DDX also provides hooks that allow the X server to offload certain drawing operations to the GPU so that they can be accelerated.  XAA, EXA, and UXA all fall under the DDX’s domain, in addition to Xv.  The former group is responsible for things like moving windows around your desktop, scrolling a website in your favourite browser, and compositing desktop effects.  The latter handles video rendering.

To summarize, everything 2D is the domain of the DDX.  And, in simple terms, it is its only domain.  If you are looking for 3D acceleration, this is not the tree to be barking up at.

2. Mesa DRI Driver: The Invisible Hero

OpenGL is the method with which applications achieve 3D rendering under Linux.  Unfortunately, but for good reasons, it is not possible to go from an OpenGL function call to manipulating hardware states in a single step.  Multiple translations must be done under the hood to convert those calls into something that the GPU can understand.

Mesa is largely divided into two parts: an OpenGL compatible library stack that applications can call into, and DRI drivers that translate Mesa-internal instructions into forms that the video hardware can understand and execute

After a call is made to the Mesa library and it has been translated into a GPU-specific language, the resulting operations need to be sent to the hardware for execution.  Mesa, however, cannot do this without help as it lives in user space:  only kernel space code is allowed to touch hardware directly.  Note that DDX is one of very few exceptions to this rule: it is technically user space code but allowed direct hardware access, for better or worse.

Unfortunately, sending these instructions through the DDX, and hence X, is not fast enough.  This point finally brings us to…..

3. DRM: Bridge to the Hardware

The final piece of the driver stack is the Direct Rendering Manager.  Oversimplified, it exposes certain features of the hardware with an abstraction layer to user space such that applications like Mesa can make use of a GPU more efficiently.

It is also the job of the DRM layer to provide measures that ensure multiple applications that require working closely with the hardware to not step on each other’s toes.

DRM drivers are Linux kernel modules, which are accessed by user space through libdrm.


Video hardware rarely change completely from generation to generation.  This means that the same code is often times used to operate GPUs from multiple generations.  Understanding which version of which component you need can occasionally become a messy affair.

To draw an example from the Radeon world, R3xx (Radeon 9xxx) and R5xx (Radeon X1xxx) GPUs share a similar 3D engine, but the mode setting engines are drastically different.  Therefore, while you can use the same Mesa DRI driver on both (r300_dri.so), radeonhd will not work on the former.  As for DRM, radeon (note that there is a kernel module and a DDX bearing this name) takes care of everything. (There are, of course, oddities from those generations that do not fit in to this generalization.)

Furthermore, there is currently a push in Linux to move video mode setting into the kernel (Intel is already there).  Kernel Mode Setting, more commonly referred to as KMS, brings the user- and kernel-space separation back to X, relieving the responsibility of hardware manipulation from the DDXes and putting it solely in the DRM drivers.  The details of this topic will—perhaps—be explored another time.


To Be Continued……….


Read Full Post »

*nix Login Process

After our *nix boots, at serial or virtual terminals, the user will see a login prompt:

machname  login:

This prompt is generated by a program usually getty which is regenerated by the init process every time a user ends a session on the console. The getty program will call login and login will call the user shell. The steps of the process are:

  1. init process spawns the getty process
  2. the getty process invokes the login process when user input login information
  3. the login process prompts for password, valid and start user’ shell on success and displays error on failure.
  4. user will run their session and eventually logout.



Read Full Post »

ssh/scp without passwd script

ssh/scp without password script

We would often use ssh/scp to do file sync between two servers. Here is a script which might help you to setup ssh/scp without passwd.

First expect must installed on your target linux machine.

Here you refer to the scpsetup tool:


Read Full Post »

Add vim to right cursor menu.

Ubuntu’s default editor is Gedit. The following tutor you how to change it into vim — the god of the editor.

  1. Edit /etc/gnome/default.list, replace all the gedit.desktop with vim.desktop.
  2. Under /usr/share/applications, create a file vim.desktop, edit like the following:
    • [Desktop Entry]
    • Encoding=UTF-8
    • Type=Application
    • Exec=vim %f
    • Icon=”whatever pic you want to specify”
    • Name=Vim
    • Terminal=true
    • NoDisplay=true


Read Full Post »