- Is there any damage
in startkde of running
kdetcompmgr as a background
task?
- What process started in startkde is
launching
kconf_update?
Why is kconf_update being launched?
Is there a way to prevent kconf_update
from
running?
What version of the nVidia drivers does Slackware
install?
The issue occurs within a very low level section
of code,
and I have not seen it on my Ubuntu systems in ages, thus I
suspect it may
be a known issue with older versions of the nVidia driver.
Slackware does not install any Nvidia packages. They
are left to the users
to build and install.
I am using 195.36.31 and have been for a long time.
That is what I'm using
on 3.5.10 too, where I don't see this behavior.
Is changing the Nvidia package the answer? Many people
are going to be
attracted to TDE because of the potential to run on
older hardware. If
those people have older Nvidia cards they will be
using legacy drivers.
I don't know. This particular bug would require a LOT of time to troubleshoot and I don't have that much time to offer for free at this point.
If anyone else wants to take a stab at it feel free!
Let's not focus yet on the bowels of the kdeinit code. Let's focus on the four questions I posed:
1. Is there any damage in startkde of running kdetcompmgr as a background task?
2. What process started in startkde is launching kconf_update?
3. Why is kconf_update being launched?
4. Is there a way to prevent kconf_update from running?
If I can throw a few snippets into the startkde script that will suffice for now.
As I mentioned, I can avoid the need for one of the killall commands if I run kdetcompmgr as a background task in startkde. I am unable to avoid the second killall command but there might be a workaround if I better understood why kconf_update is being launched and by what.
Apparently kconf_update is not being run in the same manner after the TDE profile is created because the stalls no longer occur. If I knew what to set in the new or migrated profile then I might be able to stop the stalls.
Darrell