Inspirated

Recent X.org drivers for Intel chipsets have introduced a new acceleration method called UXA which is supposed to provide “simpler, faster” code. However, for whatever reason, this bleeding-edge feature actually results in a loss of performance and reliability for particular chipsets (e.g. 915 family) on most distributions (Fedora and Ubuntu to name the foremost). In order to work around these issues, two solutions can be used:

1. Enable Tiling in xorg.conf.

   Section "Device" Identifier "Videocard0" Driver "intel" Option "Tiling" "False" EndSection

   Section "Device" Identifier "Videocard0" Driver "intel" Option "Tiling" "False" EndSection

   This fix does help the low framerate issue encountered on most distros, but it introduces screen tearing on some installations and worse, can happen in occasional X crashes as well.

2. Use “greedy” MigrationHeuristic with EXA instead:

   Section "Device" Identifier "Videocard0" Driver "intel" Option "AccelMethod" "EXA" Option "MigrationHeuristic" "greedy" Option "NoDDC" EndSection

   Section "Device" Identifier "Videocard0" Driver "intel" Option "AccelMethod" "EXA" Option "MigrationHeuristic" "greedy" Option "NoDDC" EndSection

   While this completely bypasses the UXA acceleration, it seems to work well for most users.

For the time being, I’m sticking with the second workaround since I have no issues with using the older acceleration architecture until the new one achieves some decent stability.

The 100th post, and considering that the most popular ones on the blog so far have been screencasts, there wouldn’t have been a better way to commemorate the occasion than editing a short music-video which would demonstrate the prowess of Linux on desktop.

“Two heads are better than one.”

Not everything is going perfect (I’ll get to that later), but it is an awesome feeling to be able to manage different windows on a 2048-pixels wide workspace.

(Click on the thumbnails for larger versions.)

The laptop is providing the VGA output using the Intel driver that’s included in X.org. However, to get the thing working, I had to edit my xorg.conf by hand. Here’s a list of things that work:

• The workspace “stretches” across the two displays by using xrandr commands outlined on this page.
• Applications get sliced across the display using Xinerama and as seen in the first two screenshots, even MPlayer’s x11 video output is perfectly happy with it.

And a list of things that don’t:

• For some unknown reason (which I’m too chuffed right now to be bothered about), if I specify the display modes explicitly for my laptop LCD screen on line 49 of the xorg.conf linked above, my VGA stops getting a display. Nevertheless, even without specifying display modes, the LCD resolution gets set as expected (1280×800 and 1024×768 for single and dual heads respectively).
• Xfce’s panel insists on sitting in the right-hand VGA only. Other people are reporting the same behavior for Gnome’s panel and AFAIK, there’s no workaround available at the time being.

I have yet to try a 2560×800 (1280×800+1280×800) configuration but the current resolution is still more than sufficient for some kickass photo/video editing. Also, debugging on one display while vim-ing in the other is a programmer’s paradise. Size does matter, after all.

A new version version has been released for everyone’s favorite hardware accelerated window manager. New features include window thumbnail generation in the taskbar, an opacify plugin (making all other windows transparent while mouse is hovering above one) and a rewritten (relatively) more user-friendly settings manager.

 
Taskbar window thumbnail generation and the new settings manager

The new settings manager can still be quite perplexing for newbies, but at least steps in right directions are being taken. Resizing windows has also been improved a little bit (my X server doesn’t crash whenever I attempt it). As far as I can tell, Compiz’s days of glory are almost over, Beryl has just got too much open-source-ness to be rivaled by a cathedral project.

Anyone who has ever tried to run Beryl using AIGLX must’ve heard about the infamous white cube issue. While facing this problem, the screen goes totally white and while you can rotate the cube, you can’t do pretty much anything else. As I had also spent about a week trying various methods to solve the problem, I thought to publish on my blog the combination that did work on my Intel G965 motherboard.

Apparently, the whole thing is messed up because of the opcode changes in glproto-1.4.8 and although I don’t have any idea why, downgrading glproto and recompiling Mesa and X.Org did not solve the problem for me. Nevertheless, the following setup worked like a charm:

• Git clone of glproto

git clone git://anongit.freedesktop.org/git/xorg/proto/glproto

• Git clone of mesa

git clone git://anongit.freedesktop.org/git/mesa/mesa

• Git clone of xorg-server

git clone git://anongit.freedesktop.org/git/xorg/xserver

• xorg-server-1.1.99.901-GetDrawableAttributes.patch and xorg-server-1.1.99.901-glXDRIbindTexImage-target.patch applied to the xorg-server. These patches are listed at Bug 8991 on freedesktop.org

Compiling these components might require you to install other ones (such as inputproto, damageproto etc.), but this page is not meant to be a HOWTO. I’m just confirming that the above mentioned things work for me on my Intel graphics card. There is even a new patch created for xorg-server but I haven’t tried it out myself yet (I’m away form my PC for at least another week). If anyone else can confirm some other combination to be working, I’ll be glad to list it here. Just leave a comment using the form below.