From: root@snowhite.cis.uoguelph.ca (gopher I)
Newsgroups: fj.mail-lists.x-window
Subject: 386BSD X server
Date: 22 Jul 92 01:29:43 GMT
Distribution: fj
Organization: Workstation Div., Supermicro Systems Group, Sony Corporation

Date: Tue, 21 Jul 92 13:31:13 -0400
Message-Id: <9207211731.AA15456@snowhite.cis.uoguelph.ca>

Hi,

I have been thinking about getting X going on 386BSD and thought I would
throw out a couple of questions:

1 - the obvious: Is anyone out there already doing this? (I have a need,
    but am not that keen, so if someone else is seriously working on it,
    more power to them.)

2 - I can see three ways to do it: (are there others?)
  i) - set up minimal driver support in the kernel and then hack X386 to
       work in the bsd environment.
  ii) - set up minimal driver support and resurrect the ibm/vga server
       from X11R4
  iii) - write a kernel driver that makes the svga board look like a real
       frame buffer and use the cfb code. (ie. map the frame buffer to
       1Mbyte of virtual space for the server, but only make 64K (or 128K)
       of the address space valid via. the page table. Then when the server
       crosses the 64K window boundary, a "page fault" is resolved by
       adjusting the svga window and page table.)

I can see advantages/disadvantages to all three:
Advantages			Disadvantages
i) easiest to add support       requires another hacked version of X386 to
   for other svga chips to      be supported/enhanced for future X versions

   minimal work to get going    difficult to support certain features, such as
                                timing dot clock rates (requires all interrupts
                                to be disabled)

                                does not work for real vga (is mca support
                                coming for 386BSD?)

ii) same driver work as i)      do the svga chips support "real vga, ie. write
                                mode #0, #2" for high res modes? (if not, this
                                is definitely a no go)

    supports real vga           requires V4 --> V5 upgrade of the ibm/vga and
                                and support of yet
                                another X server in the future

iii) uses the cfb server that   will not run with "real vga"
     seems well supported
     (ie. by DEC, Sun  etc)     more difficult to add support for other svga
                                chips or mice (ie. requires kernel driver
                                hacking for them)

                                what kind of performance penalty is there
                                for the kernel traps (page faults) that update
                                the svga display bank?

Funnily enough, since I am more comfortable kernel hacking than X server
hacking, I tend to like iii). { I also want to avoid maintenance of an X
server like the plague. }

One final question. Any ideas on what is the easiest way to support
< 8bits/pixel operation?

Any comments or suggestions? rick
ps: Please reply directly to rick@snowhite.cis.uoguelph.ca, as I am not on
    the mailing list. {or root@snowhite.cis.uoguelph.ca, it goes the same
    place.}