clubneon wrote:
> Yeah, I'm not understanding the lack of being able to compile in settings
> for my PAS16 also. Even if they were compiled in, they could still be
> overroad on the command line (correct?).
>
> I've always thought of the lilo "append" command as a hack to get things
> working that were odd. I always prided myself on having a machine that
> didn't need any appends.
Put me in that camp as well, but here's the lay of the land as best
I understand it.
There has been a long sustained push to modularize the sound drivers.
You may legitimately ask "why?" since PCMCIA/cardbus sound cards are
rare beasts indeed. Mostly, it happened because the distribution
maintainers couldn't possibly put a distribution together that would
support a given user's sound configuration without a modular sound
driver collection. Ok... So I was thus convinced that modular sound
drivers have their place.
As for why we can no longer compile in the driver settings for our
static configurations, that's another matter. The sound drivers have
been a mess for a long time. Originally, the drivers as provided by
Hannu were intended to be useable on a wide variety of UN*X platforms.
Naturally, that meant the drivers weren't optimal for *any* of the
supported platforms. In the Linux case, if you were going to write a
sound driver from the ground up, I would assume you would try to write
it so that autoprobing would work: this path is fraught with peril.
On the other hand, a necessary step if you're going in that direction
is to provide the same kind of mechanism that exists for other Linux
drivers where autoprobing isn't reliable or just flat doesn't work,
i.e., the "append" clause in "lilo.conf".
As best I can figure out the PAS-16 situation as of 2.3.50, here's an
"append" line that works for me:
append = "opl3=0x388 pas2=0x388,11,5,-1,0,-1,-1,-1"
where the "pas2" arguments are
"<io>,<irq>,<dma>,<dma2>,<sbio>,<sbirq>,<sbdma>,<sbdma2>"
As far as I know, dma2 should always be "-1". sbio should be 0 if
you don't wish to enable SoundBlaster emulation, 1 otherwise. Normally,
you *don't* want to enable SoundBlaster emulation. Note that all the
values after <dma> are the defaults if you build the PAS-16 driver as
a module. Here's a gotcha: there *are* no defaults if you build the
driver as part of the kernel, i.e., you should (and usually *must*)
supply ALL parameters, else, you can pretty well count on an "oops" at
boot time during driver initialization.
As usual, read the source for the gory details... At boot time, the
adlib driver will complain that you need to supply an I/O address. If
you supply the proper address (normally 0x388), the sound drivers will
politely inform you that only one opl3 is supported. In other words,
you can't eliminate all the boot time "error" messages, but they
aren't really errors in any sense that matters as far as getting a
functional PAS-16 card.
-- Bob Tracy | "C++ is to C as Lung Cancer is to Lung." rct@wlk.com | --Anonymous Coward on slashdot.org- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:22 EST