Re: [AD] Framebuffer resolution problems

[Grzegorz Adam Hankiewicz <gradha@xxxxxxxxxx>]

On 2005-05-04, Milan Mimica <milan.mimica1@xxxxxxxxxx> wrote:
> I used vesafb driver and everything was working fine, at least the
> last time I tried it (some latest WIP's). There were some issues,
> but I think they where driver related, like inability to properly
> change resolution and color depth.

Standard vesa framebuffers aren't able to change resolution because
resolution switching is performed through BIOS (I think) so it can
be done only during boot up.  Or something like that. IIRC there
is an experimental vesa driver allowing resolution changes after
boot sequence. Ah, you could try using SuperVESAfb:

  http://www.rastersoft.com/supervesafb_en.html

Oh, look, for 2.6.x kernels there is vesafb-ng:

  http://dev.gentoo.org/~spock/projects/vesafb-tng

Interestingly that says it works with nvidia X drivers...

> How come that a fb kernel API is so bad designed?

Well, during 2.4.x kernel times (or maybe even 2.2.x?) Shawn proposed
a kernel framebuffer patch to allow something like vsync() polling
inside the kernel. Without this, you cannot reliably do page flipping
because the scheduler may interrupt you and your game will probably
miss the vertical retrace (remember, crappy 10ms slice resolution
in most cases).

But this wasn't included because it was a security problem: any
user land application could poll infinitely and effectively hang
(or at least terribly slow down) machine, because the kernel
cannot interrupt itself (one of the "features" of 2.6.x is that
most uninterruptable kernel operations are shorter than on 2.4.x,
thus lagging less for multimedia applications). Well, the real
reason this wasn't implemented was slightly different, but that's
mainly the idea.

And there are other hardware acceleration issues too, or how to deal
with unicode consoels, or... I don't know. FB looked so beautiful
ages ago, and now it seems nobody wants it anymore because of the
can of worms it opened. And sane people just tend to work on top
of XFree86 or X.org now.

I guess these and other resons prompted people to start
http://www.directfb.org/. One of the problems of framebuffers is that
they cannot really use hardware acceleration. Hardware acceleration
works in a similar way to 3d acceleration. You don't have a pipeline,
but you try to perform as much high level operations as you can
(like blit this sprite rotated with alpha blending). Instead,
"stock" framebuffer virtualizes video memory as a big array, so
the only thing you can do is to plot/read pixels. And that's not
going to be accelerated very much.

All in all, it seems writing single user real time software doesn't
fit very well with generic multiuser OSes. Don't dismiss so easily
other people's work (unless you can correct them, of course).