# Re: vga16fb: blank screen with Intel GM965/GL960 on HP 2510p notebook

- From: Frans Pop \<hidden\>
- Date: 2008-03-23 01:26:49 
- List: linux-fbdev
- Page: https://ratatoskr.run/linux-fbdev/2008/03/13458030
- Thread: https://ratatoskr.run/linux-fbdev/2008/03/13458023/t.md

```text
On Sunday 23 March 2008, Martin Michlmayr wrote:
> Anyway, you didn't answer my original question which was why the
> text-based d-i loads vga16fb.

The installer only modprobes vga16fb if vesafb is not active (well, it 
actually does modprobe vga16fb when vesafb and/or fbcon are compiled in 
[1], but that's the general idea), but that's not the problem here.

The kernel config is:
CONFIG_FB_VGA16=m
CONFIG_FB_VESA=y
CONFIG_VGA_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y

So VESA is compiled in.
The problem here is that /proc/fb doesn't show VESA when the regular 
installer is booted, AFAICT because we boot with vga=normal. vesafb seems 
to only be actually activated by the kernel during boot if you boot with a 
vga mode that requires it.

The installer then runs its init scripts, specifically
/lib/debian-installer-startup.d/S40framebuffer-module-linux-x86, and that 
ends up loading vga16fb because loading vesafb fails (as it's compiled in).
And thus you end up with vga16fb, basically because it's the only 
framebuffer available _despite_ the fact that vesafb is compiled in...

Is there is a way to activate vesafb post-boot even when the system was 
booted with vga=normal? If there is this could probably be avoided.

Also, does anyone know a way to test whether fbcon is compiled in or not?
We can of course test if fbcon is available as a module and assume it's 
compiled in if not, but that's not a proper test that it _is_ present.

Cheers,
FJP

[1] I've got a patch to fix that in D-I's rootskel.
```

## Attachments

- [(unnamed)](https://ratatoskr.run/linux-fbdev/2008/03/13458030/attachment/0) (text/plain, 182 bytes)