Okay, two more crazy 12.2 problems.

1. Xorg.0.log error messages.

The following messages now appear in Xorg.0.log:

(EE) Error compiling keymap (server-0)
(EE) XKB: Couldn't compile keymap

This messages do not appear in 12.1. I use the 177.82 proprietary nvidia drivers in both setups as well as the same xorg.conf (I have a multiple partition system and can boot into either).

The messages appear with the generic nv driver in 12.2.

Any ideas of the cause and cure?

2. When I start X as root I lose all sound.

I have to restart the alsa service and then all is fine. Sound is available in the console before I run startx but not after X loads. After I restore the alsa service, I can exit X and sound is okay from the command line, but when I head right back into X, sound is gone again until I restart alsa.

After starting X as root there also is no sound in other desktops or consoles. Doesn't matter whether I run the first X desktop as root or start a second desktop as root.

This problem does not occur in 12.1 or with normal user accounts in 12.2.

Same results in KDE or Xfce.

Any ideas of the cause and cure?

Thanks again.

P.S. Oh and puhleeze: Don't preach to me or share your religion about running X as root. Take a long walk on a short pier. Kiss off. FOAD. GTFO. Blow smoke. Stick it where the sun doesn't shine. In your ear with a can of beer. Etc., etc. If I had mental issues about running as root I would not be using Slackware. I'd use Ubuntu and sudo myself into the insane asylum. But thanks for caring.

Heh-heh, thanks for making my day:-) Very funny stuff, I enjoyed this a lot.
Good luck with the nvidia issue. Can anyone help Woodsman? Bump.

Hi,
Niceties accepted!

First, I don't use Nvidia but have you tried new drivers?

As for the alsa root, after the 'alsaconf' for your system you then stored the setup after setup?

You posted similar problem before.
Did you find the solution last time?

Are you saying that the messages appear regardless of whether or not you use "nvidia" or "nv" in your xorg.conf video driver section, or just "nv"? It does not make sense if you are saying you use "nv" all the time with the proprietary modules installed.

You might try backing up your xorg.conf and rerunning your favorite X setup program such as xorgsetup or xorgconfig. Does your keyboard and everything work fine still?

I'm using the 177.82 drivers --- about as new as they can be without going beta.

I thought I did, but I made the mistake of posting late at night way past my sheep-counting time. I'll run the gamut again and test again.

Well, boink! I thought the problem sounded familiar. My middle-aged brain is slowing! I searched the web for similar discussions, but must have missed my own original post.

No, I never resolved the original problem and now the problem seems to affect runlevel 3 too.

Yes, I'm saying happens with both drivers. I keep an nv xorg.conf handy specifically for troubleshooting nvidia issues. I toggle between both setups to verify whether a problem is unique to the nvidia drivers or common.

I could try that. Possibly there is something oh-so-slightly different with the new kernel and new nvidia drivers. Keyboard and mouse work fine.

I'm going to tackle both of these again more methodically and I'll post further thereafter. I always have had a nice pristine, error-free xorg log.

Just to be sure, I again ran alsaconf, alsamixer, alsactl store. Same results. Sound disappears when I start X as root, returns when I restart alsa while still in X. Exit and restart X as root and sound disappears again. Repeatable.

No such issue when starting X as non-root.

I can start X as non-root, satisfactorily test the sound, then toggle to a different console, start X as root, and sound disappears for both users. Repeatable.

I started X and ran aplay through strace to a text file. I then ran alsa restore, which restored sound and repeated the aplay through strace. I found no meaningful difference. Yet when starting X as root something kills sound.

I compared lsmod before and after starting X. No meaningful difference.

Any ideas of other tests to run?

====================

After hours of testing I have beat the xorg error problem to death. No luck.

I created a new xorg.conf using xorgsetup. Initially I saw no more errors and then boom, they returned. I thought the problem might be related to an insufficent number of alternate keyboard layouts specified by the XkbLayout option. Initially the solution seemed to be having four layouts. Yet after many repeated restarts of X the error messages eventually reappeared.

In the end I decided the XkbLayout option had no affect. Whether I had no layouts defined or four, eventually I received the errors.

This happens with both the nvidia and nv drivers. As root or non-root.

I even tested with the vesa driver. Same results.

I restarted X through Xfce about two dozen times and could not repeat the errors. Although inconclusive, and based upon my previous thread where at that time this occurred only in runlevel 4, I'm leaning toward this being a KDE problem, not X. Only now this problem has infected runlevel 3 too.

I'm not totally convinced the problem did not previously exist in runlevel 3 with 12.1 and KDE 3.5.9. Perhaps I simply never saw the errors then. Just to be sure, I booted into 12.1 and restarted X about two dozen times. I never saw the error messages. For now I'll presume the errors occurrred in 12.1/3.5.9 only in runlevel 4, but now occur randomly in runlevel 3 and 4.

