Re: please review alsaconf patch
On Wed, Nov 02, 2005 at 09:54:59PM +0100, Roland Stigge wrote: > Martin Habets wrote: > >>(1) $PROCFS was not defined, so I set it manually. I didn't know where > >>you intended it to come from so I just set it in the beginning of the > >>patch to /proc. > > > > It is set at line 30 of the script. Maybe you are using an old version of > > alsconf? > > The one from unstable, and indeed the experimental version sets $PROCFS. > But that shouldn't make a difference for the other points. I need to > stick with unstable; for my taste, it's unstable enough. ;) Ok, that explains. I created the patch against ALSA 1.0.10rc1, as it will go into ALSA CVS. From there it will be picked up by all distro's. So it will be a while before this hits debian stable :) > >>(2) I guess you meant mounting openpromfs in case /proc/openprom exists? > >>Therefore && instead of ||. > > > > I meant to mount it if it has not been mounted yet. Fixed the code for this. > > Wouldn't it even better if we leave the system in the state we found it? > I.e. unmounting in the end if mounting in the beginning. Yes that would be better, but I consider that a bit overkill. -- Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please review alsaconf patch
Martin Habets wrote: >>(1) $PROCFS was not defined, so I set it manually. I didn't know where >>you intended it to come from so I just set it in the beginning of the >>patch to /proc. > > It is set at line 30 of the script. Maybe you are using an old version of > alsconf? The one from unstable, and indeed the experimental version sets $PROCFS. But that shouldn't make a difference for the other points. I need to stick with unstable; for my taste, it's unstable enough. ;) >>(2) I guess you meant mounting openpromfs in case /proc/openprom exists? >>Therefore && instead of ||. > > I meant to mount it if it has not been mounted yet. Fixed the code for this. Wouldn't it even better if we leave the system in the state we found it? I.e. unmounting in the end if mounting in the beginning. bye, Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please review alsaconf patch
On Tue, Nov 01, 2005 at 01:45:56PM +0100, Roland Stigge wrote:
> Hi,
>
> Martin Habets wrote:
> > Thanks for the info. I guess you must have an "audio" device on the
> > ebus then, and I failed to check for that in my original patch.
> > Could you try the patch attached in stead of the original one, please?
>
> Unfortunately, it didn't work out-of-the-box. With a bit of polishing I
> could at least make it run (see attached incremental patch to your changes).
>
> Some comments to the respective changes:
>
> (1) $PROCFS was not defined, so I set it manually. I didn't know where
> you intended it to come from so I just set it in the beginning of the
> patch to /proc.
It is set at line 30 of the script. Maybe you are using an old version of
alsconf?
> (2) I guess you meant mounting openpromfs in case /proc/openprom exists?
> Therefore && instead of ||.
I meant to mount it if it has not been mounted yet. Fixed the code for this.
> (3) Under /proc/openprom/[EMAIL PROTECTED],470/[EMAIL PROTECTED], I have
> a directory
> called "[EMAIL PROTECTED],20". Therefore, I needed to search for "audio*"
> instead of "audio".
>
> (4) The file "compatible" contains: "'SUNW,CS4231'" (with single
> quotes). I needed to remove them.
>
> Now, alsaconf detects the device fine. (Also consider FJP's comments on
> using modprobe.)
Thanks for testing and for the fixes.
> However, there are some issues left with my CS4231: On bootup, the
> modules are not loaded automatically (even hotplug doesn't care about
> them). So I need to put "snd-sun-cs4231" into /etc/modules. Further,
> when I want to play something (e.g., with xmms), I often (unpredictably)
> get (white?) noise. Retrying helps every 3rd or 4th time. Maybe
> alignment or endianess issues. But these are different issues and not
> related to alsaconf I think. If noone else has experienced this yet, I
> will need to dive into the driver myself later.
What kernel version are you on? A number of patches have been submitted
on the sparclinux list in the last 2 months, the last one on october 29th.
If you have those, it is best to follow up with Georg Chini on this.
Thanks,
Martin
---
--- alsaconf.orig 2005-10-31 13:02:07.0 +
+++ alsaconf2005-11-02 08:16:08.0 +
@@ -688,7 +688,8 @@
# PowerMac
#
if grep -q MacRISC $PROCFS/cpuinfo; then
- /sbin/modprobe -a -l | grep 'snd-powermac' | \
+ MODDIR=/lib/modules/`uname -r`
+ find $MODDIR -name 'snd-powermac' -print | \
while read i; do
i=${i##*/}
i=${i%%.o}
@@ -701,19 +702,22 @@
# Sparc
#
if grep -q Sparc $PROCFS/cpuinfo; then
- test -r $PROCFS/openprom || /bin/mount -t openpromfs none
$PROCFS/openprom >/dev/null 2>&1
+ test -r $PROCFS/openprom/name || /bin/mount -t openpromfs none
$PROCFS/openprom >/dev/null 2>&1
# Check for an "audio" device
audio=
compat=
if test -r $PROCFS/openprom; then
- audio=`find $PROCFS/openprom -follow -type d -name "audio" -print`
+ audio=`find $PROCFS/openprom -follow -type d -name "audio*" -print`
fi
if test -n "$audio"; then
compat=`cat $audio/compatible`
+ compat=${compat#\'}
+ compat=${compat%\'}
compat=${compat#SUNW,}
fi
# Go through all cards we have
- /sbin/modprobe -a -l | grep 'snd-sun-' | \
+ MODDIR=/lib/modules/`uname -r`
+ find $MODDIR -name 'snd-sun-*' -print | \
while read i; do
i=${i##*/}
i=${i%%.o}
@@ -1339,7 +1343,8 @@
if [ -s "$FOUND" ]; then
while read dev card ; do
- /sbin/modprobe -a -l | grep -q -E $card'\.(o|ko)' || continue
+ MODDIR=/lib/modules/`uname -r`
+ find $MODDIR -type f | grep -q -E $card'\.(o|ko)' || continue
cardname=`find_device_name $dev | cut -c 1-64`
if [ -z "$cardname" ]; then
cardname="$card"
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please review alsaconf patch
To be honest, I just copied that line from the powermac code. Wrong move it seems. I'll replace it with find as suggested. Thanks, Martin On Mon, Oct 31, 2005 at 02:43:57PM +0100, Frans Pop wrote: > On Monday 31 October 2005 14:11, Martin Habets wrote: > > + /sbin/modprobe -a -l | grep 'snd-sun-' | \ > > Hmmm. Is "-a -l" correct for modprobe? -l is supposed to list modules, -a > to insert (load) them... > I doubt that the intention here is to try to actually load all modules > available on the system, so why "-a"? Or am I missing something? > > From the manpage, -l takes a wildcard, thus why not just use > modprobe -l snd-sun-* > ? > > Also from the manpage it looks like both the -a and the -l options are > deprecated and using something like > find /lib/modules/$(uname -r)/kernel/ -name "snd-sun-*" > is suggested instead. > > Cheers, > FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please review alsaconf patch
Hi,
Martin Habets wrote:
> Thanks for the info. I guess you must have an "audio" device on the
> ebus then, and I failed to check for that in my original patch.
> Could you try the patch attached in stead of the original one, please?
Unfortunately, it didn't work out-of-the-box. With a bit of polishing I
could at least make it run (see attached incremental patch to your changes).
Some comments to the respective changes:
(1) $PROCFS was not defined, so I set it manually. I didn't know where
you intended it to come from so I just set it in the beginning of the
patch to /proc.
(2) I guess you meant mounting openpromfs in case /proc/openprom exists?
Therefore && instead of ||.
(3) Under /proc/openprom/[EMAIL PROTECTED],470/[EMAIL PROTECTED], I have a
directory
called "[EMAIL PROTECTED],20". Therefore, I needed to search for "audio*"
instead of "audio".
(4) The file "compatible" contains: "'SUNW,CS4231'" (with single
quotes). I needed to remove them.
Now, alsaconf detects the device fine. (Also consider FJP's comments on
using modprobe.)
However, there are some issues left with my CS4231: On bootup, the
modules are not loaded automatically (even hotplug doesn't care about
them). So I need to put "snd-sun-cs4231" into /etc/modules. Further,
when I want to play something (e.g., with xmms), I often (unpredictably)
get (white?) noise. Retrying helps every 3rd or 4th time. Maybe
alignment or endianess issues. But these are different issues and not
related to alsaconf I think. If noone else has experienced this yet, I
will need to dive into the driver myself later.
Thanks for now.
bye,
Roland
--- alsaconf.orig 2005-11-01 12:39:37.0 +0100
+++ alsaconf 2005-11-01 12:38:53.0 +0100
@@ -588,16 +588,19 @@
#
# Sparc
#
+PROCFS=/proc
if grep -q Sparc $PROCFS/cpuinfo; then
- test -r $PROCFS/openprom || /bin/mount -t openpromfs none $PROCFS/openprom >/dev/null 2>&1
+ test -r $PROCFS/openprom && /bin/mount -t openpromfs none $PROCFS/openprom >/dev/null 2>&1
# Check for an "audio" device
audio=
compat=
if test -r $PROCFS/openprom; then
- audio=`find $PROCFS/openprom -follow -type d -name "audio" -print`
+ audio=`find $PROCFS/openprom -follow -type d -name "audio*" -print`
fi
if test -n "$audio"; then
compat=`cat $audio/compatible`
+ compat=${compat#\'}
+ compat=${compat%\'}
compat=${compat#SUNW,}
fi
# Go through all cards we have
Re: please review alsaconf patch
On Monday 31 October 2005 14:11, Martin Habets wrote: > + /sbin/modprobe -a -l | grep 'snd-sun-' | \ Hmmm. Is "-a -l" correct for modprobe? -l is supposed to list modules, -a to insert (load) them... I doubt that the intention here is to try to actually load all modules available on the system, so why "-a"? Or am I missing something? From the manpage, -l takes a wildcard, thus why not just use modprobe -l snd-sun-* ? Also from the manpage it looks like both the -a and the -l options are deprecated and using something like find /lib/modules/$(uname -r)/kernel/ -name "snd-sun-*" is suggested instead. Cheers, FJP pgpbrvS2bIeMn.pgp Description: PGP signature
Re: please review alsaconf patch
Roland,
Thanks for the info. I guess you must have an "audio" device on the
ebus then, and I failed to check for that in my original patch.
Could you try the patch attached in stead of the original one, please?
This patch may also work for the AMD7930, and I would be gratefull if
someone with an AMD7930 could test it.
Thanks,
Martin
On Sun, Oct 30, 2005 at 07:40:49PM +0100, Roland Stigge wrote:
> Hi Martin,
>
> you wrote:
> > I created the patch below to make alsaconf work with the DBRI and
> > CS4231 chips. But I'm not sure if this will work for the AMD7930
> > chip. The patch tries to find a "SUNW,AMD7930*" directory in this
> > case, but I don't know if that exists. Can somebody with an AMD7930
> > sound chip confirm/deny this?
> >
> > Other feedback (like better approaches) is welcome too. I'll submit
> > it to Takashi once the AMD7930 issue is resolved.
>
> I tried with my CS4231 and that didn't work. Loading the module
> snd-sun-cs4231 manually works fine.
>
> Maybe the following debug output is of interest:
>
> # /sbin/modprobe -a -l | grep 'snd-sun-'
> /lib/modules/2.6.12-1-sparc64/kernel/sound/sparc/snd-sun-cs4231.ko
> /lib/modules/2.6.12-1-sparc64/kernel/sound/sparc/snd-sun-amd7930.ko
>
> /proc/openprom# find /proc/openprom -follow -type d -name "SUNW,*"
> /proc/openprom/packages/SUNW,builtin-drivers
> /proc/openprom/SUNW,[EMAIL PROTECTED],0
> /proc/openprom/[EMAIL PROTECTED],460/SUNW,[EMAIL PROTECTED]
> /proc/openprom/[EMAIL PROTECTED],448/SUNW,[EMAIL PROTECTED],0
>
> (On A SunBlade 1000.)
>
> So there's no 'SUNW,CS4231*' which results in the whole patch giving no
> output.
>
> Is this problem related to the above
>
> bye,
> Roland
---
--- alsaconf.orig 2005-10-25 16:00:11.0 +0100
+++ alsaconf2005-10-31 13:02:07.0 +
@@ -696,6 +696,40 @@
echo "PowerMac $i" >> $FOUND
done
fi
+
+#
+# Sparc
+#
+if grep -q Sparc $PROCFS/cpuinfo; then
+ test -r $PROCFS/openprom || /bin/mount -t openpromfs none
$PROCFS/openprom >/dev/null 2>&1
+ # Check for an "audio" device
+ audio=
+ compat=
+ if test -r $PROCFS/openprom; then
+ audio=`find $PROCFS/openprom -follow -type d -name "audio" -print`
+ fi
+ if test -n "$audio"; then
+ compat=`cat $audio/compatible`
+ compat=${compat#SUNW,}
+ fi
+ # Go through all cards we have
+ /sbin/modprobe -a -l | grep 'snd-sun-' | \
+ while read i; do
+ i=${i##*/}
+ i=${i%%.o}
+ i=${i%%.ko}
+ sdev=`echo ${i#snd-sun-} | tr "[a-z]" "[A-Z]"`
+
+ if test "$sdev" = "$compat"; then
+ echo "$sdev $i" >> $FOUND
+ elif test -r $PROCFS/openprom; then
+ find $PROCFS/openprom -follow -type d -name "SUNW,${sdev}*" \
+ -exec echo "$sdev $i" \; 2>/dev/null >> $FOUND
+ else
+ echo "$sdev $i" >> $FOUND
+ fi
+ done
+fi
}
#
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please review alsaconf patch
Roland Stigge wrote: > Is this problem related to the above Forget this line. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please review alsaconf patch
Hi Martin, you wrote: > I created the patch below to make alsaconf work with the DBRI and > CS4231 chips. But I'm not sure if this will work for the AMD7930 > chip. The patch tries to find a "SUNW,AMD7930*" directory in this > case, but I don't know if that exists. Can somebody with an AMD7930 > sound chip confirm/deny this? > > Other feedback (like better approaches) is welcome too. I'll submit > it to Takashi once the AMD7930 issue is resolved. I tried with my CS4231 and that didn't work. Loading the module snd-sun-cs4231 manually works fine. Maybe the following debug output is of interest: # /sbin/modprobe -a -l | grep 'snd-sun-' /lib/modules/2.6.12-1-sparc64/kernel/sound/sparc/snd-sun-cs4231.ko /lib/modules/2.6.12-1-sparc64/kernel/sound/sparc/snd-sun-amd7930.ko /proc/openprom# find /proc/openprom -follow -type d -name "SUNW,*" /proc/openprom/packages/SUNW,builtin-drivers /proc/openprom/SUNW,[EMAIL PROTECTED],0 /proc/openprom/[EMAIL PROTECTED],460/SUNW,[EMAIL PROTECTED] /proc/openprom/[EMAIL PROTECTED],448/SUNW,[EMAIL PROTECTED],0 (On A SunBlade 1000.) So there's no 'SUNW,CS4231*' which results in the whole patch giving no output. Is this problem related to the above bye, Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
