Bug 827655

Oh, the module isn't loaded, it's a "dead" device node, supposed to trigger the
loading of the module at access/open. "Dead" nodes have no dynamic ACL handling.

An ordianary user has no access rights to access it,  so it can not trigger the loading.

I have no good idea at this moment to make this work.

What you should be able to work around it, is:
  $ echo snd_seq > /etc/modules-load.d/seq.conf

which should force-load the module at bootup, and the ACL logic will find it
as a real device.

(In reply to comment #1)
> Oh, the module isn't loaded, it's a "dead" device node, supposed to trigger
> the
> loading of the module at access/open. "Dead" nodes have no dynamic ACL
> handling.
> 
> An ordianary user has no access rights to access it,  so it can not trigger
> the loading.
> 
> I have no good idea at this moment to make this work.
> 
> What you should be able to work around it, is:
>   $ echo snd_seq > /etc/modules-load.d/seq.conf
> 
> which should force-load the module at bootup, and the ACL logic will find it
> as a real device.

Hmmm, I could swear I did a chmod 666 and it worked, probably that is enough to trigger loading?)...

We have to find how this was done in Fedora 16, this was working before and is not working now, it is a regression that should be fixed. This should be part of whatever loads the sound modules, right? If a soundcard is found and it has a midi interface snd-seq should be loaded.

(In reply to comment #1)
> Oh, the module isn't loaded, it's a "dead" device node, supposed to trigger
> the
> loading of the module at access/open. "Dead" nodes have no dynamic ACL
> handling.

Here, right?:

/lib/udev/rules.d/50-udev-default.rules:  OPTIONS+="static_node=snd/seq", OPTIONS+="static_node=snd/timer"

Hmmm, but that is the same in fc16 and fc17
Aha, in fc16:

/etc/modprobe.d/dist-alsa.conf:

install snd-pcm /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe snd-seq

In Fedora 16 this was part of module-init-tools but in Fedora 17 that package is obsoleted by "kmod" which has no rules included. 

I guess we could do this in two ways:
a) we always load snd-seq (as suggested in comment #1)
b) we load snd-seq only if a soundcard exists in the system

I would be inclined to go with a) as you strictly don't need a working soundcard to do MIDI processing or start a MIDI aware program. 

In which case: who (which package) should take care of this? kmod?? alsa-lib? Looks like alsa-lib to me as if that is not installed we can't use the ALSA sequencer interface anyway (if we do add this to alsa-lib that we have to have a post-install script that loads snd-seq anyway as it can't be dynamic).

(In reply to comment #3)
> (In reply to comment #1)
> > Oh, the module isn't loaded, it's a "dead" device node, supposed to trigger
> > the
> > loading of the module at access/open. "Dead" nodes have no dynamic ACL
> > handling.
> 
> Here, right?:
> 
> /lib/udev/rules.d/50-udev-default.rules:  OPTIONS+="static_node=snd/seq",
> OPTIONS+="static_node=snd/timer"
> 
> Hmmm, but that is the same in fc16 and fc17
> Aha, in fc16:
> 
> /etc/modprobe.d/dist-alsa.conf:
> 
> install snd-pcm /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe
> snd-seq
> 
> In Fedora 16 this was part of module-init-tools but in Fedora 17 that
> package is obsoleted by "kmod" which has no rules included. 
> 
> I guess we could do this in two ways:
> a) we always load snd-seq (as suggested in comment #1)
> b) we load snd-seq only if a soundcard exists in the system
> 
> I would be inclined to go with a) as you strictly don't need a working
> soundcard to do MIDI processing or start a MIDI aware program. 
> 
> In which case: who (which package) should take care of this? kmod??
> alsa-lib? Looks like alsa-lib to me as if that is not installed we can't use
> the ALSA sequencer interface anyway (if we do add this to alsa-lib that we
> have to have a post-install script that loads snd-seq anyway as it can't be
> dynamic).

Maybe here? (part of alsa-lib):

more /usr/share/alsa/alsa.conf.d/README
You can place files named *.conf in this folder and they will be processed
when initialising alsa-lib.

