[Splashy-devel] FrameBuffer detection

[Jacobo221]

(This mail actually comes as a reply to the splashy-users maillist. Since it is devel stuff I'm posting in splashy-devel instead. The conversation from splashy-users is pasted at the end of this mail)

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 to remove the need of setting kernel parameters. 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.

I believe I didn't make my opinon clear in one point:

I believe /proc/fb should be considered valid _whenever_ it contains data, _even_ if_ it contains "unknown". I was just proposing a way of detecting this two special cases.

The thing is that if the driver leaves the FB configured it is because there is a reason. Otherwise t would unset it. Ok, these are default configurations, but still, there must be a reason.

In the Mac case, given that it is a mac and so that many people will be using it, it is better to risk in positive thn in negative.

Oh, in the Atari case I was a bit wrong. "Unknown Extern" doesn't mean "Unknwon card" actually. It just means (or that's what I now think after reading some more of the code) that, while using a known card, it is using an extern display and so not sure about its properties. So it should be safe to use it anyway.

Finally, about the Permedia driver, if id is set to "" it will just not work (just checked), so that's fine too.

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

To optimise on splashy-server side, this id value can be gathered from
ioctl through the FBIOGET_FSCREENINFO request command (#include <sys/ioctl.h>).

About removing the need for vga= kernel parameter, I haven't looked into that
but I'm sure it's simply by using ioctl with the FBIOPUT_VSCREENINFO
command, since the resolution, offset, etc are set in the
fb_var_screeninfo struct (notice _var_, not _fix_).
Since there is no way (or at least none I've seen) to detect the maximum resolution, I think defaulting to the theme images' size should be enough. And, of course, support a parameter in /etc/splashy/config.xml to define the resolution to use.

Also, notice that I know nothing about BSD and others :-(

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.