I repeated as many variations of tests I could imagine. I can restart X a dozen times before the errors appear. I can restart only once and the errors appear. There is no pattern to when the errors appear.

Any ideas for further testing?

make sure you have your user has audio permisions. other wise you will have to keep restarting the sound for him. if that does not work do like I did with 12.1 it was a corupt aor a lock file in kde i just deleted my .kde file did a log out logged it set it up again. then the kernel. is this.
here is what you need to do go to http://slackbuilds.org/result/?search=nvidia&sv=12.2
get the package there nvidia has a patch for the 2.6.27 kernel. do not do it like i did and spend hours reading on nvidia patch files.just go here build it. if the nvida configure program does not install with the modules do like I did. cd /tmp/ nvida build file and run nvidia installer. this has to be done in runlevel 3 and as root. reboot have fun. so after you build the module and pktool it in. if you do not have the nvidia setings tool such as nvidia-setting and nvidia-xorgconf. then do like I said runlevel 3 as root cd /tmp and the name of your kernel build file. there you will see the compiled package. type ./nvidia-installer and then it is all as usuall. on my upgrade I did not have to do this because nvidias bionary tools were already installed but on a new install I had to do the plus remove gspca_main black list it then compile max's gspca to get my old cam to work good luck. I guess the reason why it did not install with the module is the build scripts

My regular user account is a member of the audio group. As I posted above, I'm running the 172.82 nvidia drivers. I have been using the build script from slackbuilds.org for a long time. Good advice for many audio and video problems, but I don't think those suggestions will help with my original post.

A suggestion: This forum is an international forum. Many users do not claim English as a native language yet posting here requires English. You might be such a person. Rather than using netspeak or texting, add a bit of affection to your message posts by using basic English grammar and writing skills. Proper capitalization, punctuation, paragraph breaks, and spell checking will help many of the people who do not use English natively. Your advice might be what somebody is seeking but without readability might go unnoticed.

So, the sound issue is only a problem when logging into X as root. Why not try adding root to those special groups (eg. audio) as well. I don't see how it could hurt as root cannot have perms limited by group membership (as in Windows).

Also, when logged into X as root try opening the KDE mixer settings and make sure they are good. Check the audio server settings as well. Perhaps trying to turn off the session restore feature in X would help.

Are there some significant difference in the ~/.profile or ~/.Xresources? I would read through them and also the /etc/profile. I know root has some changes for them (such as PATH), but I have not read them recently.

As a workaround, you could just write a small script that is autostarted when root logs into X that will restore your settings. This could be at the end of your ~/.xinitrc or another place specific to your DE/WM (such as ~/.kde/Autostart).

--------------------------------
For your X errors:

Is this a problem with all users or just root again?

Could you please show us the keyboard section of your /etc/X11/xorg.conf?

If it is only a kde problem why not move your ~/.kde directory to a backed up place such as ~/.kde.bak and start kde with a clean profile. Let us know if you still have the problem.