(In reply to comment #2)
> (In reply to comment #1)
> 
> Hmmm, I could swear I did a chmod 666 and it worked, probably that is enough
> to trigger loading?)...
> 

I verify that chmod 666 works. At least it takes things one step further. I have similar problems with /dev/rtc which is a symlink to /dev/rtc0. I had to chmod 666 /dev/rtc0 as well. Then I had to bump /sys/class/rtc/rtc0/max_user_freq from 64 to 1024 to get things working. The question is, how to do all these things properly, with minimal user intervention.

(In reply to comment #5)
> (In reply to comment #2)
> > (In reply to comment #1)
> > 
> > Hmmm, I could swear I did a chmod 666 and it worked, probably that is enough
> > to trigger loading?)...
> > 
> 
> I verify that chmod 666 works. At least it takes things one step further. I
> have similar problems with /dev/rtc which is a symlink to /dev/rtc0. I had
> to chmod 666 /dev/rtc0 as well. Then I had to bump
> /sys/class/rtc/rtc0/max_user_freq from 64 to 1024 to get things working. The
> question is, how to do all these things properly, with minimal user
> intervention.

Why on earth do you want /dev/rtc to be world writeable???

Sorry, I have to make a correction. It is sufficient to have /dev/rtc as 444. However it is 600 in the default Fedora 17 installation.

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > Oh, the module isn't loaded, it's a "dead" device node, supposed to trigger
> > > the
> > > loading of the module at access/open. "Dead" nodes have no dynamic ACL
> > > handling.
> > 
> > Here, right?:
> > 
> > /lib/udev/rules.d/50-udev-default.rules:  OPTIONS+="static_node=snd/seq",
> > OPTIONS+="static_node=snd/timer"
> > 
> > Hmmm, but that is the same in fc16 and fc17
> > Aha, in fc16:
> > 
> > /etc/modprobe.d/dist-alsa.conf:
> > 
> > install snd-pcm /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe
> > snd-seq
> > 
> > In Fedora 16 this was part of module-init-tools but in Fedora 17 that
> > package is obsoleted by "kmod" which has no rules included. 
> > 
> > I guess we could do this in two ways:
> > a) we always load snd-seq (as suggested in comment #1)
> > b) we load snd-seq only if a soundcard exists in the system
> > 
> > I would be inclined to go with a) as you strictly don't need a working
> > soundcard to do MIDI processing or start a MIDI aware program. 
> > 
> > In which case: who (which package) should take care of this? kmod??
> > alsa-lib? Looks like alsa-lib to me as if that is not installed we can't use
> > the ALSA sequencer interface anyway (if we do add this to alsa-lib that we
> > have to have a post-install script that loads snd-seq anyway as it can't be
> > dynamic).
> 
> Maybe here? (part of alsa-lib):
> 
> more /usr/share/alsa/alsa.conf.d/README
> You can place files named *.conf in this folder and they will be processed
> when initialising alsa-lib.

If this is not going to or cannot be fixed in udev, what is the best way to move forward?

Should I file a new bug against a different component? Should this bug be moved to a different component? Alsa-lib perhaps?

I would say we should move this to some other component, kernel or alsa-lib I suppose.

python-alsa-1.0.26-1.fc17, alsa-plugins-1.0.26-1.fc17, alsa-tools-1.0.26.1-1.fc17, alsa-utils-1.0.26-1.fc17, alsa-lib-1.0.26-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/python-alsa-1.0.26-1.fc17,alsa-plugins-1.0.26-1.fc17,alsa-tools-1.0.26.1-1.fc17,alsa-utils-1.0.26-1.fc17,alsa-lib-1.0.26-1.fc17

Package python-alsa-1.0.26-1.fc17, alsa-plugins-1.0.26-1.fc17, alsa-tools-1.0.26.1-1.fc17, alsa-utils-1.0.26-1.fc17, alsa-lib-1.0.26-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing python-alsa-1.0.26-1.fc17 alsa-plugins-1.0.26-1.fc17 alsa-tools-1.0.26.1-1.fc17 alsa-utils-1.0.26-1.fc17 alsa-lib-1.0.26-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-13658/python-alsa-1.0.26-1.fc17,alsa-plugins-1.0.26-1.fc17,alsa-tools-1.0.26.1-1.fc17,alsa-utils-1.0.26-1.fc17,alsa-lib-1.0.26-1.fc17
then log in and leave karma (feedback).

python-alsa-1.0.26-1.fc17, alsa-plugins-1.0.26-1.fc17, alsa-tools-1.0.26.1-1.fc17, alsa-utils-1.0.26-1.fc17, alsa-lib-1.0.26-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.