[comp.sys.hp] Instant Ignition problems

evgabb@sdrc.UUCP (Rob Gabbard) (08/30/90)

I'm having the following problems with Instant Ignition on HP. Anyone else run
across these and find a workaround ?

	- On a device such as a Turbo SRX/VRX, you cannot modify
	  SB_DISPLAY_ADDR before running X Windows.  Normally we 
	  set this in /etc/profile or the user's .profile which were
	  run before typing .x11start. But now, with xlogin/xsession
	  the X server runs continoussly and there isn't a way to set
	  this variable. I tried setting in /etc/rc to no avail.

	  The one workaround I know of is to use the "No Windows" login
	  option. However, you lose all of the Instant Ignition functionality.

	- On a Turbo SRX running in combined mode with the color map full,
	  xhelp crashes when it cannot allocate its own colors in the default
	  colormap on an XQueryColors call.  My guess is that it is assuming you
	  have a 16-entry colormap since you have a 4 bit root, which is not 
	  true on the Trubo SRX.

	  I could probably tell it to use colors I have in my colormap but its
	  still a bug.


-- 

Rob Gabbard (uunet!sdrc!evgabb)  
Technical Development Engineer   
Structural Dynamics Research Corp

eric@hpfcda.HP.COM (Eric Flink) (09/05/90)

>	- On a device such as a Turbo SRX/VRX, you cannot modify
>	  SB_DISPLAY_ADDR before running X Windows.  Normally we 
>	  set this in /etc/profile or the user's .profile which were
>	  run before typing .x11start. But now, with xlogin/xsession
>	  the X server runs continoussly and there isn't a way to set
>	  this variable. I tried setting in /etc/rc to no avail.

This is a problem; you need to set the SB_DISPLAY_ADDR variable before X
starts, but xlogin does not pass down most environment variables to its
children.

However, there is a workaround which should fix the problem.  If you
make the server into a shell script, it can set up the appropriate
environment variables then exec the real X server.

For example, move /usr/bin/X11/X to /usr/bin/X11/X.real.  Then recreate
/usr/bin/X11/X as a shell script which looks like:

----------------- Cut Here -----------------
#!/bin/sh
#
# Shell script to set environment variables for the X server.

export SB_DISPLAY_ADDR
SB_DISPLAY_ADDR=XXX

exec /usr/bin/X11/X.real $*
----------------- Cut Here -----------------

Make sure this script is executable.  The "exec" is very important;
the xsession command needs to know the process id of the server to
correctly shut things down when you log out.

Note that this shell script will get clobbered if/when you update
the X Windows fileset on your system.

Hope this helps.


Regards,

Eric Flink

eric_flink@fc.hp.com
(303) 229-2313

This posting does not reflect the official position of Hewlett-Packard Company.

eric@hpfcda.HP.COM (Eric Flink) (09/05/90)

I should also add that you should set the SB_DISPLAY_ADDR in your
environment via the XSession*EnvironmentVariables resource.  Eg.

XSession*EnvironmentVariables: SB_DISPLAY_ADDR
XSession*SB_DISPLAY_ADDR:      <whatever>

Then each descendent of xsession will also see this variable.

-- Eric

jsd@esl.ESL.COM (Jeff Dalton) (09/07/90)

In article <970010@hpfcda.HP.COM> eric@hpfcda.HP.COM (Eric Flink) writes:
>
>However, thebe is a workaround which should fix the problem.  If you
>make the server into a shell script, it can set up the appropriate
>environment variables then exec the real X server.

So in general, there is now way for XSession to run with the environment
from a user (except thru the limited functionallity in .Xdefaults)?  And the
only way to change that is to set up an environment which the server starts
under?  Is this correct?

How does something like "umask" get set then?  Where does the initial value
come from?
-- 
Jeff Dalton, ESL Inc.                    Real programmers can write 
jsd@esl.com                                 Fortran in any language.

evgabb@sdrc.UUCP (Rob Gabbard) (09/10/90)

