On Sat, May 31, 2008 at 08:08:54AM +0200, Denis Oliver Kropp wrote: <skipped>
> It depends on what you need in kernel space. Have a look at the SH7722 > kernel > module. I'm not sure if the benefits of DRI would be that big to compensate > for > the overhead or limitations. E.g. this driver manages a self running DMA > queue, > where in the ideal case you never have to do any system call, but just > append data > to the DMA buffer from user space. > > http://git.directfb.org/?p=core/DirectFB.git;a=blob;f=gfxdrivers/sh7722/kernel-module/sh7722gfx.c > > This driver handles different interrupt sources, provides DMA for the > accelerator > as mentioned above and implements a minor portion of JPEG encoding and > decoding with > the rest done in user space. 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. 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. Friendly, Sven Luther _______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users