michal's weblog

915resolution with built-in uvesafb

Michał Januszewski — Sun, 31 May 2009 15:59:49 +0000

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):

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

Copy the 915resoluton binary to /usr/src/v86d:

mkdir /usr/src/v86d
cp 915resolution /usr/src/v86d
cd /usr/src/v86d

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:
```
#!/bin/sh
/sbin/915resolution 4d 1024 600 32
exec /sbin/v86d.real
```

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/klibc-bJzJ_Gx53KttbTgfZ4dktuoismc.so /usr/lib/klibc/lib/klibc-bJzJ_Gx53KttbTgfZ4dktuoismc.so 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.

Update your kernel config by setting CONFIG_INITRAMFS_SOURCE="/usr/src/v86d/initramfs".
Rebuild your kernel.
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.
Reboot and enjoy your consoles in the native resolution of your LCD panel.

splashutils-1.5.4 released

Michał Januszewski — Tue, 26 Feb 2008 20:27:32 +0000

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:

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

Michał Januszewski — Wed, 29 Aug 2007 20:34:06 +0000

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

Michał Januszewski — Mon, 11 Jun 2007 15:51:57 +0000

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 :)

Freetype adventures

Michał Januszewski — Sun, 11 Feb 2007 15:23:01 +0000

Like (I suppose) many of you, I have recently upgraded to freetype-2.3.1. After the upgrade I found my fonts suddenly changed from this:

to this:

which is supposedly an improvement — albeit one that I do not like. I have just spent far too much time on trying to figure out how to get my fonts back to normal and so I thought I’d share my solution with you. It turns out the only thing you have to do is to put the following snippet of code into your /etc/fonts/local.conf:


	
		true
	
	
		false
	
	
		true
	
	
		hintfull
	
	
		none

The most crucial bit seems to be the hintstyle. Unless it’s set to hintfull, the fonts look just like they do with the default settings, or worse.

vesafb-tng developments

Michał Januszewski — Thu, 22 Sep 2005 16:23:30 +0000

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.

torsmo

Michał Januszewski — Mon, 19 Sep 2005 09:06:55 +0000

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:

Switching to git

Michał Januszewski — Mon, 27 Jun 2005 08:54:46 +0000

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.

Back from London

Michał Januszewski — Sun, 26 Jun 2005 22:13:02 +0000

I’ve been back home for the last few days, but I also have been too busy/lazy to blog about the trip. But finally, here it is.

My visit to this strange place called London (where people drive on the left side of the road and you need “look right/left” marks on the pedestrian crossings, and where you get to see and meet people of tens of different nationalities, speaking dozens of languages) despite being quite short, has been very enjoyable and fruitful.

Participating in a Gentoo dev/user meeting and meeting in real life some of the people I had so far only known from the IRC was a lot of fun, as was my visit to the Science Museum and particularly to the Hitchhiker’s Guide to the Galaxy exhibition (it’s always fun to see something related to h2g2 :)).

My trip to London wasn’t a purely touristic one, so in addition to the usual sightseeing and meeting different people I also got to do some real coding and debugging. The results are not bad — more than ten patches for various fb-related applications and libraries, including fixes for vesafb-tng, fbsplash and splashutils. I also got a chance to test vesafb-tng on a dual processor SMP-enabled machine. To my own surprise, it worked. And it worked perfectly. Despite my best attempts I was unable to crash the machine and reproduce any of the bugs that were reported by some people in the past. Well, I guess that for now vesafb-tng will be left ‘half-working’ on SMP.

Physics and Astronomy workshops

Michał Januszewski — Sat, 28 May 2005 17:58:09 +0000

I’m about to head off to Warsaw to take part in Physics and Astronomy workshops at the Warsaw University. I’ll be away from home (and thus from my dev box) for the next two weeks, so expect a halt in splashutils/vesafb-tng development and a longer than usual delay in my e-mail replies. I’ve just finished going through the big pile of unanswered mails in my inbox and replied to every single one of them that was still relevant. If you mailed me about something and you haven’t received a reply now, your message probably got lost/filtered by spamassasin/etc. If whatever you wanted isn’t outdated yet and won’t be after two weeks, feel free to resend your messages :)

During the workshop on physics I’ll be working on my General Relativity simulation program that was started back in March. I realize I promised I would release the code ‘as soon as the clean-ups are complete’, but unfortunately the development took a little different path than I anticipated and I wasn’t able to hold up my promise. Still, I certainly hope that after a full week devoted to the program’s development, it will be ready for getting it out to the public and I’ll keep my word after all (with a little 3-month delay added to it ;)).