Intel

Fortunately Intel provides binary driver set called Intel® Embedded Graphics Driver (IEGD) supporting all embedded video chipsets, containing binary form of video driver libraries for latest Xorg, OpenGL and VA.

While most of the work you need to do is to have IEGD_10_3_Linux.tgz file (in case of IEGD 10.3) extracted onto the target box and to copy various .so files in proper places (follow IEGD documentation). Yet there is one more complicated thing extra – IEGD Kernel Module (IKM) iegd_mod.ko that has to be compiled out of the source shipped with IEGD.

Linux Kernel module

IEGD documentation clearly states that only few distributions are supported by this driver, and those are i.e. Fedora 8 & 10, some older Ubuntu 8.x and finally Moblin. But what about others, such as Debian, newer Ubuntu. You think you are unlucky running other distro? You shall understand word “supported” here as “tested”.

Reading the documentation, in all cases your are supposed to enter IKM folder of extracted drivers and launch install.sh script. This script shall compile and install without any hassle IKM on “supported” distributions. Surprisingly trying that on your distribution even it is not supported may work too! With one important exception it produces bogus driver that will crash your kernel.

Finding the proper way for your distribution

This recipe will save some few hours upto few days of struggling with fancy errors trying to compile and run the IKM module on your system

Investigating the driver and install.sh first thing to notice is that it checks you Kernel version, it also takes (false) assumption that your are running one of the “supported” distros, so i.e 2.6.27 may mean Fedora version of the 2.6.27 Kernel not any 2.6.27 kernel.

Linux distributions have this fancy characteristic that they usually come with heavily patched kernel, so when you take 2.6.xx driver module from one distro and try to run it on the same version kernel on the other distro it will likely crash your kernel. Why? Incompatible ABI.

What Intel (Tungsten?) did in IKM is prepared IKM/val subfolder with headers extracted from several kernel sources of “supported” distributions. And what install.sh does, it tries to guess which one of DRM and AGP kernel module headers placed in that subfolder are OK for your Kernel.

In case you are running on the “unsupported” distribution the answer in 95% cases is NONE! Even you will be able to compile the iegd_mod.ko using Makefile produced by install.sh the module will crash you kernel as soon you will try to use it. Since your kernel has incompatible ABI (different structures) with the ABI provided inside IKM/val subfolder.

Preparing for compilation of IKM for your own kernel

If you are running “unsupported” distribution you should avoid then using headers in IKM/val subfolder. The right way is to take AGP and DRM headers out of your running kernel sources (you don’t have to compile the whole kernel of course).

So go to IEGD_10_3_Linux folder and launch:

sudo apt-get install linux-headers-x.y.zz
apt-get source linux-image-x.y.zz

Where x.y.zz is your running kernel version. (Use your own distro command to grab kernel source if you don’t run on Debian or Ubuntu)

This will install kernel headers and scripts to build kernel modules and also produce linux-x.y.zz folder containing source code of your running Kernel. The whole trick if to place (replace) Makefile in IKM folder as below:

KERNELVER ?= $(shell uname -r)
KERNELDIR ?= /lib/modules/$(KERNELVER)/build
INSTALLDIR ?= /lib/modules/$(KERNELVER)/kernel/drivers/char/agp
PWD ?= $(realpath .)

EXTRA_CFLAGS += -I$(PWD)/include
EXTRA_CFLAGS += -I$(PWD)/../linux-$(KERNELVER)/drivers/char/agp
EXTRA_CFLAGS += -I/lib/modules/$(KERNELVER)/build/include/drm

all: clean modules

modules:
	@echo $(PWD)
	@$(MAKE) -C $(KERNELDIR) M=$(PWD) modules

install:
	install -o root -g root -m 755 -d $(INSTALLDIR)
	install -o root -g root -m 744 iegd_mod.ko $(INSTALLDIR)
	/sbin/depmod -a

uninstall:
	rm -rf $(INSTALLDIR)/iegd_mod.ko
	/sbin/depmod -a

