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:

Related

7 Responses to “915resolution with built-in uvesafb”

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.

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.

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.

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?