Subject: Re: OSS audio emulation [ossaudio(3)] is still source-incompatible with Linux....
To: Frederick Bruckman <fb@enteract.com>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 05/06/2001 02:38:26
[ On Sunday, May 6, 2001 at 00:59:21 (-0500), Frederick Bruckman wrote: ]
> Subject: Re: OSS audio emulation [ossaudio(3)] is still source-incompatible  with Linux....
>
> That looks familiar! I just patched one of those for a squeak-3.0 package.
> One of these days, someone needs to collect all the configure hacks
> in pkgsrc into "automake", so that "aclocal" really works for NetBSD.

That's exactly what I was working on too!  (though I have seen some
other code that has very similar checks for OSS support -- I just can't
find it at the moment...)

BTW, you'll need this for 8-bit displays (I've already sent it to the
author, along with a comment about why I added GrayScale tests):

--- src/unix/sqXWindow.c.orig	Fri Mar 23 17:47:37 2001
+++ src/unix/sqXWindow.c	Sat May  5 21:02:06 2001
@@ -566,12 +566,12 @@
 {
   switch (x)
     {
-    case 0: return "StaticGray";
-    case 1: return "GrayScale";
-    case 2: return "StaticColor";
-    case 3: return "PseudoColor";
-    case 4: return "TrueColor";
-    case 5: return "DirectColor";
+    case StaticGray: return "StaticGray";
+    case GrayScale: return "GrayScale";
+    case StaticColor: return "StaticColor";
+    case PseudoColor: return "PseudoColor";
+    case TrueColor: return "TrueColor";
+    case DirectColor: return "DirectColor";
     default: return "Invalid";
     }
 }
@@ -1210,9 +1210,7 @@
     }
 
   if (stVisual->class == PseudoColor)
-    stColormap= XCreateColormap(stDisplay, stWindow, stVisual, AllocAll);
-
-
+    stColormap= XCreateColormap(stDisplay, stParent, stVisual, AllocAll);
 
   /* 1-bit colors (monochrome) */
   SetColorEntry(0, 65535, 65535, 65535);	/* white or transparent */
@@ -1286,7 +1284,7 @@
 
   if (stVisual->class == PseudoColor)
     {
-      XSetWindowColormap(stDisplay, stWindow, stColormap);
+      XSetWindowColormap(stDisplay, stParent, stColormap);
       stColorWhite.pixel= 0;
       stColorBlack.pixel= 1;
 #if 0
@@ -1348,10 +1346,10 @@
       { 16, DirectColor },
       { 16, StaticColor },
       { 16, PseudoColor },
+      { 16, GrayScale },
       {  8, PseudoColor },
       {  8, DirectColor },
-      {  8, TrueColor },
-      {  8, StaticColor },
+      {  8, GrayScale },
       {  0, 0 }
     };
 
@@ -1360,19 +1358,19 @@
 
     for (i= 0; trialVisuals[i][0] != 0; ++i)
       {
-#       if 0
+#if 0
 	fprintf(stderr, "Trying %d bit %s.\n", trialVisuals[i][0],
 		debugVisual(trialVisuals[i][1]));
-#       endif
+#endif
 	if (XMatchVisualInfo(stDisplay, DefaultScreen(stDisplay),
 			     trialVisuals[i][0], trialVisuals[i][1],
 			     &viz) != 0) break;
       }
     if (trialVisuals [i][0] == 0)
       {
-#	if 0
+#if 0
 	fprintf(stderr, "Using default visual.\n");
-#	endif
+#endif
 	stVisual= DefaultVisual(stDisplay, DefaultScreen(stDisplay));
 	stDepth= DefaultDepth(stDisplay, DefaultScreen(stDisplay));
       }
@@ -1433,7 +1431,7 @@
     attributes.event_mask= EVENTMASK;
 
     /* A visual that is not DefaultVisual requires its own color map.
-       If visual is PseudoColor, the new color map is made elsewhere. */
+       If visual is PseudoColor, the new color map is made in SetUpPixmap(). */
     if ((stVisual != DefaultVisual(stDisplay, DefaultScreen(stDisplay))) &&
 	(stVisual->class != PseudoColor))
       {


It's still coming up with the wrong display depth inside smalltalk, but
that's pretty easy to fix and once you do all looks very fine.

> Yeah, I've wondered about that, too. I've reviewed the cvs logs, and
> the reason "soundcard.h" can't go in "sys/soundcard.h" is sound:
> "/usr/includes/sys" comes from "syssrc/sys/includes". "syssrc" is
> seperable from the rest of the sources, and it's just not right to
> have to keep one file there in sync with "basesrc/lib/libossaudio/".

I'm not entirely convinced that something from under basesrc/lib can't
install a header in <sys>.  It's ugly, but if that's where the rest of
the world, particularly those defining the API, say that the header must
live, and if NetBSD wants to offer an emulation for portability's sake,
then that's where it must go.

I.e. just because a file ends up in /usr/include/sys doesn't mean it has
to have come from /usr/src/sys, does it?  (Yes some developers still
using weird symlink tricks might get foiled iff they try to build some
OSS-using tools, but then they're the minority, right?)

The only question might be whether anything in basesrc outside of
libossaudio might need to use <sys/soundcard.h>.  I've not checked, but
I hope not, given that it would only seem prudent to have all the other
stuff in basesrc use the native audio API.

> A possible solution might be to have "sys/soundcard.h" simply
> _include_ "soundcard.h". That would give us true source compatibility,
> without incurring any extra maintenance effort.

I like that solution though.

Any reason why it can't define OPEN_SOUND_SYSTEM too?

and that leaves the question of what to do about /dev/dsp
 
> > I haven't yet looked about the amount of effort necessary, but it seems
> > at least on the surface that if the program has to be patched it may as
> > well be ported all the way to use the native interface and at least then
> > the original author would have some reason to take the changes back....
> 
> I don't know about that. One patch to a macro and and one patch to the
> "includes" is pretty easy to get past, but certain authors don't take
> kindly to having their source peppered with conditional compiles where
> there where none before. (No, I won't name names.) The thing is,
> NetBSD audio is evidently different enough from FreeBSD audio and Sun
> audio that you're not doing anyone any favors.

Well, I wouldn't want a mess of #ifdef's either.  However there are lots
of other ways to write portable code.... :-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>