On Tue, Oct 08, 2002 at 08:07:39PM -0500, Branden Robinson wrote: > On Tue, Oct 08, 2002 at 04:45:18PM -0600, Joel Baker wrote: > > > > @@ -356,0 +355 @@ > > > > +usr/X11R6/bin/kbd_mode > > > > > > I used to see this on Sun machines. You sure it's necessary with modern > > > BSD kernels? > > > > I'm not sure it is. I mostly don't know where/how to check whether it is, > > or what it's supposed to do. > > It changes the tty keyboard reading mode, e.g., from "raw" to "cooked" > and vice versa. > > I think Linux doesn't have this because a keyboard state is specific to > each virtual terminal, so the kernel knows to put the keyboard state > back after the X server crashes and gives up its VT. > > On Sun boxen, you often had to telnet[1] into the box after X crashed and > run "kbd_mode -a". Ah. Yes, I remember doing that now. And I suspect it's obsolete on modern NetBSD, then, because it also has virtual terminals (albeit of a different sort, but the same concept) with which X interacts directly. Two different versions thereof, even. I'll see if I can convince it to stop building. > > > > @@ -5543,2 +5539,0 @@ > > > > -usr/X11R6/lib/libI810XvMC.a > > > > -usr/X11R6/lib/libI810XvMC_pic.a > > > > > > This is new to XFree86 4.2. My guess is that it does something to hook > > > into the (Linux) kernel to speak foul magic to the hardware. XvMC is > > > Mark Vojkovich's motion compensation interface on top of the XVideo (Xv) > > > extension. I'll cautiously assume that *BSD shouldn't be building this. > > > > We can always put it back in if someone can show that it should build/work > > on NetBSD platforms. However, at the moment, this is not listed as being > > supportd on the NetBSD arch page in XFree86 docs. Will yank it. > > I forgot to mention that you *should* have libXvMC. Just probably not > this I810 thing. Left those in; only the I810 files were removed from the MANIFEST. > > > Nobody who builds DRI builds the offscreen Mesa library. Michel Dänzer > > > understands better how this stuff works. (I.e., I don't know *why* it's > > > called the "offscreen" Mesa library, or why 3D-accelerated GL rendering > > > is considered "off-the-screen". Maybe it means the rendering isn't done > > > into the framebuffer, a.k.a. "screen"?) > > > > Er. Is that 'not building DRI implies not building libOSMesa' - IE, it > > should be removed for non-Linux platforms? > > Correct, as I understand it. Okay. Makes sense to me. > > > > @@ -5602,0 +5595 @@ > > > > +usr/X11R6/lib/liboldX.so.6.0 > > > > > > This goes in xlibs-dev.files. Already listed there. > > > > Huh. xlibs-dev.files (and all of the MANIFESTs) have a static library > > (/usr/X11R6/lib/liboldX.a) rather than a dynamic one. Maybe I need to tweak > > a suitable part of the system and tell it to build a static liboldX? > > Sorry, I failed to pay attention. Please don't ship a shared liboldX > unless for some insane reason you need it for binary compatiblity with > other BSDs. It would be preferable to turn of building of the shared > version. I'll see if I can figure out why it's doing so and whack it into a static instead. > > > > @@ -5608 +5600,0 @@ > > > > -usr/X11R6/lib/libxrx.so.6.3 > > > > > > Another extension no one uses. This is the Netscape Navigator plug in > > > that lets you render the X server inside a browser window or some lunacy > > > like that. I'm not sure there's a good reason it shouldn't build on > > > *BSD versus Linux, but on the other hand there's probably not a good > > > reason for *anyone* to build it. > > > > Hmmm. I'll look into it, but after I do other things, then; tentatively > > left in place, until I can figure out what is up with it on NetBSD. > > Maybe the Netscape plugin code is Linux-specific? I have no idea. I'm > sure no one cares about this thing. I'm sure, too, but *iff* it compiles, well, it would be nice to make it available. But low priority. :) > > Now, the explanation for glxinfo (and it probably has much deeper > > reprecussions): NetBSD includes bsdLib.rules, which does not have a number > > of things from lnxLib.rules (the thing which made me realize this matters > > is that it lacks SharedDepCplusplusLib, causing libGLU to be linked with > > 'gcc' instead of 'g++', causing glxinfo to fail when it tried to link > > against the .so because the .so couldn't find various C++ system library > > things). > > > > Nor can I just drop in lnxLib.rules (unsuprisingly), because it wreaks a > > lot of havoc in other places. So I'm going to have to general a patch set > > for bsdLib, providing the bits from lnxLib that are required to make things > > compile in a Debian-happy way. > > I don't have very much useful to offer here. I have some facility with > Imake after fighting with it for so many years, but I phear the > *Lib.rules files. I think I found it. The bsdLib.rules ELF rules are 'copied mostly from the linux rules' - but lacked a SharedDepCplusplusLibraryTarget definition. I copied the SharedDepLibraryTarget one, changed CC to CXX (which is the sole difference between them on linux, and the only obvious difference that I know to exist at the moment). We'll see if it works on the next build pass. > > Anyway, I'll be back once I beat on it some more. Any suggestions on what > > to check to find out if kdb_mode is relevant would be appreciated. > > If the keyboard is generally hosed after the X server exits (test it > under a crash too -- kill -SEGV the X server) then you probably don't > need it. > > If existing userspace tools can do the job as well, it's probably also > not needed. E.g., "stty cooked". > > [1] Yes, that's how long ago I had to do this. AFAIK, other userspace tools will cope with it properly. I'll double-check it when I can schlep a monitor and keyboard down to that machine, but until them, I'll assume this is no longer relevant to NetBSD. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Attachment:
pgpdVumGbX11i.pgp
Description: PGP signature