[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: xfree86 4.2.1 on NetBSD/i386

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

> > > >   @@ -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: pgp48Df8RyzbS.pgp
Description: PGP signature

Reply to: