rich@oxtrap.UUCP (K. Richard Magill) (02/09/88)
In article <384@pcbox.UUCP> pjc@pcbox.UUCP (Paul J. Condie) writes: >In article <3686@megaron.arizona.edu> lm@megaron.arizona.edu.UUCP (Larry McVoy) writes: >>In article <1686@codas.att.com> mikel@codas.att.com (Mikel Manitius) writes: >>>Has anyone tried to port, or know of anyone that has, X Windows onto a >>>3B1? I've got my hands on X.V11R1, and am thinking about looking into >>>doing the port myself. Ideas? >>Uh huh. Right. It's only umpteen million lines of code that depends heavily >>upon BSD system calls. Good luck. >yea, let us know when you're done. I'm ready. I have all the info I need to do it but I could use some help. If anyone wants to help, how about if I coordinate and/or start a mailing list. I have a list of subprojects and research that need to be done. Eg, Should we really build an X server over the window device driver? (this means lots of ioctl's to write to the screen and prevents the use of a meta key) Eg, I know the addresses of the status and data registers of the keyboard but I don't know the layout of the status register nor the protocol for dealing with the keyboard. This could be figured out by a) asking someone who knows, b) disassembling pieces of the window driver, (awkward, cause its big), c) prodding at hardware, d) monty carlo, that is, try something until it works, or e) something I haven't thought of. a) requires contacts that I don't have. c) requires hardware that I don't have. Which leaves me only c) and d). Eg, we really want something like a frame buffer which means a specialized device driver, (not hard), which means replacing the window driver (a little scary) which means replacing /dev/console with some other driver which is at least a glass tty. Eg, if we want a frame buffer, how to we get system address space mapped into user space? Can we ask the sysVipc shared memory to start at a specified place? Can we sysVipc shared memory and tease the virtual memory system into remapping?
alex@umbc3.UMD.EDU (Alex S. Crain) (02/10/88)
[much enthusiasm deleted about X on 3b1] I tossed this out about a montha ago, and nobody said anything, so I scored the sources and looked at them. Yuk. X is a great program, but its really overkill for a 3b1 unless your networking a batch of 'em, and even then I wonder. It's a huge program that uses lots of code to do things that most 3b1 users never do, like network protocalls. Also, requiring all i/o to go through a user program is gonna slow things down something fierce, and X is a bit unstable to live in MY kernal space, thanX. A more viable option is to first rewrite the window driver, and then add X compatability (to some degree). That wouldn't be harder than X ittself, and could be done gradually, adding unixpc specific stuff, and retain /dev/w* compatability, so you wouldn't break the world. Note that its the window driver that provides us with the working icon, the unusable screen area that's reserverd for mouse buttons and smgr, etc. Also note that /dev/console is NOT the window driver, but is built into the kernal. If you uninstall the window driver, you are left with a FULL SCREEN scrolling display. Just some thing to think about. -- :alex. nerwin!alex@umbc3.umd.edu alex@umbc3.umd.edu
aglew@ccvaxa.UUCP (02/11/88)
I'm interesting in corresponding with rich@oxtrap.uucp
about X-windows. I may have some of the info necessary.
I do not, however, have a return mail address.
Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801
aglew@gould.com - preferred, if you have nameserver
aglew@gswd-vms.gould.com - if you don't
aglew@gswd-vms.arpa - if you use DoD hosttable
aglew%mycroft@gswd-vms.arpa - domains are supposed to make things easier?
ihnp4!uiucdcs!ccvaxa!aglew - tried
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.mikel@codas.att.com (Mikel Manitius) (02/15/88)
Porting X to a 3b1 is a lot of work. I've communicated with several people who are either starting such work, or have been working on it for a while. The problem of course, are the resources of the 3b1, and it's probably not practical unless you have a network to run on. We have all of our 3b1s on STARLAN, which I've become very familiar with programming. I'd like to see it run, and could even contribute a lot of the networking code, but really it's a lot more work than I want to do at the moment. -- Mikel Manitius mikel@codas.att.com