Archive for the 'development' Category


915resolution with built-in uvesafb

The video BIOSes of many (most?) Intel cards only support a very limited number of standard 4:3 resolutions. Widescreen and native LCD video modes are thus not available in (u)vesafb unless one hacks the BIOS using a special utility called 915resolution.

The usual approach to using the additional video modes with uvesafb is to build the driver as a module and load it after patching the BIOS.  I’ve recently obtained an Eee PC 1000 HE (which has the Intel GME945 graphics card) and wanted to use the native LCD resolution (1024×600) with the framebuffer, while keeping uvesafb built into the kernel.  Such a setup is advantageous in at least the following ways:

  • it provides a working framebuffer from a very early stage of the boot process
  • you don’t need to bother with setting up the initramfs (just like in the case of a standard uvesafb setup)

Here is what to do (the following assumes that you already have a working uvesafb setup, i.e. sys-apps/v86d and dev-libs/klibc are installed, and the kernel is properly configured):

  1. Manually build 915resolution, including all Gentoo patches, but linking the binary against klibc:
    cd /usr/portage/sys-apps/915resolution
    ebuild 915resolution-0.5.3-r2.ebuild unpack
    cd /var/tmp/portage/sys-apps/915resolution-0.5.3-r2/work/915resolution-0.5.3/
    make CC=klcc
  2. Copy the 915resoluton binary to /usr/src/v86d:
    mkdir /usr/src/v86d
    cp 915resolution /usr/src/v86d
    cd /usr/src/v86d
  3. Create a script named v86d using your favourite text editor.  Replace the 915resolution parameters to suit your needs (here we add a 1024×600-32 video mode).  Put the following in the script:
    /sbin/915resolution 4d 1024 600 32
    exec /sbin/v86d.real
  4. Create a file named initramfs, with the following contents:
    dir /dev 0755 0 0
    nod /dev/console 0600 0 0 c 5 1
    nod /dev/tty1 0600 0 0 c 4 1
    nod /dev/zero 0600 0 0 c 1 5
    nod /dev/mem 0600 0 0 c 1 1
    dir /root 0700 0 0
    dir /sbin 0755 0 0
    dir /bin 0755 0 0
    dir /lib 0755 0 0
    file /lib/ /usr/lib/klibc/lib/ 0755 0 0
    file /bin/sh /usr/lib/klibc/bin/sh.shared 0755 0 0
    file /sbin/v86d.real /sbin/v86d 0755 0 0
    file /sbin/915resolution /usr/src/v86d/915resolution 0755 0 0
    file /sbin/v86d /usr/src/v86d/v86d 0755 0 0

    Adjust this script by replacing bJzJ_Gx53KttbTgfZ4dktuoismc with what you actually have in /usr/lib/klibc/lib.

  5. Update your kernel config by setting CONFIG_INITRAMFS_SOURCE="/usr/src/v86d/initramfs".
  6. Rebuild your kernel.
  7. Update grub.conf or lilo.conf, modifying the kernel command line so that it includes your new video mode.  In our case, that would be uvesafb:1024x600-32.
  8. Reboot and enjoy your consoles in the native resolution of your LCD panel.

splashutils-1.5.4 released

Just a quick note to let everybody know that I released a new version of splashutils yesterday. 1.5.4 includes some interesting new features, the most important of which are the fbsplash message log, textboxes and special effects modifiers.

The fbsplash message log and textboxes make it possible to display textual information to the user without requiring a switch to the verbose mode. Here is a screenshot of a modified version of the gentoo-livecd-2007.0 theme illustrating the idea:livecd-2007.0 (with message log) screenshot

When the F3 key is pressed, a box with information about services that have already been started is shown on the screen.

The special effect modifiers are a fancy little thing that make it possible for icons (or any splash objects for that matter) to blend in or blend out as the boot-up progresses. This has in principle been possible with the previous versions of splashutils, but it required MNG support and specially prepared animations. Now you can get the special effects for free, even with a version of splashutils built without libmng support!


fbsplash naming changes

Recently, in the hope of making things clearer and easier for everyone to understand, I decided to do some renaming in my splash projects. The result: the kernel patch is now called fbcondecor (previously: fbsplash), the userspace part used to display the silent splash screen during boot is called fbsplash, and there is no longer anything named gensplash. The core fbsplash applications, along with some additional utilities are distributed in a single package called splashutils (available as media-gfx/splashutils in Gentoo).