From article <324@esl.ESL.COM>, by jsd@esl.ESL.COM (Jeff Dalton):
> So in general, there is now way for XSession to run with the environment
> from a user (except thru the limited functionallity in .Xdefaults)?  And the

As you may have guessed from previous postings I have had several problems with
this. Another thing to watch out for when using the XSession.Env.... method is
that you cannot use environment variables IN environment variables. I do things
in my .profile like:

	if hp9000s300
	then
		CPUTYPE=motorola
	else
		CPUTYPE=precision
	fi
	export CPUTYPE

	PATH=/bin:/usr/bin:$HOME/local/bin/$CPUTYPE:
	export PATH

	This won't work since you have no way to set CPUTYPE via the .Xdefaults
method. It would work if Xsession would parse the .Xdefaults file in a manner
similar to xrdb by passing it through the C preprocessor first. Then the code
above would become:

	#ifdef hp9000s300
		XSession.CPUTYPE:	motorola
	#else
		XSession.CPUTYPE:	precision
	#endif

	XSession.HOME:			/u/joeuser
	XSession.PATH:			/bin:/usr/bin:$HOME/local/bin/$CPUTYPE:

Another workaround to these problems if you use the Korn or C shells is to place
some of the stuff you normally do in your .profile into your .cshrc or .kshrc
but this may cause a performance penalty when starting new shells or running
scripts (depending on what you do).

I hope HP has taken these problems into consideration for HP-VUE.

-- 

Rob Gabbard (uunet!sdrc!evgabb)  
Technical Development Engineer   
Structural Dynamics Research Corp

byrnes@hpfcda.HP.COM (John Byrnes) (09/11/90)

Rob Gabbard writes:
> 
> I'm having the following problems with Instant Ignition on HP. Anyone else run
> across these and find a workaround ?
> 
> 	- On a device such as a Turbo SRX/VRX, you cannot modify
> 	  SB_DISPLAY_ADDR before running X Windows.  [more deleted]
> 
> 	- On a Turbo SRX running in combined mode with the color map full,
> 	  xhelp crashes when it cannot allocate its own colors...[more deleted]
>

Rob,
     These are specific HP VUE issues and, besides just working around them
as Eric suggests, should be reported to Corvallis.  You might want to
DTS an enhancement request for these things (or a stronger weight :-) )
or just post your discontent on hp.windows.vue to get a response from
the VUE folks.  They've been responsive in the past on issues like this.

The reason I say this is that, if you can't figure it out, then our customers
certainly won't, especially since they don't have Eric's wizardry to tap into.

John Byrnes
(soon to be former) Instant Ignition project manager
Ft. Collins

byrnes@hpfcda.HP.COM (John Byrnes) (09/13/90)

> 
> Rob,
>      These are specific HP VUE issues and, besides just... [rest deleted]
>
Rob,

OOOPS!  When I posted my reply I (mistakenly) thought this was a HP-only
notes group (this is not one of my regular strings).  I apologize for
confusing the issue.  From some of the other replies, it seems you're 
on track, so I'll just shut up. 

Besides, if you had ever used "DTS" you would hate me for suggesting it. :-)

Regards,

John Byrnes

P.S. To all of you who wrote me to inform me of my blunder, thanks.  You
     can stop now!  8-( 

tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) (09/13/90)

>      These are specific HP VUE issues and, besides just working around them
> as Eric suggests, should be reported to Corvallis.  You might want to
> DTS an enhancement request for these things (or a stronger weight :-) )
> or just post your discontent on hp.windows.vue to get a response from
> the VUE folks.  They've been responsive in the past on issues like this.

Type up a description if you want, send it to me, and I'll submit it into
our internal Defect-Tracking-System.  I'd do it myself, but customer
reported bugs always have a little more impact.

-----------------------------------------------------------------------
Thomas Gilg             | tomg@cv.hp.com                   | INTERNET
Hewlett-Packard Company | {backbone}!hplabs!hpcvlx!tomg    | UUCP
1000 N.E. Circle Blvd.  | (USA) (503) 750-2756             | VOICE
Corvallis, OR 97330     | (USA) (503) 750-3788             | FAX
-----------------------------------------------------------------------

