<simonb@netbsd.org> (Simon Burge) writes:

> Ross Harvey wrote:
> 
> > I've said it before but once again: we really do need a volunteer
> > willing to work on X for NetBSD/alpha. It has always been on my list,
> > but has never made it to top priority, so I've never even started work
> > on it and I'm not sure if that will ever change. (I always think I can
> > start in a month or two, but it's always at .+2.)
> 
> I think I've secured a spare AlphaPC164 to look into this a bit more
> seriously.  If I recall (without checking up in the archives), the
> problems with XFree86 have been "we (NetBSD) don't just want to make the
> VGA card look like a PC to XFree like some other Un*x clones do, we want
> a nice MI interface"?  Is this a fair summary?

Something like that. An early stumbling block in making XF86 work on
the Alpha is that it wants to scan the PCI bus itself (with
inb()/outb()) to find the card and ID it, and then mmap() it through
/dev/mem.

I think we can take the philosophical difference that the invoker of X
has to tell it what device to use, rather than letting it scan. That
accomplished, we need some interface (an ioctl, probably) to let XF86
get the PCI vendor/ID of the device, and what memory range(s) of that
device it can mmap(). Once an interface is invented, this is a SMOP;
the kernel has the information. This smells like it might be a wscons
interface, in which case it needs a little more data for "Hey, I'm not
a PCI device, I'm {TurboChannel/SBus/ISA/whatever}."

I think that will make X limp along. I'm sure there are other problems
to be excorsed (byte accesses that will have additional side effects
on a alpha-compiler-induced longword read? flipside, bus errors from
accessing PCI dense space with BWX instructions?)

I'll be continuing my poking at this (with my TGA ZLXp-E2 at first,
not a VGA card) once I get *my* new pc164 up and running in a couple
of weeks.

        - Nathan