Slashdot Mirror
XFree86 DRI on NetBSD
Dan writes "Erik Reid has been working on adding DRI support for NetBSD. Direct Rendering Infrastructure, also known as the DRI Project, is a framework for allowing direct access to graphics hardware in a safe and efficient manner. Some of Erik's work has been imported into XFree86 4.3.0 which is now in xsrc tree. He has subsequently put together a fairly large patch which compiles and works on his NetBSD/i386 1.6P system with a matrox g450. Try out the patch and give him some feedback!"
...what if anything this might mean for getting DRI on OpenBSD? Thanks.
Now give me nVidia and ATI drivers that have all the support/features under linux/BSD that you have under windows THEN I'll be exited.
Patrick Havens (Mr. 573333 to you.) Graphic Artist / Coder / Father / Journeler
Just like QT unifies the different window systems and opengl unifies various graphic systems, I think we seriously need a unified system of drivers for all *nix including Linux, BSD, Solaris if Sun sees the potential, AIX ditto, Beos and darwin. Newer OSes like Plan9 would use the infrastructure and gain support of ALL the hardware.
I'm not too sure how we could cope with not adding additional code layers slowing things down.. perhaps an M4-based system that changes the right functions in the driver code, and removes or replaces OS-specific functionality depending on the output of uname. Such a unified system would attract hardware designers who would release their driver code according to this structure to support multiple OSes, and Free Software would be the big winner here.
Ive had to move from FreeBSD to Linux to Solaris now, due to the inherent lack of tokenring drivers, or its stability. FreeBSD had only one TR supported, in alpha, and it crashed. I wish I had the option of using NetBSD. Linux has a slew of TR supposedly supported but there are some bugs in receive buffers of TR code when using it with ethernet and ipfilter. I tried tuning many things, even tried to implement my own receive buffer with additional checks. It was a bit complicated for me.
The various unixen have a collection of kernel hooks that could be used in drivers. A simple large table could be made for hooks that are similar, showing differences in naming, arguments and limitations of buffers etc. Other pointer hooks then could be made to represent and encapsulate these hooks, also encapsulating additional procedures that need to be run before/after each hook on specific systems.
Non-equivalent hooks are more difficult to use, some might need additional programming on some systems while other systems would have part of that functionality built in. For this, we gotta build trees of functionality of each driver type, say networking, graphic, input etc, for each system making a 3d graph of the functionality and working with the weaknesses of some systems making it similar to the strengths of others, makin it easy to create encapsulating hooks.
The encapsulating hooks themselves could be either C functions, pointers, or M4 macros, which would be replaced with the code of the right system just before compile time. I would go with c pointers if theres NO resulting performance hit after being compiled with gcc -O2. If theres a resulting performance hit on ANY system, I'd say we're pretty much stuck with M4 which on some systems could become too complicated to be worth it.
Pulling out all drivers from the Linux code, and FreeBSD and sticking it all into the tree, and demonstrating its working would be the end of the first phase. Establishing a proper standards group, quite possibly with posix/ansi/someotherbody would complete the second phase. After that its all sit back and wait, and just like WDM in windows, hardware makers should re-release driver codes for a more unified platform.
Apart from a major boost to Net/OpenBSD, Plan9 and others, the Linux kernel might be lightened much from todays 30MB+. Yet another issue would be driver signing and security unless the whole driver structure is downloaded with the kernel sources of each OS.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
http://www.projectudi.org/ Or existed, it seems like it hasn't been updated in a while.
I did some work in this, interesting environment. All drivers are source compatible across all conforming environments. If the environments have the same C ABI (say, they're all x86) then the drivers are binary compatible. Caldera actually made this their native DDI for OpenUNIX 8. There are environments for OU8, Linux, and FreeBSD, and some drivers out there. One cool thing is that the environment handles MP. All your functions are guaranteed never to be interrupted. Downside is, it's a very different environment from what you're used to, and it takes a while to get your head around.
As an aside, RMS doesn't like the environment because it makes it easier to release binary only drivers. Not only does it insulate youfrom DDI differences between platforms, but also between Linux kernel updates.