On 03/22/2012 12:20 AM, Darrell Anderson wrote:
Recently David shared some issues with starting
Trinity. In his case the probable cause seemed to be stale profile cache file or profile
cache files using the old prefix names.
Today I stumbled across a way to stall the session startup. I changed some settings in
KControl.
What caught my eye with this bug is the xsession log error, which David saw as well:
ksmserver: '<wm>' missing.
ksmserver: Use --help to get a list of available command line options.
I traced the cause to these lines in my profile twinrc:
[ThirdPartyWM]
WMAdditionalArguments=
WMExecutable=twin
Those lines and group do not exist in a twinrc backup file and is the only difference
between the files.
This is not a hard freeze. Trinity exits gracefully back to the command line, which is
how I start X/Trinity.
The problem is with tdeinit_phase1. I commented out that command in starttde. I
successfully substituted all of the following:
kwrapper ksmserver --windowmanager twin --windowmanageraddargs ""
kwrapper ksmserver --windowmanager twin
kwrapper ksmserver
Looking at the tdeinit_phase1 source code, I see that when WMExecutable is
undefined/empty then tdeinit_phase1 defaults to "kwrapper ksmserver." As my
previous twinrc contained no ThirdPartyWM group in twinrc, that is how tdeinit_phase1
always started.
When I changed some settings in KControl to cause twinrc to update with including the
ThirdPartyWM group, tdeinit_phase1 instead starts with "kwrapper ksmserver
--windowmanager %1 --windowmanageraddargs %2."
Changing the twinrc WMAdditionalArguments to WMAdditionalArguments=--lock allowed Trinity
to start using tdeinit_phase1.
I think the solution then is to add the following condition test to tdeinit_phase1:
else if (wmArguments == "") {
return_code = system((TQString("kwrapper ksmserver --windowmanager
%1").arg(wmToLaunch)).ascii());
Comments?
Darrell
This is starting to make sense. On the session before I started experiencing
crashes with startted, I had updated the background to be displayed in kcontrol
-> login manager. I suspect what you were able to traceback more thoroughly that
I was the root cause of the crashes I experienced as well. Good catch!
--
David C. Rankin, J.D.,P.E.