Graphics Driver Frameworks and Security

[olafBuddenhagen at gmx.net]

Hi,

On Fri, May 26, 2006 at 09:08:15AM +0200, Michel Dänzer wrote:

> When I tried Xggi a couple of years ago, it didn't seem to provide any
> advantage over what I was dealing with, so I quickly lost interest.

A new internal infrastructure seldom immediately offers direct
advantages; I don't think it's reasonable to expect that. Still it's
useful to move to an infrastructure that is more robust and elegant;
that helps avoiding lots of trouble in the long run.

> Maybe I should clarify what I mean by proof of concept: a working
> implementation with top-to-bottom acceleration and otherwise current
> features on at least one platform.

Yeah, you are not the first one to suggest this. I agree that it would
be desirable, but I'm not sure it can be achieved. For one, having it
fully working even on one platform means most of the infrastructure
already has to be implemented.

Moreover, focusing all effort on a single platform means either all the
work needs to be done by a single person, or all developers need to
agree on a common reference platform. Both seem problematic for a
volunteer project. Implementing a bunch of imperfect but mostly working
drivers, like KGI did in the past, seems much more feasible...

> We already have plenty of cool meta X servers that run on top of
> another X server. :)

Well, but not one running on various targets (including nested X,
fbdev/directfb, wsfb, svgalib, quartz, directx, file, aalib...) without
any changes to the actual X (protocol) server. I think this backend
abstraction makes XGGI interesting by itself even regardless of KGI. 

It seems to me that quite a lot of X developers do consider cleanly
separating the backends from the server the right way to go. XGGI does
exactly that, and yet there is so little interest in it. Why? I don't
get it.

> As for problems, I know from experience that it's hard to define a
> kernel<->userspace interface that is both fast and secure.

I keep hearing that demur, yet DRM does precisely that for the most
performance critical stuff. Why would it be then a problem for the less
critical rest of the driver infrastructure?...

-antrik-