snd-pcsp: depend on CONFIG_EXPERIMENTAL

Hello.

Considering all the feedbacks I got, depending snd-pcsp on CONFIG_EXPERIMENTAL looks like the only safe way to get out of all the troubles at one go. :)

Can the attached patch be applied?

Btw, it seems to me that the alsa-kernel hg tree somehow lacks a few snd-pcsp patches that the alsa git tree has... how have that happened and how can be fixed?

# HG changeset patch
# User Stas Sergeev <[email protected]> # Date 1210975452 -14400
# Node ID 49d310de8ac42e5c495cf39440f4fde307b39c75 # Parent 3887126bbd9ca422208e651d46f9f5385d409efe
snd-pcsp: depend on CONFIG_EXPERIMENTAL

diff -r 3887126bbd9c -r 49d310de8ac4 drivers/Kconfig
@@ -6,6 +6,7 @@ menu "Generic devices"
 
 config SND_PCSP
 	tristate "Internal PC speaker support"
+	depends on EXPERIMENTAL
 	depends on X86_PC && HIGH_RES_TIMERS
 	depends on INPUT
 	depends on SND

_______________________________________________
Alsa-devel mailing list
[email protected]
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

At Sat, 17 May 2008 02:14:12 +0400,

Thanks, applied to my tree for the next push (maybe tomorrow) together with other two patches.

It's because I apply some patches first to my git tree so that it can be better sync'ed with Linus tree. I'll backport them to ALSA HG tree later.

So, if you work on 2.6.*-rc, please make a diff against git tree.

BTW, it'd be helpful if you put more texts in the changelog. I did cut-n-paste the mail text that looks suitable as changelogs, so far.

thanks,

Takashi

A few months ago a switch HG->GIT was announced/considered:

http://mailman.alsa-project.org/pipermail/alsa-devel/2008-February/005914.html

That hasn't yet happened then?

Rene.

At Sat, 17 May 2008 10:01:50 +0200,

Not quite yet...

Takashi

No objections against your patch, but considering that virtually everyone has EXPERIMENTAL enabled in his kernel it won't bring you out of any troubles...

cu
Adrian

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Hello.

So do you think it should depend
on CONFIG_BROKEN?
The other possibilities, like hardcoding the index value as Andreas Mohr suggested, are also interesting. Can someone please comment if this is acceptable?

If it is not yet ready for being shipped in a stable kernel.

But it's a new driver and the reported problems don't seem to be unfixable, so you could first try to get them fixed.

cu
Adrian

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

No, I wouldn't do that. It isn't all that broken it would seem (assuming
it will work for me after applying the patch you posted that should
make it work with older alsa-lib; haven't checked yet).

Generally I'd say totally unacceptable but this might in fact be a special case due to it being generic PC hardware and expected to be present therefore -- it might actually make some sense to reserve a #define SND_INDEX_PCSP MAXINT or some such so that this thing gets a stable index (and make sure people know to select it through its name like in "default:pcsp" and the like). I'd ask Takashi for comment on that...

Rene.

Or hardcode index 0, so the distros will have to fix any apps that address cards by number, use the /dev/dsp API, or assume that output to card 0 is a sane default...

Lee

At Sun, 18 May 2008 01:57:05 -0400,

Looks like the sound card enumeration is getting more painful nowadays. Ideally we can forget the loading order once if everything is ported to use the persistent device name. But, it's not easy -- you see even network devices eth0 and so.

BTW, with the recent kernel, you can specify "slots" option for snd module. It's a kind of global index, and should avoid the device enum mess, at least, for devices that have beel already configured since the devices that are listed in slots option will be kept safe. See ALSA-Configuration.txt for details.

Takashi