Skip to contentSkip to conversation

snd-pcsp: depend on CONFIG_EXPERIMENTAL

PATCH Applied Stas Sergeev 5 participants 10 messages May 16, 2008 – May 18, 2008

lore
Share & tools
lore

Stas Sergeev

author
#0 lore raw

PATCH 1/1 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

Signed-off-by Stas Sergeev <[email protected]>
drivers/Kconfig +1 -0
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

Applied
#1 lore raw

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

Quoted 9 lines · Stas Sergeev

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?

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

Quoted 4 lines

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?

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

Quoted 21 lines

[2 pcsp_exp.diff <text/x-patch (7bit)>]
# HG changeset patch
# User Stas Sergeev <[email protected]> # Date 1210975452 -14400
# Node ID 49d310de8ac42e5c495cf39440f4fde307b39c75 # Parent 3887126bbd9ca422208e651d46f9f5385d409efe
snd-pcsp: depend on CONFIG_EXPERIMENTAL

Signed-off-by Stas Sergeev <[email protected]>

diff -r 3887126bbd9c -r 49d310de8ac4 drivers/Kconfig

drivers/Kconfig +1 -0
@@ -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
#4 lore raw
In reply to Stas Sergeev
Quoted 7 lines · Stas Sergeev

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. :)
...

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

Signature · 4 lines
       "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
author
#5 lore raw

Hello.

Quoted 3 lines · Adrian Bunk

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...

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?

#6 lore raw
Quoted 9 lines · Stas Sergeev

Hello.

Quoted 3 lines · Adrian Bunk

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...

So do you think it should depend
on CONFIG_BROKEN?
...

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

Signature · 4 lines
       "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
#3 lore raw
In reply to Rene Herman

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

Quoted 7 lines · Rene Herman
Quoted 3 lines · Takashi Iwai

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.

Quoted 5 lines

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?

Not quite yet...

Takashi

#7 lore raw
In reply to Stas Sergeev
Quoted 6 lines · Stas Sergeev
Quoted 3 lines

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...

So do you think it should depend
on CONFIG_BROKEN?

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).

Quoted 4 lines

The other possibilities, like hardcoding the index value as Andreas Mohr suggested, are also interesting. Can someone please comment if this is acceptable?

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.

#8 lore raw
Quoted 4 lines · Rene Herman

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).

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

#9 lore raw

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

Quoted 10 lines · Lee Revell
Quoted 4 lines · Rene Herman

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).

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...

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