# [solved] after kernel upgrade fb modes disappeared

## musv

Hi there, 

I just upgraded on my notebook from kernel-3.6.6 to kernel-3.9.0. The kernel config for the framebuffer stuff is completely the same. 

```
Device Drivers  --->

    <*> Connector - unified userspace <-> kernelspace linker  --->

    Graphics support  --->

        [*] Support for frame buffer devices  --->

            [*]   Enable firmware EDID

            <*>   Userspace VESA VGA graphics support
```

kernel-3.9.0

```
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/bzImage-390 root=/dev/sda4 ro video=uvesafb:ywrap,mtrr:3,1200x800-32@60 softlevel=lan acpi_enforce_resources=lax CONSOLE=/dev/tty1
```

```
U:1024x768p-75
```

kernel-3.6.6

```
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/bzImage-366 root=/dev/sda4 ro video=uvesafb:ywrap,mtrr:3,1200x800-32@60 softlevel=lan acpi_enforce_resources=lax CONSOLE=/dev/tty1

[    0.674036] uvesafb: NVIDIA Corporation, MCP79 Board - mcp79-pm, Chip Rev   , OEM: NVIDIA, VBE v3.0

[    0.707861] uvesafb: protected mode interface info at c000:d110

[    0.707876] uvesafb: pmi: set display start = c00cd173, set palette = c00cd1ce

[    0.707888] uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da 

[    0.772370] uvesafb: VBIOS/hardware doesn't support DDC transfers

[    0.772382] uvesafb: no monitor limits have been set, default refresh rate will be used

[    0.772720] uvesafb: scrolling: ywrap using protected mode interface, yres_virtual=1600

[    1.157282] uvesafb: framebuffer at 0xc5000000, mapped to 0xf8080000, using 8000k, total 14336k
```

```
U:1280x800p-60

V:1024x768p-85

V:1024x768p-75

V:1024x768p-70

V:1024x768p-60

V:1024x768i-43

V:800x600p-85

V:800x600p-75

V:800x600p-72

V:800x600p-60

V:800x600p-56

V:640x480p-85

V:640x480p-75

V:640x480p-72

V:640x480p-60

V:640x400p-85

U:1280x720p-59

U:768x480p-60

U:1280x800p-60

U:320x240p-60

U:320x400p-59

U:320x200p-59

U:1024x768p-60

U:800x600p-59

U:640x480p-60

U:640x400p-59
```

What's wrong here? Why doesn't the kernel respect the uvesafb-driver anymore?

Note: I tried also vesa instead of uvesafb, but I get only 1024x768 too.Last edited by musv on Sat May 18, 2013 10:55 am; edited 1 time in total

----------

## Bones McCracker

Are you using nvidia-drivers?

----------

## musv

Yes, I'm using nvidia-drivers - but only for X. I had compiled uvesafb support into the kernel and was calling that via boot command line. I haven't activated any splash stuff. 

So, the only thing I can do is wait, that nvidia fixes that issue?

----------

## Bones McCracker

I don't know.  I just thought it might be useful to know there are some (apparently recent) nividia-related issues with framebuffers.  I think concurrently the way the kernel handles framebuffers has changed.  I too see only one video mode in /sys.  Maybe that's being automatically selected as the "best" mode that's supported by the bios, the video card, the monitor, and the framebuffer.  I notice in your case uvesafb is complaining about not being able to get DDC.  Maybe there's a way to export the DDC to a datafile, and specify the datafile in your uvesafb portion of the command line.  (I don't use uvesafb).

----------

## musv

 *BoneKracker wrote:*   

> I notice in your case uvesafb is complaining about not being able to get DDC. 

 

But that was the case with kernel 3.6.6. In 3.9.0 there's no complaining about anything (and no fb modes).

 *BoneKracker wrote:*   

> I don't use uvesafb.

 

It's not a big difference to plain vesa. The difference is the format of the parameters. In uvesafb it's nice to specify the fb mode with the resolution and not with a vga mode, what you have to find in a table first.

----------

## Gusar

There is nothing for nvidia to fix here, they have nothing to do with uvesafb. Their driver only handles X. If uvesafb works differently in the new kernel, then that's where the issue is. Or maybe not in the kernel, but in the v86d daemon or the way it interfaces with the kernel.

Also, the difference between vesafb and uvesafb is more than just parameters. vesafb is completely in the kernel, uvesafb executes a lot in userspace. That's the point of it, to move stuff into userspace.

----------

## musv

Ok, but I've tried both vesa and uvesafb driver. And with both drivers the fb modes are disappered. There are now to chances:

With the kernel update I lost in some place an option, which provided the fb modes. OR

They have changed something in the kernel code, which leaded into the situation, that only one fb mode is shown.

----------

## musv

Got it!   :Twisted Evil: 

Ok, for the solution it took me some investigation. First I found this thread and  bug #196848. This remembered me to my problem with firefox and seamonkey (thread and bug #461694). 

Rebuilt kernel only with vesafb and deactivated edid support: didn't help

Rebuilt kernel with uvesafb and rebuilt v86d with x86emu: didn't help. The fb-console disappeared completely.

cleaned kernel (make clean), rebuilt kernel with uvesafb, klibc and v86d: worked  :Twisted Evil:  

The solution is simple: gcc-4.7.[-3] seems to be extremely broken on x86. Compiling firefox and seamonkey gave me internal compiler errors. And the kernel lost it's fb modes. Recompiling the needed components with gcc-4.6.4 brought the desired behaviour back.

Ah, it's not necessary to compile uvesafb as a module. It always worked for me fixed compiled into the kernel.

----------

