Re: How about running X on top of something else?

Christoph Egger <[email protected]> wrote:

> > 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. 

Really! Seems you don't know GGI well enough to know that I was involved 
at the very early design stages of GGI. In fact GGI and what became SNAP 
were evolving at around the same time, and we cross pollinated a lot of 
ideas back during the early design stages of GGI. Personally I think GGI 
actually has quite a nice architecture.

> 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'). 

Yes, and SNAP is designed with the same principles in mind. We have SNAP 
drivers that run on a memory buffer (for headless machines) as well as 
SNAP drivers that run on top of DirectX. Of course SNAP can also directly 
access the hardware. We haven't bothered as yet (no real need on Linux 
since we can control the hardware directly), but we could write SNAP 
drivers that would run programs (such as the SciTech MGL libraries) that 
would run under X11, on top of fbdev, on to of DirectFB, on top of of 
SVGALib and even on top of GGI. It would be mostly an accademic exercise 
though, so we haven't done it (except the X11 version; that will be 
useful and actually is in our roadmap so that MGL can be used by X11 
apps).

So I se no design issues that would stop you building a GGI XFree86 
driver module if GGI still has a nice clean design.

> 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! 

I fail to see why you would have a resource conflict here. If you wrote 
an XFree86 driver module that interfaced to GGI, why exactly do you 
believe that XFree86 would suddenly be trying to control the hardware 
resources? It won't, because the code that would normally control the 
hardware resources should have been replaced by a layer that calls into 
GGI functions. In the case of running on top of fbdev, this would just be 
a GGI->fbdev layer and all resource access should be handled by fbdev or 
the GGI layers (assuming the GGI layers are doing user land 
acceleration).

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

I think however you are missing the point here. Using an XFree86 module 
that runs on top of GGI is really only useful if the GGI layer is 
providing native hardware driver support. A version that does X->GGI-
>SVGALib->HW or X->GGI->fbdev->HW is a pretty academic exercise and 
should be ignored as a supported target.

> 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.

I don't know enough about XFree86 PCI probing, but I would guess given 
the existance of xnest and xvfb that you can build XFree86 servers that 
do not do any PCI bus access at all. From within an XFree86 driver module 
this is probably not easy to bypass, but if it is a critical issue you 
could always work out how to bypass it and submit patches back to 
XFree86.

> 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_! 

XDarwin is a completely different ball of wax to an XFree86 server that 
runs on top of GGI. XDarwin's job is to integrate a rootless X server 
into the MacOS X desktop. There is no device driver model needed, except 
for a layer to pass things through to the underlying display driver used 
by the MacOS Quartz engine. However there is a *lot* of stuff around the 
edges that needs to be done to integrate the X windowing system into the 
MacOS windowing sustem using the MacOS default window manager. To do that 
project there was really no other choice but to build a completely 
separate server, since the XFree86 driver module system was designed to 
support direct hardware access, not integrate into another operating 
systems windowing layers and device driver model.

At the end of the day it really depends on what the focus of XGGI is. If 
XGGI is intended to be a X server that can utilise the native hardware 
drivers in GGI, you can easily do that as an XFree86 loadable module. If 
however you expect XGGI to be some weird X server that can run on any 
platform (ie: in a window under DirectX, inside X11 (ala xnest) etc) then 
the GGI abstraction layer is too high level and confusing the issues.

> 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?

I figured that was what you were getting at. In a word - who cares!! It 
is a completely academic exercise to run XGGI on top of another X server 
(just like I think it is an academic exercise to run XGGI on thinks like 
SVGALib or fbdev)! There is no value there. Xnest is not a real server 
and not used for many practical purposes. It mostly exists as a test 
mechanism to allow people to quickly try out and test new ideas, not as a 
production server people will use in the real world!

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~