Kernel support for graphics cards

[Rogelio Serrano]

On 2/8/06, olafBuddenhagen at gmx.net <olafBuddenhagen at gmx.net> wrote:
>
> 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
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20060208/fed6291c/attachment.html>