bcm2708 frame buffer does not work without fbcon

[fabled]

It seems that bcm2708_fb expects to to get a bcm2708_fb_set_par() callback to allocate the memory for the frame buffer. This is normally true as fbcon driver does this.

However, I'm trying to build a system without 'fbcon' to make sure no kernel printk()s, blinking cursor, or anything else is shown before a boot splash image is shown, and finally a native omx application start.

In practice this means that any application opening fb0 and trying to mmap it fails, because there's no frame buffer memory allocated.

After once changing the resolution using 'fbset' things start to work again as that forces a call to fb_set_par() and memory gets allocated.

Would it be possible to fix the driver to internally call fb_set_par() or similar to do allocation even without fbcon.

[popcornmix]

Have you tried calling fb_set_par? Did it work satisfactorily?

[fabled]

Not yet, have not had time to rebuild kernel. What would the proper place? As last thing of bcm2708_fb_register() ?

[fabled]

I'll try something like:

diff --git a/drivers/video/bcm2708_fb.c b/drivers/video/bcm2708_fb.c
index b3b1e04..e791b62 100644
--- a/drivers/video/bcm2708_fb.c
+++ b/drivers/video/bcm2708_fb.c
@@ -625,6 +625,7 @@ static int bcm2708_fb_register(struct bcm2708_fb *fb)
         */

        fb_set_var(&fb->fb, &fb->fb.var);
+       bcm2708_fb_set_par(&fb->fb);

        print_debug("BCM2708FB: registering framebuffer (%dx%d@%d) (%d)\n", fbwidth
                fbheight, fbdepth, fbswap);

[popcornmix]

I tried your patch. It does cause the "rainbow" splashscreen to be removed (this is with CONFIG_FRAMEBUFFER_CONSOLE=n).
startx runs okay. fbi gives:
ioctl VT_GETSTATE: Inappropriate ioctl for device (not a linux console?)

There is the question of whether allocating the memory when no fb console is required is a good thing.
What's the problem with calling fbset to allocate the framebuffer memory?

[fabled]

No other driver works like that. And this means no standard fb program will likely work. I would have to patch the framebuffer software to do that. Or apply hacks in the initramfs scripts -- in so early stage that it might not be possible in a simple way.

I run my RPi with 'disable_splashscreen' so I don't get the rainbow. But if one wants to keep it, the frame buffer driver should be able to initialize the memory so that it does not erase the contents.

As side note, if fbcon is built, it resets the display anyway one ending up with the rainbow image deleted.

As reference, GRUB seems to have a mechanism to do this:
https://www.gnu.org/software/grub/manual/html_node/gfxpayload.html

[fabled]

And finally, if one does not want frame buffer memory overhead, one should say no to frame buffer driver. Then you don't get anything on screen expect with the native OMX stuff.

[fabled]

Another problem with fbset is that kernel filters out fbset calls to same mode. So you'd need to change the mode first to alternative value, and then back to original.

[popcornmix]

Assuming the added bcm2708_fb_set_par causes no issues with the default (with fbcon enabled) kernel, then I have no objections.
It would be useful if you can confirm that line does fix your current issue.

[fabled]

I can confirm that it fixes my issues.

I build fbcon as module - I also tested the case when fbcon is loaded as module, and it also works as before.

Please consider applying that patch. Thanks.

[popcornmix]

Yes, I've tested and haven't seen any problems.
I'll add the patch in next firmware update.

[popcornmix]

It's added to 3.17.y tree and BRANCH=next firmware.
Will add to 3.12.y tree if no one complains.

[popcornmix]

Added to 3.12 and in latest rpi-update firmware. Please test.

[popcornmix]

This should be present in recent firmware. Please reopen if there is still an issue.