![[Previous]](image-lib/prev.gif){kind=small} |
![[Contents]](image-lib/contents.gif){kind=small} |
![[Index]](image-lib/keyword_index.gif){kind=small} |
![[Next]](image-lib/next.gif){kind=small} |
|
|
|
|
This chapter covers the following topics:
Environment variables can be set in the sysinit.node file (where node represents your computer's logical node number):
dir:dir:dir:dir
Unlike the PATH environment variable, the current directory must be indicated by a period, not a space. A space indicates the directory where the executable is.
 |
There are two potential incompatibilities with the previous releases:
|
For more information, see the section "PhAB multilingual applications" in the Unicode Multilingual Support chapter.
PHBIFF=y ph
PHFONT=//203/dev/phfont ph
For more information, see phfont in the Applications and Utilities chapter.
PHWMOPTS="-t"
To boot directly into Photon, append the following two lines to the end of your existing system initialization file sysinit.node:
# start Photon ph
Or
# start Photon ph.boot
|
ph.boot is another method for booting directly into Photon, but it doesn't support any of the options that ph has. |
Because no one has logged in yet when Photon starts for the first time, the phlogin program runs automatically. It presents the QNX Photon Login dialog and prompts you to enter a valid userid and optional password. The Photon environment is initiated when you log in successfully. When exiting Photon, you're returned to the login dialog.
|
If you click the login dialog's Exit button, you'll get
the OS command prompt (#).
If you'd like to disable the Exit button, add the following lines before the ph command in the sysinit.node file:
# disable exit button in login dialog export PHEXIT_DISABLE=1 |
To prevent ph from running phlogin when booting directly into Photon, add the following lines before the ph command in the sysinit.node file:
# setting LOGNAME prevents phlogin from running # xxx is any login name export LOGNAME=xxx
The export command causes ph to launch Photon directly without going through the QNX Photon Login dialog.
|
Setting LOGNAME isn't the same as logging in with a userid - you aren't automatically logged in as $LOGNAME when you set LOGNAME. |
In a runtime environment, you may not want the Desktop Manager to be used. To disable the Desktop Manager, add the following lines before the ph command in the sysinit.node file:
# Disable Photon Desktop Manager export PHPDM_DISABLE=1
To launch an application immediately after Photon starts, add the following lines after the ph command in the sysinit.node file:
# run a Photon application # replace xxx with the name of the executable xxx
For example, the following commands would start Photon through the phlogin utility and then launch the DayMinder application:
ph dayminder &
The inputtrap utility relies on PnP identification to detect which input devices you're using. However, most nonstandard pointing devices (such as touchscreens and pens) don't support PnP identification. To ensure that Input is invoked with correct arguments for these kinds of input devices, you'll need to create a file called input.node in the /etc/config/trap directory.
This file should contain the arguments inputtrap will pass to Input. When an input.node file exists, inputtrap doesn't probe for input devices - it simply invokes Input with the arguments you specify in the file.
 |
If you have to change your hardware any time in the future, you'll have to discard the input.node file for the previous setup. |
To reduce the likelihood of typing errors, you may query inputtrap and redirect the output to an initial input.node file, which you may then edit:
touch /etc/config/trap/input.node inputtrap query >/etc/config/trap/input.node
where node is the logical node number assigned to the computer.
The input.node file doesn't have a line-oriented structure, but you may find it convenient to list each protocol module (along with its options and arguments) on a separate line.
Since the result resembles a simple script, you may think of each hardware module as an "executable." After you remove the protocol modules you won't need, the contents of your input.node file might look like this:
kbd fd -d/dev/kbd airmse fd -d/dev/ser1 smartset uart -p2f8 -i3
These lines would connect Input to the keyboard (through the console driver), to an airmouse (through the serial driver), and to an Elographics Smartset touchscreen (through a UART at port 2f8 IRQ3). For more information about the input devices inputtrap detects, see the inputtrap utility in the Applications and Utilities chapter.
To determine which protocol modules to select for your hardware, type use Input for a complete description of the modules, their options, and arguments.
Once the touchscreen is successfully configured (i.e. you've created an input.node file), it must be calibrated. To invoke the calibration screen:
When the arrows come up, point to the corner of the screen opposite the arrow (not the arrow tip). When the bull's-eye comes up, touch the center.
To run many Terminal (pterm) windows concurrently, you may need to increase the configuration limits specified to the Device Manager and to the pseudo-tty driver.
Since each pterm window uses a pseudo-terminal device, you may need to modify your invocation of the Device Manager (Dev) in your sysinit.node file so that the Device Manager can handle a larger number of devices. For example, if you specify the following under QNX:
Dev [any_other_options] -n96 &
the Device Manager will support 96 terminal devices (virtual consoles, serial terminals, and pseudo-tty devices). The default number of devices is 64 with QNX 4.23 and QNX 4.24 (32 devices with QNX 4.22 and earlier). For more information, see Dev in the QNX OS Utilities Reference.
Each pterm window requires a pseudo-tty device pair. By default, the pseudo-tty driver (Dev.pty) starts four device pairs. If you want to use more pterm windows, you must specify a larger number of device pairs to the pseudo-tty driver. For example, to have up to 16 pterm windows, use this command:
Dev.pty -n16 &
Photon supports remote monitoring, diagnostics, technical support, and/or training. The phrelay utility has the job of transmitting graphical Photon events over a communications link to a remote phditto or Phindows client. The phrelay, phditto, and phindows utilities use a private protocol that allows large graphical objects to be sent only once to the remote client. All subsequent references to that data object are made by passing a small tag, knowing that the client has a local copy of the entire data object. Over time, commonly encountered objects (such as icons and backdrops) will all be cached.
The phrelay clients not only cache tagged data objects in local memory, but also spill least-recently used objects to disk automatically and save all cached objects to disk when they terminate. The next time the client starts up, it preloads its in-memory cache from the most recently encountered disk cache and informs the remote phrelay session which objects it already knows about. This means that after a graphical object is seen once within a phditto or Phindows client, it will, in general, never have to be transmitted again.
The normal mode of using phditto/Phindows (without the -n option) causes a private session of Photon to be started on the QNX machine you connect to. Photon's Jump Gate and dittoing facilities can be used to interact with other Photon sessions on the connected QNX machine (or any other QNX machine in the same QNX network, but your Photon session is otherwise independent of everyone else).
The -n command-line option allows a phditto/Phindows client to see and interact with any Photon session already running on one of the QNX machines in the same QNX network. An exact copy of the remote Photon user's screen will be displayed on your desktop. In addition, your mouse and keyboard can be used to interact directly with that remote Photon session. You can, in effect, "take over" the remote screen as if you were sitting there!
For example, if you wanted to provide support to a remote QNX site running Photon, you could dial up and log into that QNX machine using phditto with a command line similar to the following:
phditto -m/dev/ser2 -n/dev/photon
You would log in and start phrelay as follows:
/usr/photon/bin/phrelay
At this point, phrelay would be informed that a connection to an existing Photon session (/dev/photon) is being requested (i.e. the Photon running on the local console). The phrelay utility would create a graphics region to overlay the entire console graphics region, so that both your mouse and the remote mouse could control the same pointer. You would then be able to share that remote desktop with the remote user.
This type of remote connectivity is convenient for a variety of purposes, such as remote diagnostics, monitoring, technical support, and training. With Photon connectivity, there's no need for a screen or keyboard at the remote site.
Suppose you needed to look at a Photon application running remotely on a QNX machine other than the one you're connected to via modem. The -n option can specify the full QNX pathname of any Photon session on that remote QNX network. So if you're dialing into QNX node 1, but you want to look at and interact with Photon running on node 2's console, just use the following command:
phditto -n//2/dev/photon
When you connect to the QNX network (initially logged into node 1), start phrelay as follows:
/usr/photon/bin/phrelay
The phrelay utility will recognize that you really want to be connected to a Photon session on node 2, so it will automatically migrate itself to that node but continue to use the modem you dialed in on (i.e. the modem on node 1). Since QNX is an inherently distributed operating system, this happens seamlessly and efficiently.
Suppose the QNX machine you log into has lots of modems, but not a lot of spare CPU or memory. You want to start up a private Photon session and discover that node 2 has lots of spare resources (in QNX, any node will do). You can specify this with the following command:
phditto -n//2/dev/ph+
Phindows and phditto can both be used to "stretch" a single Photon space across multiple desktops. Some (or all) of these desktops can be QNX computers, some (or all) of these desktops can be Windows desktops (with the Phindows program), and some (or all) can be X workstations as well (with the PhinX program).
The -x, -y, -h and -w options are provided in both phditto and Phindows to make this possible. Here's how it works:
Suppose you have a QNX machine running Photon on a console in 1024*768 resolution and you now want to stretch the Photon space to include a 1024*768 MS-Windows screen placed immediately to the right of the QNX screen - this would create a 2048*768 Photon desktop. All you'd have to do is start Phindows on the Windows machine as follows:
phindows.exe -x1024 -n/dev/photon
When the TCP/IP connection is made, you'll notice that the Photon Desktop Manager, which is normally on the bottom of the Photon screen, has "stretched" to include the bottom of the right-hand MS-Windows screen as well. You can now use either mouse to start up new applications, drag them from screen to screen, and otherwise take advantage of your increased workspace.
With careful use of the -x, -y (and -h and -w) options, you could create many interesting combinations such as an array of monitors forming one huge Photon display, multimedia presentations, etc.
The normal mode of dittoing someone else's Photon session (-n specified) is to have a single pointer that can be controlled by either the local or remote user. Similarly, keystrokes from either keyboard can be entered into the application with keyboard focus, which is normally what you want for a remote training or debugging session.
But sometimes you may want the remote user to carry on working without necessarily being affected by what you're doing. You can do this by specifying the -u option on the phditto/Phindows command line. In this mode, your mouse, keyboard, and display will be completely independent of the other user's console. Both of you will see two pointers (your pointer will be solid, the other person's pointer will be dimmed or ghosted), but the two pointers will behave independently.
In Photon terminology, you'll be running in your own private input group. You're free to roam around the Photon space without affecting the other user. Your mouse clicks and keystrokes will be directed to whatever application has input focus for your input group. You can start new applications anywhere in the Photon space (probably in a different Photon console to be polite). Unless the other user chooses to roam over to the part of the desktop you're working in, the other user won't be affected by your presence.
There's no builtin limit to the number of users sharing the same workspace concurrently (although practically it's doubtful that you'd want to have more than two users at any one time). It's far more likely that if multiple users are connected to a single QNX machine, they will each run in their own private Photon workspace (the default behavior of phditto/Phindows) and communicate with each other using builtin Photon connectivity facilities such as Jump Gates, phditto, and msgpad. A single QNX computer could easily support dozens of such clients, provided it was fast enough and had enough RAM.
|
|
|
|