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". > > > @@ -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. > > 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. > > > @@ -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. > > > @@ -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. > Policy says FHS; Debian/NetBSD, at least, is basically NetBSD kernel, libc, > and other required system libraries, but Debian-package-pure userspace, > filesystem arrangement, et al. The only exception so far is that, on the > 1.6 port, ld.so and family live in /usr/libexec, but NetBSD native moved > this to /lib (as well as making /lib dynamic) in -current immediately after > the 1.6 release, so even that will probably go away before it requires a > Policy adjustment. > > As such, I'll change the patch and tweak said symbol to put it where the > FHS says. Okay. /var/lib instead of /var/db for Debian/NetBSD it is, then. > 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. > 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. -- G. Branden Robinson | The last Christian died on the Debian GNU/Linux | cross. branden@debian.org | -- Friedrich Nietzsche http://people.debian.org/~branden/ |
Attachment:
pgpyrxbCzMbu7.pgp
Description: PGP signature