[alsa-devel] [patch] 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?
At Sat, 17 May 2008 02:14:12 +0400, Stas Sergeev wrote:
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.
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
[2 pcsp_exp.diff <text/x-patch (7bit)>] # HG changeset patch # User Stas Sergeev stsp@users.sourceforge.net # Date 1210975452 -14400 # Node ID 49d310de8ac42e5c495cf39440f4fde307b39c75 # Parent 3887126bbd9ca422208e651d46f9f5385d409efe snd-pcsp: depend on CONFIG_EXPERIMENTAL
Signed-off-by: Stas Sergeev stsp@aknet.ru
diff -r 3887126bbd9c -r 49d310de8ac4 drivers/Kconfig --- a/drivers/Kconfig Fri May 16 22:01:53 2008 +0400 +++ b/drivers/Kconfig Sat May 17 02:04:12 2008 +0400 @@ -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
On 17-05-08 08:52, Takashi Iwai wrote:
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.
A few months ago a switch HG->GIT was announced/considered:
http://mailman.alsa-project.org/pipermail/alsa-devel/2008-February/005914.ht...
That hasn't yet happened then?
Rene.
At Sat, 17 May 2008 10:01:50 +0200, Rene Herman wrote:
On 17-05-08 08:52, Takashi Iwai wrote:
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.
A few months ago a switch HG->GIT was announced/considered:
http://mailman.alsa-project.org/pipermail/alsa-devel/2008-February/005914.ht...
That hasn't yet happened then?
Not quite yet...
Takashi
On Sat, May 17, 2008 at 02:14:12AM +0400, Stas Sergeev wrote:
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
Hello.
Adrian Bunk wrote:
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?
On Sat, May 17, 2008 at 02:45:27PM +0400, Stas Sergeev wrote:
Hello.
Adrian Bunk wrote:
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
On 17-05-08 12:45, Stas Sergeev wrote:
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).
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.
On Sat, May 17, 2008 at 12:01 PM, Rene Herman rene.herman@keyaccess.nl wrote:
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
At Sun, 18 May 2008 01:57:05 -0400, Lee Revell wrote:
On Sat, May 17, 2008 at 12:01 PM, Rene Herman rene.herman@keyaccess.nl wrote:
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
participants (5)
-
Adrian Bunk -
Lee Revell -
Rene Herman -
Stas Sergeev -
Takashi Iwai