On Tue, 28 Jan 1997, Chris G. Demetriou wrote:

> > How different is the new console from the console facility provided by
> > Linux on the Alpha?
> 
> "very."
> 
> > Supposedly, XFree86 is working with Linux on the Alpha,
> > and, unless there are good ideological reasons for doing so, things probably
> > ought to be made such that the code in XFree86 need not be that different
> > for Linux/Alpha and NetBSD/Alpha.
> 
> OK, where should i start?
> 
> (1) Alpha Linux's console interface is, from what I can tell, i386
> Linux's console interface (perhaps with a few tweaks).  They basically
> said "these are PCs on speed."  That is quite simply _wrong_,
> especially if there's any desire to support turbochannel frame
> buffers.

>From the basis of providing an familiar text-based user interface, I think
the console interface is the simplest to program and subsequently use en
route to providing better interfaces.

At the risk of sounding argumentative, you've repeatedly told us what the
things you think the turbo-channel frame buffers _aren't_ without trying
to tell us what you think they _are_.

> (2) the existing X server code in Xfree86 on the Alpha uses functions
> 'inb()' and 'outb()', with their traditional arguments.  What do they
> mean (what _can_ they mean) if you've got multiple ISA or multiple
> primary PCI busses?  What do they mean on systems that look nothing
> like PCs?

'inb()' and 'outb()' map to a memory mapped input/output section on the
alpha which interfaces to the ISA bus.  If you have multiple busses, it's
up to the architecture specification to let you know how to talk to
anything connected to the bus.

I may be speaking totally offbase here, but as far as I can tell, XFree86
was mostly developed for use on x86 machines, and those that are
relatively architecturally similar.  ISA + PCI based Alpha systems fall
close if not directly in with these.

> (3) XFree86 is completely wrongheaded in the way it does frame bufffer
> detection.  Basically, it looks through PCI configuration space (on
> Alpha Linux by using some routines in libc(?), from what i can tell
> reading the mailing lists), figures out what frame buffers are there,
> where they are in /dev/mem, and accesses them that way.  _That_ is
> totally wrong-headed, as well.  It might make sense for PCs, and on
> OSes that have no reasonable console interface, but it doesn't make
> sense on workstations or on systems with console interfaces which
> actually do a fair bit of work (e.g. detecting generic 'classes' of
> devices for you).

PCI configuration services are provided by the kernel and provide a
standard interface for determining what is attached to the system, what it
does, and where it's located relative to the memory and I/O bus.

'cat /proc/pci' will gleam information such as the following on a PCI x86
or alpha system:

PCI devices found:
  Bus  0, device  20, function  0:
    VGA compatible controller: ATI 215CT222 (rev 9).
      Medium devsel.  Fast back-to-back capable.  IRQ 255.  
      Non-prefetchable 32 bit memory at 0xe0000000.
  Bus  0, device  19, function  0:
    SCSI storage controller: Adaptec AIC-7871 (rev 0).
      Medium devsel.  Fast back-to-back capable.  IRQ 11.  Master Capable.
Latency=32.  Min Gnt=8.Max Lat=8.
      I/O at 0x6000.
      Non-prefetchable 32 bit memory at 0xe1000000.
  Bus  0, device   7, function  1:
    IDE interface: Intel 82371SB Natoma/Triton II PIIX3 (rev 0).
      Medium devsel.  Fast back-to-back capable.  Master Capable.
Latency=32.  
      I/O at 0x9000.
  Bus  0, device   7, function  0:
    ISA bridge: Intel 82371SB Natoma/Triton II PIIX3 (rev 1).
      Medium devsel.  Fast back-to-back capable.  Master Capable.  No
bursts.  
  Bus  0, device   0, function  0:
    Host bridge: Intel 82439HX Triton II (rev 1).
      Medium devsel.  Master Capable.  Latency=32.  

I am totally unfamiliar with the turbo-channel set up, but from what you
describe, this sounds similar.  Providing a standard OS interface for
programs that bridge the gap between user and kernel functions is probably
the cleanest way to implement providing the necessary information to an
XFree86 port.

> (4) I want a console interface that can be picked up by other ports;
> i'm already aware of one port-in-progress that's planning to use it.
> 
> Quite honestly ... i'm not impressed by the XFree86 support for the
> Alpha.

Jason Duerstock
jason@linux.aatech.com