clean:
	@rm -f *.o iegd*.ko iegd*.mod.c iegd*.o agp/*.o drm/*.o Module.symvers
	@rm -fr .intel* .tmp* .*.cmd agp/.*.cmd drm/.*.cmd

obj-m := iegd_mod.o
iegd_mod-objs := agp/pci.o agp/global.o agp/drv_alm.o agp/drv_nap.o agp/drv_plb.o agp/drv_cmn.o agp/drv_gn4.o drm/iegd_drv.o drm/iegd_interface.o drm/iegd_interface_265.o drm/iegd_interface_2611.o drm/iegd_interface_2615.o drm/iegd_interface_2624.o drm/psb_irq.o

You don’t need to launch install.sh at all. Just paste the file as above.

As you see now, this Makefile references to ../linux-$(KERNELVER) for your running Kernel source AGP & DRM headers. Yet however you may still need to do few tweaks in your Makefile, see notes below:

Note (1) In case you are running older kernel, /lib/modules/$(KERNELVER)/build/include/drm may not exist, then $(PWD)/../linux-$(KERNELVER)/drivers/char/drm should be right path to put in the Makefile instead.

Note (2) The Kernel source code folder you downloaded (i.e. via apt-get source) may not actually match exactly linux-$(KERNELVER), so you may change that EXTRA_CFLAGS setting manually:

• In case of Ubuntu `uname -r` is 2.6.31-19-generic while the extracted source folder name has no -generic suffix and it is just linux-2.6.31-19.
• In case of Debian `uname -r` is 2.6.26-21 while the extracted source folder name is linux-2.6-2.6.26-21. Weird huh?

Final fixes before compilation

There is a file still missing if you try now to `make`. It is file that exists in IKM/val/agp but does not exist in your $(PWD)/../linux-$(KERNELVER)/drivers/char/agp. It is called interface_abs.h.

Wonder why the heck it is NOT in IKM/include!? This is a little lack of consequence from Intel here.

Anyway just copy interface_abs.h into IKM/include out of IKM/val/agp/agpm0vmob2 if you are running on >= 2.6.30 Kernel or from IKM/val/agp/agpm0v103 otherwise. The only difference between interface_abs.h from agpm0vmob2 and agpm0v103 is one macro definition.

Finally we need two little extra fixes.

(1) Trying to compile on Debian Lenny we will get many nasty errors from kernel headers for IKM/drm/iegd_interface.c. Moving igd_abs.h inclusion in this source file little down fixes the issue. Edit IKM/drm/iegd_interface.c as below:

 #include "iegd.h"
-#include "igd_abs.h"
 #include "drmP.h"
 #include "drm.h"

+#include "igd_abs.h"
 #include "iegd_drm.h"
 #include "iegd_drv.h"
 #include "psb_intregs.h"

(2) IKM/drm/iegd_drv.c tries to include linux/config.h at the very begining of the file. This is not actually necessary, and anyway does not exist, so you may comment that out:

-#include <linux/config.h>
+/* #include <linux/config.h> */

Compiling at last

Now you are ready to so `make` and `sudo make install`. This time  iegd_mod.ko should be ABI compatible with your kernel.

I have tested this method on Debian 5.0 Lenny and Ubuntu 9.10 Karmic Koala.

To ensure everything works fine after driver installation try:

sudo modprobe iegd_mod

And try to go into IKM/agp and compile and run agp_test.c:

gcc -o agp_test agp_test.c
sudo ./agp_test

Next try the same with IKM/drm compiling and running drm_test.c.

If those two test won’t fail and won’t blow your kernel it means you have fully working IEGD module on your own Linux distro.

Notes for users of old psb-modules or psb-kernel-source Ubuntu package

Older psb-modules and psb-kernel-source Ubuntu packages install their own incompatible drm.ko module at /lib/modules/`uname -r`/updates/char/drm.

Check find /lib/modules/`uname -r` -type f -name 'drm*' you should have only one: /lib/modules/`uname -r`/kernel/drivers/gpu/drm/drm.ko

In case if you find other drm.ko, probably in updates/char/drm delete it. That one came from psb-kernel-source and is causing you a trouble. You may ensure you got only valid drm.ko reinstalling your kernel image with:

apt-get install --reinstall linux-image-`uname -r`

Notes for curious

The difference of Makefile of mine and Makefile produced of install.sh is the beginning:

KERNELVER ?= $(shell uname -r)
KERNELDIR ?= /lib/modules/$(KERNELVER)/build
INSTALLDIR ?= /lib/modules/$(KERNELVER)/kernel/drivers/char/agp
PWD ?= $(realpath .)

