[ On Monday, July 16, 2001 at 21:41:34 (-0400), Charles Shannon Hendrix wrote: ]
> Subject: Re: Why not track our xsrc with X11R6.6 from X.org?
>
> That's true, though the main reason for that is because X was previously
> heavily proprietary, and difficult to make widely available.  The PC
> was the platform that suffered the most.

Ah, um, that seems wrong (on several fronts)!  X11 has been the premier
example of "open source" nearly decades befroe the phrase was ever
coined!  It was always anything but proprietary.  Part of this was of
course due to the fact that as a research project it had to be published
(at least that's how I understand the rules work, or at least worked at
the time).

I don't see exactly how the PC suffered in any way either, other than
perhaps there were no PC "unix" vendors on the X Consortium board and
indeed perhaps early PC-unix vendors weren't interested in X11.  Early
versions of ``standard'' PC graphics also really really really sucked
from an X11 graphics model, eg. VGA -- what a horror it was to program
directly too!  (I don't know if XGA gets rid of some of the old problems
or not....)

In more recent times the problem was not that the PC suffered, but
rather that the multitude of PC unix and unix-like variants all had
quite different APIs for graphics devices, if of course they even
provided a decent driver for such a device in the first place....

Of course the "moving target" of near weekly PC hardware changes doesn't
help (even today).

> > Why does XFree86 even have to know about the bus or whatever?  
> 
> Why does Xsun? The workstation X servers are even worse in this regard.

Huh?  Xsun knows nothing of sbus or pci (or vme or whatever is in a
Sun-386i for that matter).  I'm using exactly the same code on an sbus
bwtwo card that I previously used on a mainbus bwtwo framebuffer, and
I've used another variant on a VME CG series and P4 CG and an sbus CG.

Xsun simply expect a framebuffer device driver that offers various
common ioctl() calls.  I don't know the exact details, but the sun tcx
driver for accellerated frame buffers seems no different.  It simply
offers up the lookup tables and various control registers via mmap().

Any magic necessary for remapping virtual memory to hardware registers,
etc., happens in the driver in the kernel, not in the Xserver.  From the
Xserver you see the hardware, via memory accesses, but not the wiring.

Very cleaner, very secure (or at least has the possibility of being more
secure! ;-).

> Hah! All X servers are generally done like that, or were in the past.

I don't see that in Xsun, and from what I read of the HP and DEC driver
manual pages they're no different....  all have a common driver API that
hides the worst of the hardware implementation details such that the
same Xserver works with the same graphics chip (or whatever) on many
different systems (even across CPU architectures).

> XFree 3.x was just horrible, with drivers hard-coded into servers. Sun
> was no different, with the code for their cards done about the same way.

Well, yes, there are classes of devices that require separate Xservers,
but ...

> I remember having the different servers depending on my hardware the
> last time I used Suns with graphics.

... this is an optimisation, not a requirement.  You can already use
Xsun on a bwtwo, but XsunMono is much smaller and seems faster; and of
course Xsun24 still works on all the less capable framebuffers too, but
less efficiently than Xsun or XsunMono on their respective hardware.
 
Perhaps we're talking about different levels of "driver" though.....

Certainly having an Xserver "driver" for some hardware accelleration
feature is an entirely different issue from an OS driver that presents a
common interface to a given class of graphics device.  The former is
certainly hardware specific, but more or less independent of the
physical bus the hardware's attached to and given a half-decent driver
API it should be possible to have a common Xserver for a given graphics
chip regardless of what bus it's on, or indeed even what processor it's
running on (just as in XsunMono working on sparc/sbus and m68k/mainbus
or VME)

Except maybe in the Linux/M$ "desktop" arena there's nothing wrong with
"hard-coding" various chip and accelleration support features into a
given build of an Xserver.  I don't need or want "pluggable" dynamic
loaded modules.  I have no problem whatsoever choosing the Xserver
binary to run based on what type of graphics chip or whatever that I've
got in my system.  This is not an issue the open source world should be
concering itself with.  I'm quite happy to use a little script or
something that calls "constype" or similar to help me invoke the correct
server more dynamically.

> > Yes I know that development and support of other graphics
> > systems (i.e. other than X11) has waned, but does that automatically mean
> > that the only way to access graphics hardware should be through the XFree86
> > Xserver?
> 
> That's one thing DRI is for... allowing the use of an X server but still
> letting you get close the the hardware.

Oh, no!  Not that can of worms!  No, I'm not talking about getting close
to the hardware *with* X11, but rather *instead* of and *without* X11!

> What part of it do you perceive as being PC-centric? I imagine that the
> server in 4.x will sit on top of sbus drivers too. 

I'd very much rather that it just sit on the existing /dev/fb device.

> I'm sure the pieces
> of code that handle the abstraction will need to be modified (if it has
> not been already), but I don't see that as making the design PC-centric.

Well, I'm partly parroting things I've heard others say, of course, but
the primary reason goes something like this:  It's "pc-centric" because
the guys that designed it seemed to have done it from the point of view
where they might have said something like "What's all this X11 crap?  I
don't have a framebuffer driver in this system, but if you'll let me
root around in the low-level hardware and bios registers a bit I'll find
out where and what the graphics card is, and then since I'm already down
here in the low-level hardware I can take it over directly and muck
about with it in the most efficient way I know how and mabye we can
provide enough code to support the upper layers of that X server thing!
Now where'd you put those peek() and poke() routines?"  :-)

(and how far off can I be when xfree86/os-support/solx86/solx86_iout.s
contains assembler definitions for inb()/outb, inw()/outw(), and
inl()/outl(), an it sits right beside stuff to read BIOS info via
mmap()!!!!!  blech!)

This whole "aperture" driver crud is just a VERY immature and
ill-defined /dev/fb too!  I don't know how/if that fits into XFree-4,
but if it's anywhere at all then I see no improvment.

Thanks, but no thanks!

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>