On 2/8/06, <a href="mailto:olafBuddenhagen@gmx.net">olafBuddenhagen@gmx.net</a> <<a href="mailto:olafBuddenhagen@gmx.net">olafBuddenhagen@gmx.net</a>> wrote:<div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi, > > The question isn't about moving all of the "X drivers" into kernel, > > just about not poking around hardware directly, which I think > > everyone agrees is a really bad idea. > > they poke around by mmap()ing the video card and writing to memory - > you can do this as root with lots of things. you need to have ROOT > privelidges to do it though. the kernel cannto protect the registers > unless it KNOWS what they mean and how they work - for that nvidia and > ati and others will need to publish all their specs openly. if the > kernel doesnt know what they mean - how is it to know somehting is a > good or bad thing to do - and when? at the end of the day x is working > with the gfx harward much like the kernel would - but form userspace > instead, so it can segv. it basically expects to be the only thing > fiddling with the gfx hw - within limits. like the kernel does with > other hw (but the kernel ENFORCES such limits). until 1. gfx makers go > open on specs so this can be implemented, I think there is some misunderstanding here. The idea is *not* to have the kernel put limits what kind of hardware access the userspace drivers are allowed to do, using perfect knowledge of the hardware to decide what is safe and what is not. The idea is rather for the kernel to do the graphics hardware access *itself*, the userspace driver only telling what operation it wants performed. This doesn't require any more knowledge about the hardware than doing the same access in userspace directly. The difference is that the kernel driver can ensure that only known safe operations can be invoked. Thus, it's actually a great advantage in case of incomplete specs. > and 2. x and kernel coders sit down and work out how exactly to put it > ALL in the kernel As it turns out, "it ALL" isn't really that much. A typical KGI driver (with accelaration support) is only a few kB -- not more than other typical drivers. There is nothing particularily complex about graphics hardware access. What makes graphics drivers complex is the transformation of abstract operations into specific commands that put the accelerator(s) to (efficiently) perform the desired operation. We all seem to agree that this part should (and can) be left in userspace. (Preferably in a generic library, which can be used both by the X server and by other interested parties.) > (which would work only for linux btw - u'd need differnet drivers for > bsd, etc. etc. etc.), That's not necessarily true. In KGI, the board-specific driver modules are actually system independant. It's in fact *more* portable than the current situation, with kernel specific DRM drivers. Of course, the interface for graphics hardware access needs to be hooked into the kernel in a system specific fashion. Note however that hooking it into the kernel requires *less* work than providing all the necessary hooks for userspace drivers -- just look at the thread about PCI access. BTW, the FreeBSD variant of KGI presently is actually more advanced than the Linux implementation... :-) -antrik- _______________________________________________ xorg mailing list <a href="mailto:xorg@lists.freedesktop.org">xorg@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</a> </blockquote></div> Can we have something we can play with and actually understand? I have been reinventing things just to understand them. Its like trying starting with a terminal emulator first so i can understand how the linux kernel works. -- SMS Global Ltd Short Message Service For Seafarers