How about running X on top of something else?

> > > You can write an XFree86 driver within the current driver model
> > > that is built on top of something else like GGI.  Nobody has done
> > > it.  I even gave a personal invitation to do this to the GGI folks 
> > > years ago and they declined.
> > 
> > No, that's NOT possible. You can't prevent XFree86 to access
> > hardware-resource like pci and input stuff.
> > There was a try to write a GGI driver for XFree86, but it came out
> > this is impossible, because of that. Sorry.
> 
> Impossible? No, definately not. Given that GGI was supposed to be a 
> General Graphics Interface, it should have absolutely no bearing on 
> whether XFree86 wants to handle input or PCI enumeration.

You don't see the actual problem, because you only understand
what GGI is... from a very roughly point of view.

GGI is designed to run everywhere, that can act as an display - even
virtual displays such as the memory (i.e. for backbuffering,
shared memory...) and tcp-displays, which forwards the output to
remote displays (in the following called as 'remote target').

Anyway, whatever target is used, the target uses the API of the graphics
backend for display output, which means, the target has the control.

Imagine the situation: There's a GGI driver for XFree86 and you use
the fbdev target on your console (fbdev driver is already loaded).
XFree86 scans the PCI bus for the card to get control over it

before let act the GGI driver. Then the GGI driver
sets up the graphic mode => the fbdev target uses fbdev's ioctl for this.
Past this point, fbdev and XFree86 comes into a hw-resource access
conflict => BOOM!

That's just one situation. Using GGI's svgalib target in that situation
is even worse!

And btw: Is scanning the local PCI bus really necessary when the memory
target or even a remote target is used?

IMO, there's a major design flaw in XFree86!! Sorry.

If you don't believe me, then ask the XDarwin folk, why they write their
own X server instead of a _native_ XFree86 driver using
Apple's Quartz/OpenGL/whatever API _directly_!

Ok, they share a bunch of code, but...

> If the input layers in GGI are too closely tied to the graphics layers,
> then you have a serious design problem in GGI. Graphics should
> be useable as a completelyl separate entity.

Yes, GGI can do graphics with NO input. Almost all targets have a
-noinput option for this.

The whole input stuff is handled in a separte input library - libgii
(See http://www.ggi-project.org/ for more information about it).

Imagine, a GGI application runs under X using the X-target - where
do you think the input comes from, when it weren't interacting with
libgii's X input?

IMO, graphics application with no input are useless - in most cases,
even for non-interactive ones (i.e. to quit it before it exits
automatically in times later...).

> As for PCI access, our SNAP drivers do all their own PCI enumeration and 
> XFree86 does it's own, and they coexist very peacefully.

lol...

IMO, X should get such information from the OS
(How do XFree86's drivers work on OpenBSD?)

Oh and btw: How does XFree86 do PCI scanning on the sparc architecture? :-))


-- 
CU,

Christoph Egger


+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!