Thank god someone finally asked this question. It should have been the first thing to look at, being that it's a permissions problem with sound after all.

Just to be sure important details don't get left out, we need to know what the output of `ls -al /dev/sound` is in both runlevels.

Permissions on /dev/dsp are the first things I checked. They're exactly what they should be, 660.

I don't think it's a problem with arts; when I'm in KDE in runlevel 4 as a non-root user, /dev/dsp actually doesn't even exist.

At this point I'm fairly certain this is some kind of bug in KDM. Thanks for the suggestions though, guys.

I never actually managed to get the tg3 driver installed. I downloaded it from Broadcom's site, and it errored out on all kinds of crap on the build.

Why can't they just provide coherent drivers like everyone else? Their build process is defective and I didn't feel like debugging their scripts for them, so I gave up on it after wasting a couple of hours of my own time on it.

Wifi works (I'm using the Intel 3945 mini card), so I'm satisfied with that for now. Maybe someone else can reverse engineer whatever Broadcom POS is on this particular laptop (I haven't even been able to figure out which of about a dozen chipsets it is), but until then I'll have to put up with no wired ethernet support.

If that is so then try running XDM to see if it does the same thing. Maybe it isn't a KDM exclusive problem and if it is you will know another workaround. If it is KDM, perhaps see if you can change any configuration on it or run it manually to see if it has the same effect.

What's the output of lspci -vv?
http://hardware4linux.info/system/2101/

Yeah, I'm going to try that tonight and see if it's any different.

I'm at work at the moment, and I didn't bring my laptop with me today; I'll have to try that this evening after I get home.

I am also having trouble with sound in KDE on Slackware 12.
On some computers KDE astsd crashes with SIGSEGV.
I made a post in LinuxQuestons about this:
http://www.linuxquestions.org/questi...83#post2813783
Also check your permissions.
By default users have to belong to the 'audio' group to have access to sound.

You know, I keep seeing that, and I'd believe it, except for three things:

1) Sound works fine when I'm logged in as myself in runlevel 3

2) Sound works fine for non-root users on the other two machines on which I am running Slackware 12

3) There doesn't seem to be an "audio" group out of the box

really? Mine has it and I know I didn't add it. Anybody else not have audio as one of their groups under /etc/group?

My main user is a part of
with the last three groups being special groups I created.

This may not be your problem but I am curious.

Weird.

I'll look into it. Maybe I'm hosing something up in the way I worded my "usermod" command. I don't do that very often, so that very well could be the case.

On my system, they're 777 because /dev/dsp is a symlink to /dev/sound/dsp whose permissions are actually 662. This would explain why non-audio group users can write to the sound card on other setups.

I'm thinking that there may be a problem with the audio hardware (or detection of it) on this particular box.
There is an audio group. It has been there as long as I can remember.

Nope, I had my head up my ass. I did a "usermod -G audio myusername" and switched to runlevel 4 and it magically worked.

I had my syntax wrong on the usermod command before, which I do often (durrrrrrrrr).

Now, what I still don't get is why does sound work just fine in KDE at runlevel 3 if I wasn't a member of the audio group?



Baffling.

Thanks for the help though, guys. I appreciate it.

Have a look in /etc/login.defs - in run level 3, you're logging in to the console and you get membership of some groups for free:

Thank you, gilead. I think many people learned something from this, and we can now sleep soundly tonight