XFree86 DRI on NetBSD 28
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!"
Can anyone then tell me... (Score:3, Insightful)
Re:Can anyone then tell me... (Score:3, Informative)
going to guarantee anything.
Basically someone that knows something about OpenBSD needs to step up and start digging in. Eric Anholt did some fantastic work in abstracting some of the code, so it really wasn't tough to make it work on NetBSD.
- Erik
Re:Can anyone then tell me... (Score:2, Interesting)
3D on OpenBSD? Mmmmmmmm.
why (Score:1)
*nix Support (Score:2, Insightful)
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.
Re:*nix Support (Score:5, Informative)
Although there is a port of the FreeBSD nvidia drivers to NetBSD... Lemme dig up the uri...
Ah, here it is:
NVidia drivers on NetBSD [netbsd-fr.org]
Have fun!
Unified UNIX drivers (Score:5, Interesting)
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.
Re:Unified UNIX drivers (Score:2)
Well, apache is not the be-all end-all of webserving. There are lots of webservers available for the *nix platform that are not based on or related to apache. One notable exception is roxen [roxen.com], although the development activity is a bit shady at the moment. Check freshmeat for more webservers. There are many.
Re:Unified UNIX drivers (Score:4, Insightful)
Re:Unified UNIX drivers (Score:2)
Drink tea. Black.
> There's a standard desktop and graphics toolkit >for UNIX already. They're called CDE and Motif. >Ever heard of them? I didn't think so.
Sure, but theyre not standard across to Win32 and OSX. There might be emulators that run on TOP, but that defeats my analogy.
QT wraps the windowing system functions, from Win32 OSX and X11, presenting a unified and simple bunch of tools. I'm not asking you to love it, just t
Re:Unified UNIX drivers (Score:2)
Re:This already exists. (Score:4, Informative)
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.
Re:This already exists. (Score:2)
Interesting stuff.
Part of opensource developer psychology is exclusivity. Belonging to for instance the FreeBSD or Debian linux camp, and not developing something that contributes to the other camps especially the commercial OSes like Solaris. I think this would hinder the unified drivers. And like you said its a very different environment, its also an added layer, and what attracts developers to system/kernel/driver programming in the first place is the low level.
But I think theres a threshold bey
Re:I'll do it next week! (Score:1)