So, to sum things up: fbsplash = silent splash, fbcondecor = verbose splash.

The reasons for the name changes:

  • Since the gensplash project was started, everyone referred to the userspace part as “fbsplash” anyway.
  • Many people don’t realize that fbsplash is fully functional and usable without any kernel patches.
  • fbcondecor (which stands for: Framebuffer Console Decorations), which was previously named “fbsplash”, has nothing to do with displaying the splash screen during boot. The only thing that it does is displaying pictures in the background of system consoles. This is not a splash screen, but a decoration and should thus be named accordingly.

Changes in Gentoo:

  • From splashutils-1.5 onward, the /etc/init.d/splash script is called /etc/init.d/fbcondecor
  • SPLASH_TTYS is now FBCONDECOR_TTYS, SPLASH_TTY_MAP is FBCONDECOR_TTY_MAP. Both are located in /etc/conf.d/fbcondecor

Announcing uvesafb

Those of you who use the Linux framebuffer and for some reason can’t use a chipset specific driver such as nvidiafb might be familiar with a project called ‘vesafb-tng’ that I started a few years ago.

vesafb-tng is a generic framebuffer driver for VBE 2.0 compliant video adapters. It removes most of the limitations imposed by vesafb, such as the awkward way of setting video modes (vga=xxx) or the lack of support for mode switching. There are two main problems with vesafb-tng:

  • it’s a rather ugly hack,
  • it works only on x86.

uvesafb, aka “vesafb-tng done right”, fixes these two problems. It uses a userspace daemon to run x86 Video BIOS calls, which makes the driver a lot cleaner and perhaps more importantly, makes it possible to use the driver on non-x86 systems.

uvesafb is still in alpha stage. It currently supports x86 and amd64 and has been tested with a few nVidia cards. If you would like to test it out, check the project webpage and follow the installation instructions. Bug reports and success stories are welcome :)


vesafb-tng developments

I’m happy to say that vesafb-tng has recently received a rather significant code overhaul.

The result is a new testing patch, timestamped 20050920.. So far the reports I got have been very positive. Some old SMP-related problems seem to be fixed, and the recently discovered highmem system instabilities that were traced back to vesafb-tng appear to be gone now. However, the new code could really use some more testing (both on machines that vesafb-tng had problems with in the past, and ones on which it was running just fine — to test for any potential regressions). If you feel like giving it a try, please apply the ‘testing’ version of the patch to a 2.6.13 or 2.6.14* vanilla kernel tree, and select ‘vesafb-tng’ as the framebuffer driver.

For those of you who haven’t heard about vesafb-tng prior to reading this post: vesafb-tng is a kernel framebuffer driver based on vesafb, designed to run on x86 systems and offer a wider set of features than vesafb does. A more detailed description can be found on the vesafb-tng project page.



For many of you this might be old news, but I have only very recently discovered a nice little app called torsmo. For those of you who don’t know it: torsmo is a lightweight system monitor which doesn’t require GTK, QT or other bloated libraries and which paints directly to the root window in X. It has support for all the standard things you would expect in a system monitor and can be easily extended if you want something more.

It doesn’t support hddtemp, though. It also doesn’t provide a flexible way to adjust the displayed text. I thought this was a pity, so I’ve written two patches to fix this (hddtemp, text ajd., all-in-one).

Here is what it looks like on my dekstop:
torsmo screenshot


Switching to git

I’ve finally created git repositories for vesafb-tng and fbsplash (I was using BitKeeper before it became non-free). So far everything seems to be working smoothly. I’m quite happy that once again I’ll be able to do a simple cg-update instead of manually unpacking, patching and diffing two kernel trees. Git appears to be a little slower than BK, but it should still be a huge time-saver for me.

Moving the repos to git also means that theoretically they could now be made publicly accessible, should anyone need access to the latest code. Unfortunately, due to some rather annoying limits my ISP is imposing on my net connection, this will most likely remain a purely theoretical possibility.

During the preparations for the migration I was searching for some documents describing the new git SCM. I read a few HOW-TOs on the lkml, but it turns out that the best doc is the Cogito README. If you want to start your own repo, you might just as well skip the HOW-TOs and go straight to the README.