Re: OpenGL-based framebuffer concepts

[Marko M]

Sure it is. I mean, it uses only VESA (extended VGA) registers and
doesn't know anything about present bliters, backend scalers or
similar hw features, AFAIK.

I think DirectFB guy have right approach, only they do it from user
space. fbdev should be capable of detecting present chip(s) and load
appropriate (acceleration) module, which describes hardware more
precisely.

If there is no specific (fbdev) driver module for your gfx then
everything should work with generic (VESA) one, though it would be
somewhat slower.

On 6/1/06, Jan Engelhardt <jengelh@xxxxxxxxxxxxxxx> wrote:
> >> As long as I can continue to use 80x25 or any of the "pure text modes"
> >> (vga=scan boot option says more) without loading any FB/DRM, I am satisfied
> >
> >Jan, I don't plan on forcing fbdev/DRM on anyone. My work is going to leave
> >vgacon alone, and if my work at making DRM and FBdev cooperate goes as
> >planned, those two will remain independant, though part of my work aims at
> >having fbdev provide all 2D graphics acceleration for DRM while DRM handles
> >the 3D stuff via the Mesa libraries or similar.
> >
> That sounds acceptable.
>
> But current vesafb is slower, noticable with scrolling as in `ls -Rl /`.
> Does it lack 2D acceleration?
>
>
> Jan Engelhardt
> --
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/