Also I found these in the X man page
Perhaps you could play with some of those options (at least the ones in bold. If nothing else perhaps a debug would give you more information to work with.

I found this interesting, though not very helpful link using a quick google search.

Finally, you have had these X errors since the last Slackware version, and other than the messages themselves you never saw any symptoms from them. You still have no problems other than the messages themselves. Perhaps this would be something worth letting go if we cannot find a satisfactory solution.

Root is already a member of those groups.

Mixer settings are okay. The moment I run alsa restore sound is fine again for root.

I never use session saving.

~/.bash_profile is the same as other accounts. I don't use ~/.Xresources.

I thought of that too, but unlikely to be a path problem. The moment I run alsa restore all is well.

Yes, I know. Seems wrong though to Band-Aid something that should not occur in the first place.

All. And random. I cannot predict when the messages appear.

I disabled all the KDE keyboard maps and xkb options. Same result. Error messages appear, and sometimes they don't.

I tried changing the keyboard to pc105 with the same results.

I tried that, but I'll test again.

I'll try that.

Yes, I saw some threads like that too. I tried various ideas from those threads.

Yes, they are harmless, or seem to be. But again, they should not be there.

Thanks for taking time to help!

Try taking out all of the "Option ..." stuff and restart X (AutoRepeat is probably OK).

If you still get the errors then add
What kind of keyboard are you using?

Problem No. 1 (Weird Xorg.0.log Errors) Possibly Solved

This is one for Ripley's Believe It or Not. After a couple of hours trying various things and testing files, I might have narrowed the problem to enabling NumLock in KDE. Crazy. When I enter the Control Center and in Peripherals/Keyboard I select either Turn off or Leave unchanged, then after a couple of dozen times of restarting X/KDE I don't see the errors. When I change the option to Turn on then I see the errors, although as I mentioned previously, the errors are random and do not appear every restart of X/KDE. I have found no pattern to when the errors appear. Second, a couple of dozen restarts is insufficient to conclusively say that is the cause. I think I'll write a script to check for the error messages when I start KDE and pop up a message box. Then I'll run several days with each of the three options to see whether I can repeat the problem with certainty.

The sore part is I am a NumLock user. According to the KDE Help, selecting Leave unchanged should leave the status of NumLock to whatever the status is when starting KDE. I have NumLock enabled in console mode and KDE is supposed to respect that. Yet with the Leave unchanged option selected, every other time when I restart KDE NumLock get disabled.

I might try that too.

A classic Northgate OmniKey Ultra-T! The keyboard is so rugged that after 17 years none of the paint on the keycaps has yet to wear. I have a spare too, just in case.

Problem No. 2 (No audio as root in X) Solved!

I decided to again test a new ~/.kde directory. I'll be doggoned but sound returned for root. About a half hour of testing various config files, I narrowed the problem to one file: ~/.kde/share/config/kmixctrlrc. There is a similar file named kmixrc. I don't know why there are two files but the kmixctrlrc file was the problem. No more sound problems after deleting that one file. I also checked kmix visually and I saw nothing unusual. Something in that file was corrupt. I'll shrug over exactly what. Problem solved. Woo-hoo!

Maybe a really stupid suggestion but you never know until you try.

Install numlockx from SlackBuilds. The only way I could get it to work was by adding it to autostart in Xfce (4.5.92) and not the recommended way by editing the .xinitrc(s).

My numlock LED does not turn on but I can still 10-Key.......

A worthy experiment?? Maybe it will get rid of your errors?

Mystery Solved But No Solution

(EE) Error compiling keymap (server-0)
(EE) XKB: Couldn't compile keymap

The errors are caused by enabling Num Lock in KDE.

The errors appear inconsistently and seemingly at random. Expect these random messages if Num Lock is enabled from the Control Center or in the KDM login manager configuration file kdmrc. One workaround should be to set Num Lock to Leave unchanged, but this option fails about half the time. Contrary to intent, with that option KDE does not always honor the previous state of the Num Lock key, either when starting KDE from the console or even when switching virtual terminals or users. Using the popular NumLockX utility does not work because the KDE code is basically the same thing.

I ran across a blurb that using NumLockX in KDE was unnecessary because the KDE code essentially was the NumLockX code.

As mentioned in my previous post, predicting when these messages appear is impossible. There probably is a timing issue in the code, parallel or background tasks or something like that. Sometimes there are no error messages, sometime there are.

I installed NumLockX and inserted the command in xinitrc. Suddenly the messages appears more frequently, although again, never with perfect consistency.

I then removed NumLockX from xinitrc and placed the command in a desktop file in my KDE Autostart directory. I saw similar results in that the errors appeared more often but sometimes they did not.

The only method that seems to eliminate the error messages was not using Num Lock in any manner.

Then I ran a final test. I started KDE and from either a terminal command line or the KDE Run box, I manually ran NumLockX. I then inspected the Xorg.0.log. Every time I manually ran NumLockX, the error messages appeared. The cause of the error messages is enabling Num Lock. With this method I was able to create the error messages every time.

This information now also ties into my previous thread when I saw the error messages only from runlevel 4. In the KDM login manager configuration file kdmrc, there is an option to enable Num Lock.

Something has changed in the X source code that sometimes conflicts with the KDE Num Lock code functions.

Worse, as I have known for a long time, Num Lock is more or less broken in KDE. As long as I remain within my own user session there are no problems. Toggle to another console or KDE user session, and KDE often forgets both user's Num Lock setting. As I mentioned, if the user sets the Control Center Num Lock option to Leave unchanged, about half the time KDE fails to honor the current Num Lock setting. I have Num Lock enabled in my console tty and the Leave unchanged option should leave Num Lock as is. About half the time Num Lock gets disabled. I can verify this both with the LED and when I test NumLockX in xinitrc. KDE would toggle Num Lock off, although not configured to do that, and then NumLockX would reenable Num Lock. I use the KDE toggle keys utility which emits a barely audible beep when either the Caps Lock or Num Lock key is toggled. KDE would disable Num Lock despite being set to Leave unchanged and then I'd hear the tiny beep as NumLockX enabled Num Lock.

The Num Lock LED has never worked correctly in KDE. Toggle to another user's session and even if both users have Num Lock enabled, the LED will extinguish upon returning to the first user's session.

There is something amiss in the KDE Num Lock code.

There is no solution to eliminate the error messages if a user wants to use Num Lock in KDE.

Well, mystery solved although there is no cure.