Usplash doesn't work on systems without vesa framebuffer

[Loïc Minier]

Hi

usplash doesn't work on the armel imx51 babbage board; it seems usage of VESA is hardcoded, but the card isn't VESA capable. Currently we're using fb mode.

Bye

[Colin Watson (cjwatson)]

Shouldn't it be workable with the bogl backend?

[Matt Sealey (mwsealey)]

Indeed it should work somehow but we have exactly the same problem on powerpc too (Ubuntu, SuSE and Fedora all hit the same problems) - usplash really wants to hook into a vesa framebuffer for some reason and I can't imagine any that would require anything but the standard linux framebuffer abstraction and ioctls off the top of my head.

Is there any reason usplash requires a vesa mode, vga= arguments or something or can't it just find a framebuffer that's already initialized (on x86 they may not be built in but on armel and powerpc they 99.9% of the time are always builtins to the default kernel)?

[Paul Larson (pwlars)]

Originally reported on imx51, but it appears that this bug is not specific to Ubuntu on armel, so the armel tag has been removed. If something changes, and you later believe that this bug only happens on armel, please add the armel tag again.

[David Sugar (dyfet-deactivatedaccount)]

In debian/rules:

ifeq ($(DEB_HOST_ARCH), $(findstring $(DEB_HOST_ARCH),i386 amd64 lpia))
 BACKEND = "BACKEND=svga"
else
 BACKEND =
endif

It looks like i386, amd64 and lpia all use the svgalib backend, and that does initialize svgalib only for VESA. svgalib can however also be set to a number of very specific chipset configs...

I would think this means everything else (including arm) already uses the bogl backend directly with native framebuffer support, and NOT svgalib or vesa, since if BACKEND is not set, the Makefile defaults to bogl.

Finally, usplash seems to include it's own local copies of bogl and svgalib and statically links them into the binary based on the backend selected. Is the version of bogl valid for current kernels?

[Oliver Grawert (ogra)]

the problem on imx51 is fixed with a workaround in initramfs now, it was caused by the fact that the mxcfb framebuffer driver can not display anything but the one resolution specified on the cmdline (see Bug: #420555 for details). usplash defaults to use the lowest resolution theme it has if no usplash.conf is specified though.
that resulted in jaunty (where mxcfb came with a default resolution of 800x600 hardcoded in the module and did not need a cmdline option) in the situation that usplash tried to display 640x480 on the 800x600 framebuffer.
in karmic where only DVI output is supported and no default resolution is set in the module at all (i.e. the video= cmdline arg is needed, else nothing is displayed at all) we use video=mxcfb:1024x768@60 on the cmdline (under the assumption that all monitors having DVI input can display such a resolution), so here it results in usplash trying to display 640x480 on a 1024x768 screen with a driver that doesnt manage to do upscaling of such a picture.

[Oliver Grawert (ogra)]

definately not a usplash bug, closing as invalid