pam@hpcvlx.cv.hp.com (Pam Raby) (09/14/90)

Following is an overview of the HP-VUE startup process and a brief description
of where various environment sorts of things might be most appropriate.
Sorry for the length, it's fairly condensed.  I hope this overview helps
clarify when/where to set environment variables, start clients, etc.

Pam Raby
pam@cv.hp.com

============================= CUT HERE ==============================

First, note that until you have actually logged in, errors are appended to
/usr/lib/X11/vue/Vuelogin/Xerrors.  Once you have logged in and your session
is initiated, errors are appended to $HOME/.vue/errorlog.

1.  init spawns the parent vuelogin process which reads
    /usr/lib/X11/vue/Vuelogin/Xconfig, starts the X server, and spawns a
    child vuelogin for each display on the system.  Whenever you modify the
    Xconfig file, you should restart the server manually i.e. select restart
    from the login screen.  xrdb is used to load resources.

2.  The child vuelogin sets the following environment variables:
	DISPLAY is set to the first field in the Xservers file
	HOME as specified in /etc/passwd
	LANG is set to the display's NLS language (if any)
	PATH is set to the Vuelogin userPath resource
	     default is /usr/bin/X11:/bin:/usr/bin:/usr/contrib/bin
	USER is set to the user name
	SHELL as specified in /etc/passwd
	TZ set to Vuelogin.timeZone resource in Xconfig; default MST7MDT
	XAUTHORITY set to an authority file
    Note that no shell processing is available at this point (as was already
    mentioned).  Environment variables affecting the X server and/or all
    users on a display are set in Xconfig.

    The child vuelogin runs vuegreet to display the login screen as specified
    in /usr/lib/X11/vue/Vuelogin/Xresources, and validate the user and
    password.  The Xstartup script is then run.  Xstartup is run "as root"
    on behalf of the user to perform system-level functions, e.g. mounting
    home directories from file servers, displaying the message of the day,
    etc.  Last, the session is started via Xsession.

3.  Xsession is a ksh script which sets these environment variables:
	LOGNAME is set to the user name
	TERM is set to hpterm
	MAIL is set to /usr/mail/$USER
    Environment variables you want to affect all users on a display which
    require shell processing or are dependent on the value of other
    environment variables should be set in the Xsession script.

    Xsession displays the copyright notice by running vuehello.  Xsession
    then execs the appropriate shell, passing it $HOME/.vueprofile if it
    exists.  Xsession then starts your session as follows:
	if VUE is present, vuesession is run.
	if XDM is present, .xsession is run.
	otherwise, $HOME/.x11start is run.

    Environment variables for individual users are set in $HOME/.vueprofile.
    The .vueprofile file should not perform terminal I/O nor prompt for user
    input, which causes startup problems.  .profile (or .login) is still used,
    i.e. hpterm -ls, rlogin, telnet.

4.  vuesession starts all the VUE daemons, merges vue.resources into the
    resource database, sets server settings as specified in vue.settings,
    starts the window manager vuewm, runs vue.session (your saved session),
    and runs the sessionetc script if it exists.  vue.resources, vue.settings
    and vue.session are all found in $HOME/.vue/host:display/home
    (or current).  sessionetc is found in $HOME/.vue/host:display.  Start
    clients not automatically saved by VUE in sessionetc.

5.  Session termination.  Assuming you resume your current session, the
    contents of the resource database are saved in vue.resources, server
    settings are saved in vue.settings, and clients' command lines as set
    via the WM_COMMAND property are saved in vue.session.

    The Xreset script, counterpart to Xstartup, is run, again "as root" on
    behalf of the user.  This is your opportunity to "undo" what was done
    in Xstartup if needed.

    Now, you're back to vuelogin and, by default, the server has been
    restarted (not just reset).