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
v86dusing 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_Gx53KttbTgfZ4dktuoismcwith 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.
Why don’t you use KMS?
I tried and it seemed to work quite fine until I started X and began to type in a urxvt window, which caused a complete screen corruption. I haven’t had the time to figure this out yet, so I decided to stick to uvesafb for now. Perhaps this problem can be fixed by a kernel upgrade.
I’ve been using KMS on an eee701 with a 2.6.30rc kernel (zen-sources IIRC).
The corruption bugs/lockups seem to have all gone away now. Just to make sure, I had it running Nexuiz for an hour. It wasn’t playable, obviously, but I didn’t see a single graphical glitch in it either.
Hi Michał,
Please, I beg of you, do not publish such information for Intel users out there.
The proper way to get a console now is to use KMS+fbcon like Mike suggested. (u)vesafb has been a constant source of nightmares for users (and me) in the past few months and in 9 out of 10 bugs, disabling all framebuffer drivers fixed one or more bugs.
Please, if you have any issues with Intel drivers, file a bug report in FreeDesktop’s bugzilla and add me as a CC on the bug so I can keep track of issues. Upstream has been working really really hard on fixing bugs, there might be a few left but the last few .30 RCs have been been very solid for a lot of Intel hardware owners.
Thanks
Hi Michal, I have a 1000HE and am seeking a 1024×600 framebuffer console and appreciate the information. Would you mind doing a write up on the proper way to use KMS+fbcon coming from 2.6.29-gentoo-r5?
Rémi,
The purpose of my post was not to advocate the use of uvesafb on Intel hardware, but to show how to use uvesafb in case the BIOS needs to be patched. The Intel cards just provide a good example. Perhaps I should have made the post a little less Intel-centric, but then again, I wanted to show a specific example, not just some general theoretical discussion.
That KMS is the proper way to get a working framebuffer is I think pretty obvious (why would anyone use a generic driver, such as (u)vesafb, when a more featureful hardware-specific driver is available?). That being said, I still think that the setup I described in my blog post provides a viable temporary alternative in case KMS doesn’t work for whatever reason. Getting bugs fixed is surely the way to go, but sometimes one needs a quick workaround in the meantime.