| gabriel rosenkoetter on Tue, 8 Jul 2003 00:41:15 -0400 |
|
On Mon, Jul 07, 2003 at 08:05:50PM -0400, Fred K Ollinger wrote: > I thought I installed everything, but who knows. I'm probably going to > reinstall anyway so I'll look out for it. Incidentally, I had scoured > /usr/X11R6/bin/ for it, and I did not find it, though I did find regular > X, which did not work as should be expected in this case. X should just be a sym link to the local X server: grappa:~% uname -a [1] NetBSD grappa 1.6K NetBSD 1.6K (GRAPPA-$Revision: 1.533 $) #3: Tue Jan 21 22:32:43 EST 2003 gr@grappa:/new/src/netbsd/src/sys/arch/i386/compile/GRAPPA i386 grappa:~% ls -l `which X` [2] lrwxr-xr-x 1 root wheel 7 Apr 10 2002 /usr/X11R6/bin/X@ -> XFree86 uriel:~% uname -a [1] NetBSD uriel 1.6.1_RC2 NetBSD 1.6.1_RC2 (URIEL) #0: Wed Mar 26 19:22:52 EST 2003 gr@grappa:/new/src/netbsd-1-6/src/sys/arch/macppc/compile/URIEL macppc uriel:~% ls -l `which X` [2] lrwxr-xr-x 1 root wheel 7 Jan 15 2002 /usr/X11R6/bin/X@ -> Xmacppc I'd be interested to see what your /usr/X11R6/bin/X is... > I figured that what this means is that I can have all of X goodness except > that it will really suck, be slow and so on. Is this correct? Well, it means that you can have graphical windows and run a web browser. I wouldn't go expecting any kind of 3D acceleration. > Or will have something that is not quite X? I won't waste too much time on > this unless I can pop up windows with tk code, which is the reason I want > this box to run X, also, to run a simple web browser, xpdf, and maybe > gnumeric. You'll be able to do all of those things just fine. I X forward things that complicated from my macppc machines all the time, but seldom use their console for X. Also, note that, depending on the system, you may be locked into 640x480 mode by OpenFirmward refusing to initialize the video chipset to anything higher on boot. You might or might not be able to fix this with some OF twiddling (which you could then define as part of a Forth script that ended in calling the regular "boot", store the script in the nvramrc, and call the script from the OF environment variable boot-command). > This is still the case and will probably remain so unless I grow another > brain and code it myself. Some later PowerMacs shipped with something closer to an industry standard chip. My understanding, which may have been mistaken, was that XF86 4 just didn't know to be looking for the chip on the other side of the kind of bridge where it showed up in a Mac, as opposed to a (IA32-)standard PCI bridge. If that's the case, generalizing the XF86 code to deal with the situation (especially under NetBSD) is ridiculously easy and the X folks are remiss for not doing so. Oh, well, maybe. XF86 does its own probing of the PCI bus, for better or for worse (this is frequently a good thing, see below), so that stuff would perhaps have to be added on to it in a moderately painful way... > I might try the card trick out, but I heard that this is a lost cause > unless one has of3.0, and I am at 1.x. You're at 1.0.5, I think. I don't know if that's still the current state of affairs, since I've a friend using a couple of PCI Ethernet cards without OF on-board on an OF 1.0.5 PowerMac, which I also thought was impossible. The graphics card problem may be more complex, though, as if OF doesn't recognize the card, you'll never get a console framebuffer on it. Maybe that doesn't matter and you can still get X to operate on it (and just use a serial console rather than a framebuffer). Certainly, this is effectively what one does for second (or beyond) monitors for use with Xinerama (the console, that is things like wscons, only know about the first, and making a text console appear on others is quite difficult, but having XF86 recognize all of them is relatively easy, since it does its own probing of the PCI bus). -- gabriel rosenkoetter gr@eclipsed.net Attachment:
pgpvn0hgM5EXN.pgp
|
|