[Splashy-devel] Re: [Splashy-users] Re: Splashy 0.1.x and the future of bootsplashing

Jacobo221 jacobo221 at gmail.com
Sun Apr 2 22:22:20 UTC 2006


I have been doing some research on 2.6 kernel's sources about the fb detection, to avoid checking into the kernel's image and the ram device. And I believe I got to a solution.

The /proc/fb corresponds in kernel to the fix.id, a char[16] field in an
fb_fix_screeninfo struct, defined in include/linux/fb.h
As far as I could see nowhere in the kernel this field is for purposes
other than providing a short id-like description of the underlying
graphical card/driver. On the other hand, _all_ fb drivers (in
drivers/video/*) do provide such id. This is because leaving it
unassigned would segfault (random pointer, this is C), for example,
when reading /proc/fb, since /proc/fb is no more than a pointer to that
field afaics. The only place where the id was set to a "strange" value
is in drivers/video/pm2fb.c where it is set to "", but this is just a
default. When the exact card is known to the driver, it then sets it to
"TVP4020", "Permedia2" or "Permedia2v", depending on which card it is. So, ok, if the driver doesn't know the card it will be blank, but hey, if the driver doesn't know the card it chances are 95% won't work! ;-) Actually, if the card is unknown to the driver probably it disables fb, but I haven't read that far in that source, after all, that's a very small chance.

Conclusion: The following is an almost valid check

# Bourne shell code
test -n "`cat /proc/fb`" && echo "FB working"

I mean:
 - If /proc/fb exists, the kernel has fb support, though it can be unconfigured and, thus, not working
 - If /proc/fb is empty, inmho it is safe to assume fb is unusable
 - If /proc/fb contains anything, fb is almost surely usable (it may be a virtual fb, but hey, we shoudln't care about it, that's up to the user!)

There is a glitch: Similarily to Permedia's driver, atafb.c and macfb.c default to "Unknown Extern" and "Unknown/Unsupported built-in" respectively and then change this when the card is known. But what about when the card is not known? This is more worrying since /proc/fb will contain data while not really supporting fb. Actually in none of the two cases the fb is disabled, so it will allow writting to the fb (I guess) etc as if it did work, but simply display nothing. The only solution I could find to this is to grep for "Unknown" in /proc/fb.

This all seems to me like a very good approach to detect fb efficiently and hickish-less-ly ;-)

P.S.: My initial approach was to get a list of valid /proc/fb contents, which is totally useless as I could later see. In case someone wonders, just run (having kernel's sources in /usr/src/linux) the following in console:

egrep '(fix(\.|->)id.*\"|\.id[[:space:]]*=[[:space:]]*\")' -R /usr/src/linux/drivers/video/ | sed 's/.*\"\([^\"]*\)\".*/\1/'

The empty line corresponds to Permedia driver's id="" assignation.


> On 3/20/06, Joey Hess <joeyh at debian.org> wrote:
> > Luis M wrote:
> > > In order to allow the framebuffer to be started by the kernel at boot,
> > > vga=xxx is required. For 2.6.14 kernels and up, vesafb must be
> > > compiled-in, not as module, so, this makes things simpler for people
> > > who want an image at boot.
> >
> > Note that anything that requires prompting the user by default for
> > obscure vga=xxx values[1] won't be enabled by default in the installer.
> 
> Ok.
> 
> > FWIW, the Debian installer already knows when a basic framebuffer can be
> > used, since it uses this with bogl itself. It does this without vga
> > parameters though, in the vast majority of cases.
> 
> Good to know. I wonder if this is similar to what splashy-init does:
> test -z "$vga" &&
> 		  # Lilo (kernel docs) method
> 		  vga="$(silent -2 dd count=1 bs=2 skip=295165 if=/dev/mem |
> 		    silent -2 od -d - | head -n 1 | tr -s \  | cut -f 2 -d \ )"
> 		! silent test "$vga" -ge 769 -a "$vga" -le 799 &&
> 		  # Desperate detection
> 		  ! silent grep -E 'VESA|VGA' /proc/fb -q &&
> 			echo " - Kernel parameter vga= not set"
> 
> We could definitely add this to splashy itself and forget about
> telling users to add vga=xxx to their kernel paramters.
> 
> When splashy is added to initramfs though, the modules are loaded for
> you if we find vga= in cmdline (similar to what usplash does now). I
> guess that code can be refined as well.
> 
> > [1] Or that requires guessing at them in any way that's more likely to
> >     cause breakage than what we do now.
> 
> Thanks for your suggestions Joey. Will keep them in mind before
> allowing Splashy to go into Sid.



More information about the Splashy-devel mailing list