EXTRA_CFLAGS += -I$(PWD)/include
EXTRA_CFLAGS += -I$(PWD)/../linux-$(KERNELVER)/drivers/char/agp
EXTRA_CFLAGS += -I/lib/modules/$(KERNELVER)/build/include/drm

If you try to run install.sh EXTRA_CFLAGS will include two of IKM/val folders which contain some Kernel source extracted header definitions that are likely not compatible with your Kernel.

I use also PWD ?= $(realpath .) here instead of PWD ?= $(shell pwd) because with some Linux headers versions $(shell pwd) resolves to /lib/modules path not the path where IKM sources are.

Notes for Intel

It would be nice for next IEGD release if IKM source tree would be made for readable and clear:

1. IKM/val should be renamed to IKM/kernel-headers (what the heck “val” means here ?!) and this should be noted somewhere in docs that files here are NOT made by Intel but extracted of “supported” Linux distributions Kernel sources
2. interface_abs.h should moved away from IKM/val (IKM/kernel-headers) to avoid confusion (with point 1) and placed into IKM/includes (and there should be #ifdef for this one macro that makes it different for across 2.6.30)
3. IKM/drm/iegd_interface.c should be fixed as described above (moving iegd_abs.h inclusion little bit down).
4. IKM/drm/iegd_drv.c inclusion of <include/config.h> is not necessary, may be removed.
5. Finally install.sh should contain case when running on “unsupported” distribution.
   So it shall make SURE if running on “supported” distributions and then and only then use files from IKM/kernel-headers, OTHERWISE ask for a path for your own Linux distribution Kernel source’s to find a path for your own kernel/drivers/char/agp and kernel/drivers/char/drm (include/drm) i.e. by showing:

   Your Linux distribution and Kernel version was untested, however you may try to compile and run driver on your own risk.
   Please provide your running kernel sources extracted i.e. on Debian or Ubuntu using apt-get source linux-image-2.6-686:
   [path to your kernel]:

Fell free to post your comments and problems with method presented here below using comment form!

Seems it is very hard to spread the news about CMSity around the world, and acquire some user base of this project. Till now I did few commercial deployments of CMSity, however the cmsity.com page hits look really miserable.

I wrote mails to many CMS magazines asking to drop a note about my project. However only two of them replied and posted something on their sites about CMSity. So I still miss some more reviews that can put a breathe into the project. But it seems my mails are ignored by majority of big CMS related sites making very hard to promote new project like CMSity nowadays.

Since I believe this software presents great value and outperforms other popular solutions I consider releasing it as open-source, however probably not GPL but some license that will force the code to stay by the author (me), deny all the forks, making all community changes happen to be included in the source code base.

Open-source is a great idea, but I have seen too many projects that were just bloated, forked and spoiled by masses of developers that were just about put something of themselves in the project regardless of quality of the included changes, missing overall sense and directions of the project itself. That is why I decided to keep the code closed initially, while giving the licenses for free, but it seems non-open source project are just kicked out of the focus today, and releasing the source code is a “must” to gain the momentum.

So I decided to create Haml “mod” that uses GetText (FastGettext alternatively) to automagically translate static texts from Haml templates during precompilation stage. So something that you don’t see and you don’t need to worry about.

Normally you would use _(text) calls to translate string in your templates as below:

%h1= _('Items')
- items.each do |item|
  .item
    %h1= item.title
    %a{ href='/edit' }= _('Edit')
    %a{ href='/delete' }= _('Delete')

You can see this is pretty ugly and unreadable. If you gonna have multi-language site you want to translate all of the static texts there anyway, without doing anything extra. So you would prefer to type:

%h1= Items
- items.each do |item|
  .item
    %h1= item.title
    %a{ href='/edit' } Edit
    %a{ href='/delete' } Delete

And have “Items”, “Edit”, “Delete” just translated, right? This is what my mod does. It translates all of those at precompilation stage which also is much better for your application performance, since GetText routines are called only once at precompilation stage. Here it goes.

haml_gettext.rb

# Haml gettext module providing gettext translation for all Haml plain text calls
#
# http://pastie.org/445295

class Haml::Engine
  # Inject _ gettext into plain text and tag plain text calls
  def push_plain(text)
    super(_(text))
  end
  def parse_tag(line)
    tag_name, attributes, attributes_hash, object_ref, nuke_outer_whitespace,
      nuke_inner_whitespace, action, value = super(line)
    value = _(value) unless action || value.empty?
    [tag_name, attributes, attributes_hash, object_ref, nuke_outer_whitespace,
        nuke_inner_whitespace, action, value]
  end
end

All you need is to choose GetText or FastGettext and load my mod later on.

require 'haml'
require 'fast_gettext'
include FastGettext::Translation
require 'haml_gettext'

You probably want to know the way to your gettext pot/po files out of the tempaltes. I have prepared here Rake tasks for you as well (based on work I found somewhere over Ruby blogs) to parse Haml templates extended to include static texts in the translation.

Rakefile

desc "Update pot/po files."
task :updatepo do
  require 'gettext/tools'
  require 'haml_parser'
  GetText.update_pofiles("rbigg", Dir.glob("{lib,views}/**/*.{rb,haml}") << "rbigg.rb", "rbigg 1.0.0", :po_root => 'locale')
end

haml_parser.rb

# Haml gettext parser module
#
# http://pastie.org/445297
require 'gettext/tools/rgettext'
require 'gettext/parser/ruby'
require 'haml'

class Haml::Engine
  # Overriden function that parses Haml tags
  # Injects gettext call for plain text action.
  def parse_tag(line)
    tag_name, attributes, attributes_hash, object_ref, nuke_outer_whitespace,
      nuke_inner_whitespace, action, value = super(line)
    @precompiled << "_(\"#{value}\")\n" unless action || value.empty?
    [tag_name, attributes, attributes_hash, object_ref, nuke_outer_whitespace,
        nuke_inner_whitespace, action, value]
  end
  # Overriden function that producted Haml plain text
  # Injects gettext call for plain text action.
  def push_plain(text)
    @precompiled << "_(\"#{text}\")\n"
  end
end

# Haml gettext parser
module HamlParser
  module_function

  def target?(file)
    File.extname(file) == ".haml"
  end

  def parse(file, ary = [])
    haml = Haml::Engine.new(IO.readlines(file).join)
    code = haml.precompiled.split(/$/)
    GetText::RubyParser.parse_lines(file, code, ary)
  end
end

GetText::RGetText.add_parser(HamlParser)

So this is it. Have fun with nice and clean templates that are translated on the fly

See & get more…

You can find more recent and complete code at my Sinatra Hat GitHub hosted Ruby gem project.

1. It uses now click menu instead of keystroke “System Events” command, because in some cases when you had this script assigned to shortcut that used Ctrl or Shift modifiers, those modifiers were sent together with Cmd to “Terminal” producing invalid behavior.
2. It waits 0.5 second when window is busy just in case Terminal.app was not running and it is just loading the shell which makes it busy for short while too. Fixes incorrect behavior of opening extra tab when Terminal.app was not running.

If you ever wondered how to open specified path in new tab of Terminal.app or reuse current one if it is not busy (running a command), here’s a script you may use:

tell application "Terminal"

    activate

    set windowCount to (count of the windows)

    -- Terminal may be just launched loading the shell, wait a bit
    if windowCount is greater than 0 and first window is busy then
        delay 0.5
    end

    -- Still busy / no windows? open new tab
    if windowCount is greater than 0 and first window is busy or windowCount is 0 then
        tell application "System Events" to tell process "Terminal"
            click first menu item of first menu of second menu item of first menu of third menu bar item of first menu bar
        end tell
    end if

    do script "cd #{e_as(e_sh(dir))}" in first window

end tell

Where #{e_as(e_sh(dir))} is your desired folder. This is modified chunk of TextMate’s command script found at Mark Eli Kalderon’s Blog. Thanks Mark!

Note: Mark’s TextMate command script does not open anything when Terminal.app has no windows or it is not running.

I am running my own business for 3 years now, however last 2.5 years I was working actually for just 3 clients that were keeping me alive, most of them were foreign companies. So I wasn’t particularly interested what is going on in Kraków where I am living for past 10 years. Since lately one of my major clients is going to shut down his business I decided to try myself at the local market – as so called “freelancer” seeking for the projects.

I must confess it does happen a lot in Kraków nowadays. Wow… I am pretty happy I have chosen to stay in such a great city. Keeping my finger crossed for Mike Butcher having TechCrunch conference done here in Kraków.

It is hard to be Switcher and totally forget/abandon Windows projects, since most of my clients… well almost all of them are on *indows. So since I switched, I am constant user of VMWare Fusion + XP (Win7, Win98) as a guest OS having Visual Studio installed inside. But sometimes if you want to create small cute application for *indows I prefer do it 100% on Mac with TextMate, then just test it on Windows. This is what MinGW cross compiler is perfect for. Not to mention I did Miranda’s MinGW Makefile that successfully builds miranda on Linux/Mac using cross-compiler, so it can be queued for nightly builds on SF.net servers.

We cannot count on free “performance lunch” anymore, but how about at least a pie for free? Do we need to throw all our old source-code into the trash bin and start over again? 

Certainly, not. We may think of our old software as a zombie of the new multi-core era. Still there is a way to make the zombie walk, even walk faster. Of course we will need to rewrite our code sometime, but we may postpone this nasty need for a while. 

The computing paradigm shift is now a fact we need to learn how to live with. It is unquestionable that processor manufacturers hit the barrier of 3 GHz. There pretty many news about spinning the CPU up to 5 GHz or so, but do not try to do so at home unless you got liquid nitrogen cylinder around. Over 3 GHz heat emission grows unreasonably making the CPU economically worthwhile. 

So the only sensible way is now horizontal performance improvement, doubling the number of processing units. This means we can expect soon 128 core CPUs. Oh, wait they are here already; nVidia GeForce 9 series are perfect example of 128 core streaming processor. 

Now how to keep up with things that happen so fast. First we need focus more on performance of our code. Something that was not important before, now cannot be ignored.

Want more, read my article draft below:

• A Pie for free.pdf 256KB, 2008-06-16

After spending few years using WordPress, MODx, PHPnuke I found out those systems getting more and more complicated, well yes sophisticated too, but first of all complicated. Anyway, feeling that this is not right direction I have decided to rewrite something by my own; simple, but powerful enough to provide functionality that you expect from most of the modern sites – blog, forums, RSS feeds.

Such functionality was requested by few of my clients, asking me: “Adam, we need something like WordPress, but we would like to have forums too, also site should be multi-lingual and finally we would like to limit the access to some parts of the site.” Just to mention those clients were running websites at PHP virtual hosting. I said, “Roger that” and started looking for some (any) CMS that could satisfy their needs.

I use to browse for new CMSes time to time. I did it again last October. Nothing new. Okay, maybe I could somehow tailor MODx, or WordPress. Nah. Then I found BBpress, well I was excited. A forum system made by WordPress creators, that integrates with WP. Great! Maybe this will fit.

Unfortunately I was hitting so many problems syncing WP and BBpress user database and logins, cookies (Why the hell it is so complicated?), so I gave it up.

I decided to write my own system, having in mind that forum, blog, they just differ at presentation level! There is always some parent page and subpages, post and replies, forum and topics. All having some hierarchy relations, and different presentation model. So why we have to install BBpress over WP if it is just a matter of presentation. Forum should look more like a table… while blog more like list of post excerpts. Why we cannot just turn WP sub-blog into the forum?

The difference is the presentation

So thing that makes forum or blog special is the way it is presented to the user. But from structure point of view both are the same. So this is the idea of the CMSity. For CMSity all pages (document tree nodes) are the same, they just carry the type which is used to determine what template to use to render them – what is their presentation.

Why PHP? Even I know more optimized/fast languages such as Ruby (1.9 is really fast), Java, C++.. started learning Erlang, still PHP is kind of standard that is present on most of the web servers and you can expect your clients will have PHP on their web servers. So I have chosen PHP; not really my favorite language, but the one I know pretty well and have spent quite a while with.

So this is genesis of CMSity… hope it will find many users and will be useful for you all.

• Project files and binaries were upgraded to Visual Studio 2008 (SP1).
• Installer now checks the runtime properly on Windows Vista & Windows 7 Beta, was tested also on Windows XP & 2003. Moreover since Visual Studio 2008 runtime seems to be present by default on many machines, most of you will not need to install it manually at all.
• Installer now contains OpenSSL 0.9.8j, so no more problems with OpenSSL external installation.
• … finally we got all the fixes and features introduced in jabberd2 till the revision #752.

Once you upgrade, you may uninstall Visual Studio 2005 Runtime and OpenSSL using Add/Remove Programs if you have them installed just for older jabberd2 win32 build.