I've done quite a bit of searching, here and elsewhere, and just haven't seen anything else quite like this, and it's been ages since I've posted a question around here, so I figure I'm due.

I just bought a brand new Dell XPS m1330 and I'm running Slackware current (from an ISO made on 01/08/2008).

I know, I know. If it's in current, it's probably not stable. Humor me for a moment; I think this issue probably has a relatively simple configuration related solution, I'm just out of ideas as to what it might be.

Everything works great (well, except for the POS on-board Broadcom wired ethernet... but that's another story). Slackware-current as of 01/08/08 was on 2.6.23.12, and KDE 3.5.7. I've spent the better part of yesterday getting things installed, configured, and tweaked to the way I like them. I encountered an odd problem with sound that seems to be common on this laptop, based on my searching, where sound works fine through the headphone jack, but doesn't come out of the speakers.

I resolved this by downloading the latest stable Alsa source and compiled and installed it. Worked perfectly after that.

Since I had everything working, I edited /etc/inittab and switched from runlevel 3 to runlevel 4, using KDM as my login manager.

And then when I log into KDE from the login manager as a non-root user, sound no-worky. It squawks about "device /dev/dsp can't be opened (Permission denied)" or so it claims.

Ooooooo-kaaaay.

When I try to run "alsamixer" it comes back and says "alsamixer: function snd_ctl_open failed for default: no such device".

So this is clearly permissions related, since it works fine under root... but why should changing runlevel have anything to do with this?

When I switch back to runlevel 3 I can log in as a non-root user and "startx" to fire up KDE and sound works fine.

Any suggestions as to what I permissions should be looking at? It surely couldn't be permissions directly on /dev/dsp, could it?

Is there anything out of place in /etc/rc.d/rc.4? Otherwise it is quite strange that it works fine in runlevel 3, but not 4...

Good thought, but nope.

/etc/rc.d/rc.4 looks identical to the rc.4 file on my other (older) laptop running Slackware 12, and I've never had issues with that one in runlevel 4.

It's funny, too, because it only seems to be sound that's affected by this... nothing else. Everything else works fine as a non-root user in runlevel 4.

Bizarre.

To be sure, I have no problem leaving this laptop in runlevel 3, I should add.

It just puzzles me as to why this would make a difference.

What about runlevel 1?

Did you make sure that the old alsa package was removed before the upgrade?

Uhhhhh.

No.

You think that might do it? I'm actually thinking it just might be a borked binary of KDM that's doing it.

I suppose I could completely blow away and completely reinstall alsa from scratch. It's not hard to do.

I am half afraid that might break things worse though. I have myself convinced that "runlevel 3 ain't so bad".

Haven't tried, but I'm not sure what runlevel 1 would accomplish. It works fine in runlevel 3, just not 4 (unless logging into KDE as root).



EDIT: For the hell of it, I just tried booting in runlevel 1. Sound works fine in KDE in runlevel 1, but that shouldn't be surprising; if it works in 3 it shouldn't have a problem in 1.

In your place I would go with disabling things in rc.4 until it (sound) works.

There isn't much in rc.4.... it fires up KDM, that's about it.

I've removed all traces of alsa and am in the process of installing everything alsa-related from source right now. We'll see if that does it, though I'm still skeptical it's an issue with KDM.

The only one thing affecting sound in KDE should be arts(d), which has lots of bugs.

Yeah, that's the other thing I haven't looked at yet, mostly because I don't know squat about arts(d). I've never had any problems with it, thankfully, but I know my way around alsa pretty well, and since alsa was one of the things I was monkeying with, I figured I'd start there.

Completely removing and reinstalling alsa didn't fix the situation. arts(d) is my next stop in troubleshooting this, I suppose.

I would imagine it has to have something to do with arts as well...maybe take a look at your settings in KDE...

I love a good story are you using the tg3 driver with your Broadcom card? Changing to that fixed a problem I was having with a workstation here.

Just out of curiosity, what are the permissions on /dev/dsp?