Alan Coopersmith wrote:
> I have not yet merged in the Belenix or Martux changes yet - either
> Moinak & Martin can volunteer to do so for their changes, or you can
> point me at a current copy of your sources to merge, and I'll try to
> get to it as soon as I can.
I already switched back from theory to practice 10 full days ago, so 98%
of my shelf continue(s) to remain unread.
My intention is to build a wrapper module that would allow Xorg to load
Xsun's ddx driver modules, providing downward compatibility with all the
now EOL'ed SPARC frame buffers for which no native Xorg support exists
(anyways with the exception of XiG's commercial Xorg-drivers: Expert3d,
Expert3dLite, XVR-500, XVR-600, XVR-1200 [and Sun's last self-designed
and last UPA board, the XVR-1000 a.k.a. FFB3 / Java-cpu {a modified
"sunffb" Xorg-driver only loads parts of its chipsets incl. ramdac,
tweaked driver successfully boots, but video remains inactive}]).
That original wrapper (opposite direction) from the 2001/02's porting
kits, which made xf86 modules _appear_ to being loaded "into" Xsun ...
(actually the wrapper module contained many of the objects that normally
end up in the "bin/XFree86" or now "bin/Xorg" binary, so the xf86
modules were not loaded into Xsun, but rather just into a cut-down
version of "bin/XFree86" / "bin/Xorg" which was in fact all of which the
wrapper module consisted: Upper half of "xf86Init.c" plus all required
deps in form of object files linked in)
... that original wrapper module used a ^downhill direction^ for various
reasons.
Xsun was branched off from the original common MIT X11 tree before ddx
modules came into existance, unfortunately, so Xsun and Xorg don't share
any historic compatibility in that aspect.
At first drivers had been statically linked into a monolithic server binary.
Then the Xsun versus XFree86 branches went down two completely
incompatible roads: Xsun introduced ddx modules - circa - in 1996 (hard
to say from the perspective of an outsider). The modules get loaded by
InitOutput() --->> sunloadModule() --->> plus functions contained in the
kernel modules (/dev/fb driver) themselfes, such as driver specific init
functions i.e. sunffbInit() (or in case of CG6 additionally
sunCG6Probe(), plus the standard sunCG6Init() ) embedded into the kernel
modules (gobjdump uncovers a lot). No general purpose bus scan is
performed. No general purpose mmap'ing either (therefore no "xsvc" or
"aperture" required).
Everything is closely driver- and device specific and sits inside the
kernel modules such as in /platform/sun4u/kernel/drv/sparcv9/ffb.
Closed src, except for cgsix from the DDK (I meanwhile got the full 2.6
DDK on original CD, btw!).
I actually planned to tell you more about all this later on, as soon as
I might have made more progress.
But one thing is clear: Whoever implements this wrapper may not require
Xsun's sources, but at least a sufficient set of its object files. Plus
sunInit.c (and maybe others) in src.
XFree86 / Xorg, on the other side, use a framework developed and donated
by Metrowerks in 1997.
So the Interfaces are completely different, see Xorg's "loadmod.c".
Maybe the biggest similarity is, that they both use to compile/deliver
their driver modules as shared libs (preloadable via
LD_PRELOAD_32=/path/to/module).
Wow.
- - - - - - -
And yes, as for the native Xorg driver patches and pkg defs: I'm happy
to sync them with snv_71 and to upload them asap.
Now with working XVR-100 support back (didn't work anymore, after snv_41).
And with functioning Tadpole bus scanning and PGX64 support.
I stopped giving away my SPARC Desktops. So you can be assured that
stuff gets thoroughly tested on most of the older, formerly widespread,
typical configurations (U1, 2, 5/10, 30, 60, 80, SB100, 150, 1000/2000,
Tadpole_Ultra3) before release.
However, no working bus scanning for newer pci bridges though (SB1500,
2500, U25, U45, T1000/T2000).
It may be possible to use the device specific bus scanning contained in
the kernel modules, just as Xsun appears to do it.
Most communication via ioctl's.
Maybe even mmapping without aperture.
But that would be another target.
%martin%
