![]() |
|||
![]() |
Sessions OverviewThe current Itsy software environment contains support for simultaneously running multiple applications in separate sessions. Each session is essentially a virtualized Itsy, with its own session-specific interface to the display, touchscreen, buttons, and other user-interface oriented I/O devices.In earlier releases, multiple applications would compete for control of the raw Itsy I/O devices. For example, when the user pressed a physical button, it might be seen by the intended application, other unintended applications, or some combination. The resulting cross-application device anarchy was clearly undesirable. Itsy sessions were designed to solve this problem by introducing a simple device sharing model with reasonable default behavior and modest implementation effort. In contrast to a unified windowing system that assumes compliance from all applications, the Itsy sessions model supports the peaceful co-existence of distinct yet concurrently-executing "worlds" such as full-screen standalone applications, virtual consoles, the X Windows desktop, Java environments, and the Squeak Smalltalk-80 system. This section presents a high-level overview of Itsy sessions. More detailed information can be found in the documentation for session-compliant device drivers.
Foreground vs. BackgroundAt any given time, a single session may be distinguished as the "active" or foreground session. Processes in the foreground session receive physical input events, such as button presses or touchscreen samples. Processes in the foreground session also have exclusive (or preferred) access to physical output devices. For example, the session's active framebuffer, if any, is mapped to be visible on the physical LCD display. Similarly, audio output generated by processes in the foreground session is played at full volume.Any number of "non-foreground" or background sessions may co-exist with the foreground session. Processes in background sessions do not receive physical input events. Output generated by processes in background sessions is typically hidden. For example, a background session's active framebuffer is not displayed on the LCD. Similary, background audio output is attenuated or muted.
Device Sharing ModelWhen a process in a session opens a physical device, it only really obtains access to a session-filtered instance of that device. Input generated by each physical device is replicated to all instances in the foreground session. Output is merged from all instances within the foreground session. Output from background sessions may be dropped, attenuated, or handled specially, depending on the device.Each physical device also exports an "unfiltered" or raw interface that is not session-filtered. For example, the buttons driver supports both a session-filtered /dev/buttons device and an unfiltered /dev/rbuttons device. Applications requiring low-level access to a device may use the raw interface, bypassing the coherent sharing support offered by the session-filtered interface. Applications may also be made "session-aware" by explicitly listening for events (such as changes in foreground/background status) via the /dev/session pseudo-device interface.
Session IdsEach Itsy session is identified by a unique session number. In our current implementation, each distinct Linux session also defines a distinct Itsy session. Linux sessions are typically used to group processes (and/or process groups) together with a single controlling tty and a distinguished session leader. More details about standard Linux sessions are available via relevant man pages including setsid(2) and getsid(2). A good discussion of Unix sessions also appears in the popular book Advanced Programming in the UNIX Environment by W. Richard Stevens.It is important to note that the one-to-one correspondence between Linux sessions and Itsy sessions may change in future releases. Session-compliant drivers must obtain session ids from tasks indirectly via the kernel function itsy_session_from_task(). Session-aware applications may query session ids via the /dev/session interface.
Session ManagerA user-level process generally serves as a session manager to coordinate which virtual Itsy instance is currently mapped to the physical hardware. The session manager obtains information about all active sessions and manipulates them through the raw session interface /dev/rsession. For example, the session manager can dynamically change the foreground/background status of a session, and can send suspend/resume/terminate signals to all processes in a session.In the current release, the default session manager is gmanager, a graphical application that allows the user to start, stop, and monitor active sessions using a touchscreen-based interface. The round white "power button" is reserved for bringing the manager to the foreground. If the power button is pressed and held down for several seconds, gmanager will instead put the Itsy into its low-power sleep mode. gmanager: An Itsy Session ManagerA session manager is an application that allows the user to start, stop, and monitor active Itsy sessions. A session manager can change the foreground/background status of a session, and is able to suspend, resume, or terminate all the processes in any session.The default Itsy session manager included with Release 4.0 is gmanager, a graphical application that uses a touchscreen-based interface. The wm1 window manager application included with older releases is not compatible with Itsy sessions and is now obsolete.
Invoking gmanagerWhen the Itsy boots, gmanager is started automatically. This is accomplished via an entry an /etc/inittab; gmanager will automatically restart upon termination.If another application is running as the foreground session, the round white "power button" on the front of the Itsy can be pressed at any time to bring the manager to the foreground. If the power button is pressed and held down for several seconds, gmanager will instead put the Itsy into its low-power sleep mode. Once the Itsy is in sleep mode, normal operation can be resumed by pressing the power button to wake it up.
Basic OperationThe gmanager interface contains several touch-sensitive screen regions that are used to perform various operations:
CustomizationAll gmanager configuration information is stored in the /etc/manager directory. The launcher menus, buttons, and other scripts used by gmanager are easily customized. To make your customizations persistent, you will need to either change the motherboard ramdisk (and burn the updated ramdisk into flash), or create a package with a startup script under rc.itsy that updates files in /etc/manager, typically by creating symbolic links or overwriting existing files.
Custom LaunchersEach directory in /etc/manager, such as System and Apps defines a top-level launcher menu that gmanager displays in its left pane. Each executable file contained in one of these menu directories becomes a launcher button. When a launcher button is pressed, gmanager runs the associated exectuable file in a new session using the standard Linux open command, which also starts a new virtual console (see the open(1) man page for details). Since no arguments are passed to launcher executables, they are usually scripts. For example, in the current release, Apps/Tcsh launches a new tcsh shell session that accepts unistroke input as follows:#!/bin/tcshThis won't win any prizes for efficiency, but it works. The itsy-session command (sources are provided) specifies a custom name for the session, which is also displayed in the manager session list. The instance of scribapp started with this session will accept written unistroke characters, and send it to the keyboard device for this session, allowing you to enter your favorite Linux command like "df" by writing it on the touchscreen. The use of exec for the final command avoids keeping an extra shell around. Here is a more interesting example, the System/ViewProcfs launcher script: #!/bin/shThis script displays an interactive touchscreen-based menu of procfs entries. The selected file is displayed via less, which is controlled via the Itsy buttons using the keyboard mapping implemented by buttonkeys. Note that the source for both menu and buttonkeys is included with the release. Note also that small scripts can be quite powerful. Finally, note that I never got around to fixing a bug; some procfs entries are directories. If you write your own scripts that are useful or interesting for controlling an Itsy, please contribute them to us. We'll consider including them in a future release.
Additional Customization
|
![]() |
|
The Itsy Project
is a joint effort of the Western Research Lab and the Systems Research Center