Re: [directfb-dev] [directfb-users] DirectFB without FBDev

[Sven Luther <sven@powerlinux.fr>]

On Sat, May 31, 2008 at 08:29:52AM +0200, Denis Oliver Kropp wrote:
> Sven Luther wrote:
> >Yes, but given that the kernel already has 2 "graphical" subsystems, fbdev
> >an drm, the reticence of Linus to merge in the fbdev back then, and the
> >failure of the ggi/kgi project, i wonder if it makes sense to try to add
> >yet another system.
> 
> I wouldn't try to add another system either, but write small, specialized 
> and
> optimized kernel modules suited best for the way the hardware works to take 
> as
> most advantage as possible. The example shows that 600 lines of hardware 
> plus
> 200 lines of Linux code suffice in the SH7722 case.

The risk is ending with a bunch of different such kernel modules without
any unified kernel-userland interface, and it will end up in a mess,
just like the different powerpc embedded board support ended up with a
huge in-kernel mess which is beign fixed right now.

> >In my opinion, what would make sense would be to disucss with the fbdev
> >and drm/xorg folk, as well as the vendors out there, to obtain a single
> >unified "graphical" driver, on which fbdev and xorg/drm functionality
> >can be built, and which allows us to take advantage of the various
> >functionality of the graphic chips, and which is designed, not only for
> >high end desktop/workstation graphic cards, but also for embedded
> >chipsets.
> 
> A single unified solution would be nice, but it's always a trade off. For

Why should there be a tradeoff ? The kernel space part should expose the
functionality of the hardware, and there is not thousand of ways to do
this, and the needs of all the userland users of this are pretty much
the same, or at least similar.

> embedded chipsets there's a unified solution in user space as well as for
> desktops, while the former can be used for desktops with limitations and
> the latter can be used for embedded with overhead.
> 
User space is easy, its the kernel space which is the problem.

Friendly,

Sven Luther

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/