Hi,
I've just tried 2.6.0-test6 on my SIS630 based PIII-M laptop. I was
unable to select the trident ALSA driver for my sis7018 built in sound.
Further investigation revealed it now all of a sudden depends on the
game port being selected as well. My laptop doesn't have a game port at
all so I never built game port drivers.
Is the trident driver really dependable om the gameport? What can be a
solution here?
Thanks,
Jurgen
On Sun, Sep 28, 2003 at 09:50:53PM +0200, Jurgen Kramer wrote:
> I've just tried 2.6.0-test6 on my SIS630 based PIII-M laptop. I was
> unable to select the trident ALSA driver for my sis7018 built in sound.
> Further investigation revealed it now all of a sudden depends on the
> game port being selected as well. My laptop doesn't have a game port at
> all so I never built game port drivers.
Looks like the change that broke it for you is the last change in
sound/pci/Kconfig, from a dependency on SOUND_GAMEPORT to a dependency
on GAMEPORT.
CONFIG_SOUND_GAMEPORT is an odd beast. I think it exists because of
the the following situation:
If gameport is N, it provides empty dummy functions for a sound driver
using it, which compiles and links fine, both builtin and as a
module.
If gameport is Y, it provides real functions for the code using it,
regardless of whether that code is builtin or a module.
But - if gameport is M, and our sound driver is builtin, you will get
unresolved dependencies when linking the sound driver into the kernel,
because the sound driver needs the function definitions from gameport
in order to compile.
CONFIG_GAMEPORT_SOUND is meant to handle that situation. It is defined
in drivers/sound/gameport/Kconfig as
config SOUND_GAMEPORT
tristate
default y if GAMEPORT!=m
default m if GAMEPORT=m
So if you choose GAMEPORT=m, SOUND_GAMEPORT will be m as well, and
then the sound driver that depends on SOUND_GAMEPORT will be forced to
m as well.
ALSA, and specifically snd_trident, handles the problem
differently. Instead of using the build system dependencies, the code
that uses the gameport interface has
#if defined(CONFIG_GAMEPORT) || (defined(MODULE) &&
defined(CONFIG_GAMEPORT_MODULE))
which achieved the same purpose, but is uglier, IMHO.
> Is the trident driver really dependable om the gameport? What can be a
> solution here?
I don't think it is, due to the #defines above. Try this:
Index: sound/pci/Kconfig
===================================================================
RCS file: /home/cvs/linux-2.5/sound/pci/Kconfig,v
retrieving revision 1.8
diff -u -u -r1.8 Kconfig
--- sound/pci/Kconfig 26 Sep 2003 00:23:18 -0000 1.8
+++ sound/pci/Kconfig 28 Sep 2003 21:37:52 -0000
@@ -83,7 +83,7 @@
config SND_TRIDENT
tristate "Trident 4D-Wave DX/NX; SiS 7018"
- depends on SND && GAMEPORT
+ depends on SND
help
Say 'Y' or 'M' to include support for Trident 4D-Wave DX/NX and
SiS 7018 soundcards.
--
Muli Ben-Yehuda
http://www.mulix.org