Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#1529 - More user-friendly sound config + faqs
Attached to Project:
Arch Linux
Opened by Steven Van Impe (stevenvanimpe) - Sunday, 26 September 2004, 08:23 GMT
Last edited by Judd Vinet (judd) - Monday, 27 September 2004, 17:14 GMT
Opened by Steven Van Impe (stevenvanimpe) - Sunday, 26 September 2004, 08:23 GMT
Last edited by Judd Vinet (judd) - Monday, 27 September 2004, 17:14 GMT
|
DetailsLots of people seem to have problems getting their sound to work in Arch. I propose the following:
* Add the sound devices to a group 'sound'. In the current udev permissions, these are set to root. * Put a note in the installation guide or FAQ that users should add their account to the sound group if they want sound. * The fact that stuff like Rhythmbox asks for /dev/dsp is due to a not-so-sane GStreamer default config: it's default sink is set to OSS. Just use the 'Multimedia Systems Selector' to switch it to ALSA or ESD and all will be well (if you use ESD, don't forget to set the 'sound server at startup' check in Fnome's sound configuration). * This way, you don't need the oss compat modules anymore (unless you use really old or unmaintained software, like some games). I'm using a fresh arch install with gnome from testing. |
This task depends upon
This is even trickier to fix. I tried modifying /etc/devsd.conf to add the following:
REGISTER dri/.* PERMISSIONS root.users 660
But that didn't work. /dev/dri doesn't get created until later, when X loads, and the register line gets totally ignored. I have to do change the group manually before loading X to get around the problem.
David: I'm not sure why your devfsd rule isn't working. It should take effect even if the module gets loaded some time after boot-up.
Maybe I never rebooted, so it was still using the old conf file? I thought I did, though.
I'll check again on Monday. That's my work box, so I don't have access to it over the wkend.
[darose@wnyc190562661 ~]$ ls -l /dev/ | less
total 0
lr-xr-xr-x 1 root root 10 2004-11-08 09:01 adsp -> sound/adsp
lr-xr-xr-x 1 root root 12 2004-11-08 04:00 agpgart -> misc/agpgart
lr-xr-xr-x 1 root root 11 2004-11-08 09:01 audio -> sound/audio
drwxr-xr-x 1 root root 0 1969-12-31 19:00 cdroms
crw------- 1 root root 5, 1 2004-11-08 09:01 console
drwxr-xr-x 1 root root 0 1969-12-31 19:00 discs
drwxr-xr-x 1 root root 0 2004-11-08 09:01 dri
...
[darose@wnyc190562661 ~]$ ls -l /dev/dri
total 0
crw-rw---- 1 root root 226, 0 2004-11-08 09:01 card0
Very strange.
Do I have my rule set up wrong?
REGISTER dri/.* PERMISSIONS root.users 660
If not, then something funky is happening. Maybe the permissions are getting changed afterwards? Who knows. Anyone else seeing this behavior with /dev/dri? Maybe someone can try loading dri in X and see if they get this too.
+for the DRI device. That's because those permissions aren't set by udev. You specify them in a DRI
+section in your xorg.conf file instead:
Section "DRI"
Group "users"
Mode 0660
EndSection
Perhaps you want to add this info as a final comment onto this bug so that if someone else gets hit
+with this, there'll be a solution listed.