Using fbdev (Re: [PATCH] fbdev: Add an fbdev compositor backend using pixman and evdev)

[Pekka Paalanen]

On Sun, 20 Jan 2013 06:05:58 +0000 (UTC)
Nerdopolis <bluescreen_avenger at verizon.net> wrote:

> Nerdopolis <bluescreen_avenger at ...> writes:
> 
> 
> > I see.
> > The only concern is that can the vesafb fbdev device resolution be changed in
> > runtime if its too small?

No. See
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/fb/vesafb.txt;hb=HEAD

> > Otherwise users are going to have to manually set the framebuffer size by
> > correcting the correct vga= argument with grub if they get the wrong size.

Yes.

vesafb is basically a fallback driver, which just needs to load on
boot, and loading a real DRM driver will then replace it. See e.g. the
Nouveau documentation on boot-time fb drivers:
http://nouveau.freedesktop.org/wiki/KernelModeSetting

Notice, how hand-off from vesafb should work, but from uvesafb not.

> > I think that would mean there is an issue with Ubuntu, (I would assume it's
> > Casper as it runs and configures the live environment during runtime). 
> > And that this would need to be fixed in order for fbdev-backended Weston to
> > work on VirtualBox.
> > 
> > I tested it on a default Kubuntu 12.10 Live ISO, and when it booted, 
> > there was no /dev/fb0 as well.
> > 
> > As this is an issue within a distribution, either a workaround will have to be
> > provided, or we'll have to wait for the distribution to fix this issue.
> > 
> > I don't know enough about what could be causing the issue that the same ISO
> > when booted as a Live CD does not have /dev/fb0, but when its installed 
> > it has /dev/fb0.
> > 
> To answer my own questions after more research, it seems that the ability 
> to change the resolution depends on the framebuffer driver.

Yes, very much. AFAIK, efifb cannot change the resolution, either.

> It seems that vesafb can not change the resolution without a reboot, however
> a driver called uvesafb can. It seems though that although some distros
> provide it by default, they might not include the userspace 'v86d' program 
> by default that uvesafb requires. (I tested on Ubuntu)

Documented in
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/fb/uvesafb.txt;hb=HEAD

> In order to use uvesafb:
> modprobe uvesafb mode_option=1024x768-32
> 
> and from there the mode can be set again by echoing one of the modes listed in
> /sys/devices/platform/uvesafb.0/graphics/fb0/modes  into
> /sys/devices/platform/uvesafb.0/graphics/fb0/mode

Is this not more work than just defining, say, vga=ask on the kernel
command line? Or rather, have your bootloader present a range of
default modes to choose from, by appending the corresponding vga=
argument to the kernel?

> ...So in the case that a system doesn't create an fbdev by default, and the user
> is using the framebuffer backend, could weston-launch possibly do this

IMO, this is definitely not weston-launch's or weston's job. However,
X is a precedent of some different thinking. I believe the kernel or
init system should load the right drivers automatically, not leave it
for some random user space applications to second-guess the system
configuration.

There are also a bunch of hardware specific fb drivers, that might be
more featureful than vesafb, if there is no DRM driver. However, fb
drivers may conflict with user mode setting X drivers. I don't know the
details today, but just mentioning it, in case you plan to include X.

As for your differences between live vs. installed distribution, it is
the distribution's (or yours, since you configure the images) choice to
have it behave like that. Maybe it loads a different set of drivers, if
the live image wants to stay as hardware independent as possible.
Comparing the kernel logs should tell you what gets loaded.

All Gentoo live cds have always had an fb unless explicitly told not
to, from what I have used, IIRC.


Thanks,
pq