This file documents version 0.20 of the Pxdrv device driver and its support programs (February 2001 ).
This text introduces to the features of the PX500/510/610 device driver for Linux. Not every feature of the device is supported: feel free to ask for features if you need them: I'll feel more inclined to write code if someone is going to use it.
In this document, the term PX500 is used to refer to all devices in the family (unless otherwise specified). The terms PX510 and PX610 are used to refer to features that are not available in earlier models. Refer to the ImageNation manual to get information about hardware features.
The driver currently works with version 2.0 and 2.2 of the Linux kernel. Note that in order for DMA to work, you need to change your Lilo configuration, as described in The DMA Buffer.
As of version 0.20 of the driver, progressive scan cameras are supported, as well as using WEN as an input to synchronize the frame grabber (The WEN signal is used by some resettable cameras to signal the beginning of a new video field. See Special Cameras.
As usual in the Unix environment, you need device special files in order to access a device driver of any kind. This section enumerates the entry points used to communicate with the driver.
The following devices are used for the first grabber (device number 0). They are automatically created by px_load. See Compiling and Loading.
/dev/px0
/dev/px0pgm
/dev/px0ctl
/dev/px0H
/dev/px0Hpgm
Whenever the device is active in low-resolution, opening an high-resolution entry point return -EBUSY. The same happens if the device is working in high resolution and you open a low-resolution entry point. The control node can always be opened because it isn't involved with data acquisition.
Note that if you open a device and then change its resolution via ioctl, further open calls on the device won't be prohibited; the device will instead remain configured as selected via ioctl. See Ioctl.
To compile the driver run "make". If the source of the kernel you are using is not in /usr/src/linux, you can specify its location as KERNELDIR, either in the environment or at the command line of make. For example I currently use "make KERNELDIR=/usr/src/linux-2.2".
Alternatively, you can specify INCLUDEDIR in the same way. I used INCLUDEDIR in older releases of this drivers as well as other drivers. Now I prefer to use KERNELDIR instead. INCLUDEDIR, if not specified by the user, defaults to $(KERNELDIR)/include .
To load the driver, run ./px_load, Edit the script to configure permission bits and owners of the devices being created. Any argument that you pass at the px_load command line are passed to insmod. This allows load-time configuration of internal variables.
To unload the driver, run ./px_unload. It also
removes the /dev entry points.
One of the most compelling problems with any DMA-capable device is the allocation of a suitable memory buffer. In pxdrv I chose to use a module of mine, called "allocator". The allocator is able to use high memory (above the one used in normal operation) for DMA allocation. In order to use it, however, there must be some real RAM memory at the end of the memory used by the Linux kernel.
To prevent the kernel for using high memory, so that it remains
available for DMA, you should pass a command line argument to the
kernel. Command line arguments can be passed to Lilo, to Grub or to
whichever loader you are using (unless it's very poor in design). For
Lilo, either use "append=" in /etc/lilo.conf or add command
line arguments to the interactive prompt. For example, I have a 64MB box
and reserve two megs for DMA by telling the kernel mem=62M.
Actually, the px500 uses half a meg at most, but I have another driver
that acquires RGB images and needs 1.5 megs.
In lilo.conf:
image = /zImage label = linux append = "mem=62M"
Or, interactively:
LILO: linux mem=62M
Please note that the mem= argument must be lowercase or the kernel won't use it.
The devices return image data when read. For example, you can use "cat /dev/px0H | split -b <size>" to create a burst of raw graphic files in your disk (the size value depends on whether you use NTSC (size == 307200) or PAL (size == 442368). To see the current image, you can issue "xv - < /dev/px0pgm" or any equivalent command.
There is currently no way to control grabbing in time, like grabbing one frame every 200ms or so. This will be implemented in a future release of the driver.
Devices can't be written to, currently. Maybe I'll arrange for PGM devices to receive text strings to configure their behavior (regions of interest and so on), and the same will apply to the control node. If I won't conceive more interesting write semantics for binary nodes, they will behave in the same way.
The ioctl() function is supported by the device, to see and/or change what is happening in the internals. A few of the ioctl commands are very low level, and I'd suggest using them only if you know how the device works internally.
Some of these commands can only be issued by the super-user, independent
of the file permission of the /dev entry point accessed. This is
a security measure necessary to protect hardware from potentially bad
actions. The super-user can damage anything anyways, so allowing these
commands does not harm.
If you are just a device user, feel free to skip to the next section.
PX_IOCRESET
PX_IOCHARDRESET (no third argument needed)
PX_IOCGDEV (third argument needed)
Px_Dev * item.
The command is mainly useful for debugging and is not
restricted to the super-user.
PX_IOCSREG (third argument needed)
PX_IOCGREG (third argument needed)
Px_Register structure. The reg field identifies
the register to be acted upon, the val field is the
value being read or written. If the register number is out
of the allowed range, -EINVAL is returned. Only the superuser
can write device registers.
PX_IOCCMD (third argument needed)
px500.h and are often used
internally by the driver. The argument of this ioctl command
is a pointer to a Px_Register structure and is used
like in PX_IOCSREG and PX_IOCGREG above. For output
commands, the structure defines the command number and its
argument; for input commands the structure defines the
command number on entry and the result is filled by the driver.
Some of the commands are restricted to the super user and some
are not. Refer to px_command_list in the driver for
details.
PX_IOCSPORT (third argument needed)
PX_IOCGPORT (third argument needed)
PX_PORT_MIN to
PX_PORT_MAX inclusive (otherwise, -EINVAL is
returned). The third ioctl argument is a pointer to a
Px_Register structure and is used just like in
PX_IOCSREG and PX_IOCGETREG adove. Only the superuser
can write ports.
Use of these commands doesn't require intimate knowledge of the frame grabber device, and the commands are meant for use by actual application code.
PX_IOCSLUT (third argument needed)
PX_IOCGLUT (third argument needed)
struct PX_Lut, defined in px500.h.
A sample applications using these commands is pxlut.
See pxlut.
PX_IOCSGAIN (third argument needed)
PX_IOCGGAIN (third argument needed)
struct Px_Gain,
defined in px500.h. Use of this command is exemplified
in pxgain and pxcontrol.
PX_IOCAUTOGAIN (third argument needed)
pxgain and pxcontrol.
PX_IOCSMUX (third argument needed)
PX_IOCGMUX (third argument needed)
IOCSMUX
can be used to switch the multiplexer to either of the four
input channels (numbered from 0 to 3). The third argument
to ioctl is a pointer to unsigned long. IOCSMUX
returns -EINVAL if the value specified is out of range;
IOCGMUX always succeeds. When switching video input,
the behavior of the grabber is controlled by PX_FLAG_NONSYNC.
See Device Flags.
PX_IOCSOFF (third argument needed)
PX_IOCGOFF (third argument needed)
int.
See the ImageNation manual for details about theoffset.
PX_IOCSFLAGS (third argument needed) (unsigned long * argument)
PX_IOCGFLAGS (third argument needed) (unsigned long * argument)
unsigned long. While IOCGFLAGS
returns all of the flags to user space, IOCSFLAGS
modifies only the bits in PX_FLAG_USERMASK and doesn't
touch other bits. The flags are described in Device Flags.
PX_IOCSCOMPARE
PX_IOCGCOMPARE
PX_IOCSSIZE (third argument needed)
PX_IOCGSIZE (third argument needed)
Px_Parameters. The role of
this structure is detailed in Special Cameras. Since
IOCSSIZE is potentially dangerous, its use is restricted
to the super-user.
PX_IOCSTRIGGER (third argument needed)
PX_IOCGTRIGGER (third argument needed)
unsigned long.
The argument being
exchanged with kernel space is a bit field and
is described in Triggers.
PX_IOCWTRIGGER (no third argument needed)
errno set to EINTR)
if the command is interrupted by a signal.
PX_IOCSTROBEENA (third argument needed)
int. If the value pointed to is positive, then strobes
are enabled, if it is zero or negative strobes are disabled.
Strobe management is implemented by macros that use PX_IOCCMD
and is documented in Strobes.
PX_IOCTRIGSTROBE (third argument needed)
The command tells the driver whether the trigger input should
fire the strobe sequence or not. The third argument to ioctl
is a pointer to int. If that integer value is positive,
the feature is enabled; if it is zero or negative the feature
is disabled.
PX_IOCDRIVEENA (third argument needed)
unsigned long.
The pointed-to value is a bit mask, made up of the following bits.
PX_BIT_DRIVE_ENA enable the output pins (1) or disable them (0).
PX_BIT_DRIVE_HNEG if set makes the output H-sync a
normally-high signal with negative-going pulses; if set the signal
is normally-low with high pulses. PX_BIT_DRIVE_VNEG is
the same for the V-sync signal.
The command can be tested using the pxcontrol sample tool
but the bitmask must be specified in numeric form. See pxcontrol.
The command fails with -EINVAL
if any invalid bit is set in the argument value.
PX_IOCPALQZ (third argument needed)
int. If the pointed-to value is positive
than the PAL quartz is selected; if it is zero or negative the
standard (slower) quartz is selected.
Memory mapping is implemented on any device node. If you mmap() the
control entry point, you will map the current DMA memory, either low
resolution, high resolution or no DMA at all (if no DMA is active,
mapping the control device will return the last-acquired
image). Memory-mapping other devices assures that DMA is being run at
low resolution (/dev/px0 or /dev/px0pgm) or high
resolution (/dev/px0H or /dev/px0Hpgm).
You can test a simple mmap() client by running the mapper
program distributed with the driver. See mapper.
The PX500 device is able to perform triggered acquisition. The feature
is controlled by means of the PX_IOCSTRIGGER ioctl command
(and the current setup can be retrieved by issuing PX_IOCGTRIGGER.
See Ioctl.
The argument passed to (and received from) the ioctl commands is a bit mask made up of the following bits:
PX_BIT_TRIGGER_ENABLE
PX_BIT_TRIGGER_POL
PX_BIT_TRIGGER_EDGE
PX_BIT_TRIGGER_DEBN
PX_BIT_TRIGGER_OCCURRED
IOCSTRIGGER command. The bit is cleared every time
IOCSTRIGGER is issued.
When the TRIGGER_ENABLE bit gets set, data transfer is stopped
until a trigger arrives (if you read the device, you'll find the last
grabbed image). When a trigger is received, the driver will acquire a
single image (one frame or one field, according to the current setup)
and will wait for one further trigger. Clearing TRIGGER_ENABLE
turns back the system to continuous grabbing.
To wait for a triggered acquisition use PX_IOCWTRIGGER
described in Ioctl.
If you want to check whether a trigger has already been managed, you can
check the TRIGGER_OCCURRED bit. The bit is set after a triggered
acquisition is over (i.e., when the bit is set you are assured that the
in-memory image is current). The bit is automatically cleared if you
choose to wait for the trigger (using IOCWTRIGGER) instead of
polling (using IOCGTRIGGER). As outlined above, the bit is
cleared when read, so that waiting for another trigger doesn't require
any further action.
The PX510/610 devices have two digital I/O lines, called strobes. The
lines can be acted upon using microcontroller commands, so no special
ioctl command is implemented for them. However, in order to save
the programmer from boring hacking with hex values, the px500.h
header defines the following functions to play with the strobes.
Refer to the ImageNation manuals for details on the provided mechanisms.
The return value is always zero or a positive number for success, and
-1 in case of error (with errno set to a proper value). This comes
straight from the underlying ioctl system call.
Px_EnableStrobes(int fd, int output);
output argument must be 1 to enable the strobe lines
and 0 to disable them. The macro uses IOCSTROBEENA.
Px_InitStrobes(int fd);
Px_Fire_Strobe(int fd, int which);
which argument. The argument must
be 0 to stop a strobe sequence, and to 1, 2, or 3
to fire the first strobe, the gap, or the second strobe.
For clarity, the following symbolic names can be used as well:
PX_FIRE_STROBE_STOP, PX_FIRE_STROBE_1,
PX_FIRE_STROBE_GAP, PX_FIRE_STROBE_2. The result
of the macro is undefined if invalid values of which are
passed.
Px_TimeStrobe(int fd, int which, int val);
which is 1, 2, 3.
The duration is expressed in multiples of the duration of one
horizontal line. Like above, the following Once again, the
following symbolic names can be used instead: PX_FIRE_STROBE_1,
PX_FIRE_STROBE_GAP, PX_FIRE_STROBE_2.
The result of the macro is undefined for invalid values of
which. The val argument (the duration)
must fit 16 bits so it must be in the range 0-65535.
Px_TimeStrobes(int fd, int t1, int t2, int t3);
Px_StrobePolarity(int fd, int which, int negative);
negative is non-zero, the polarity will be inverted
from the default. The which argument should be 1
(strobe 1) or greater (strobe 2). The values
PX_FIRE_STROBE_1 and PX_FIRE_STROBE_2 can be used.
This macro individually controls the polarity of the two
output lines.
int Px_GetStrobes(int fd);
PX_BIT_STROBE_1, PX_BIT_STROBE_2 and
PX_BIT_STROBING. The first two bits report the
current voltage level at the strobe pins (which, thus
can be used as input pins as well, provided strobing
output is disabled). The PX_BIT_STROBING value tells
whether or not a strobing sequence is active; since both bits
are inactive during the gap period, the bit is needed to tell
the gap period from the no-strobe-active case.
The device structure includes a 32-bit field of flags, which can be
retrieved from user space either as an unsigned long value or within the
whole device" structure (using IOCGDEV). Only flags intended for
user consumption are described here. Some of them are read-only for
user-space programs.
Informative flags:
PX_FLAG_DEVICENAME
flags & PX_FLAG_DEVICENAME"
is either 500, 510 or 610 according to the device type.
PX_FLAG_DEVICE510
PX_FLAG_DEVICE610
PX_FLAG_DEVICE104
PX_FLAG_HASCACHE
Read/write flags, that can be modified via IOCSFLAGS:
PX_FLAG_AUTOGAIN
PX_FLAG_PERSIST
pxlive for an
example).
PX_FLAG_NONSYNC
read()
system call will sleep for the duration of two
image frames after the digitazer is switched to another
camera. This delay allows the grabber to re-sync with the new
video stream. The bit is off by default thus assuming that cameras
are synchronized (in which case, no extra delay is added by the
driver after the input MUX is switched).
Pxdrv supports progressive-scan cameras and special cameras by means of
its struct Px_Parameters structure and PX_IOCSSIZE
ioctl command.
The structure is defined in px500.h:
typedef struct Px_Parameters {
__u16 xsize, ysize;
__u16 firstline, lastline;
__u16 firstcol, lastcol;
__u16 dmahole, decimate;
__u16 fieldlen, blanklen;
__u16 flags;
} Px_Parameters;
The role of the various fields is as follows:
__u16 xsize, ysize;
IOCSSIZE the dimension
of the image is changed from the default.
__u16 firstline, lastline;
ysize
parameter above must be consistent with firstline and
lastline.
__u16 firstcol, lastcol;
xsize
parameter above must be consistent with firstcol and
lastcol.
__u16 dmahole;
dmahole is the amount (in bytes) of space to leave blank
between successive video lines in the same field. When acquiring
single fields it is usually 0, when acquiring whole frames it is
the same as the line length. Note that when acquiring whole frames
with progressive-scan cameras the dmahole must be set to zero.
__u16 decimate;
decimation
can be set to values greater than 1, the feature is untested.
__u16 fieldlen, blanklen;
__u16 flags;
Currently, the following flags are supported:
PX_PARAMETER_FLAG_PROGRESSIVE
fieldlen in the structure.
PX_PARAMETER_FLAG_WEN
Note that the driver automatically configures the frame grabber for PAL
operation whenever the field length is greater than the default NTSC
length. Therefore, when using a progressive-scan camera you may need
to explicitly choose the pixel clock to use. To this aim, use
the PX_IOCPALQZ ioctl command. See Ioctl.
As an example, this is how I acquire images using a Jai CV-M10 progressive-scan camera:
/dev/px0Hpgm but it doesn't matter).
IOCSSIZE to set image parameters and flags. This
enables WEN and progressive-scan; I use xsize=640,
ysize=480, dmahole=0, decimate=0,
blanklen=20, fieldllen=640. First and last
lines and columns are unchanged, while flags are
set to PX_PARAMETER_FLAG_PROGRESSIVE|PX_PARAMETER_FLAG_WEN.
IOCSTRIGGER to choose trigger parameters. I select a
positive-edge trigger: PX_BIT_TRIGGER_ENABLE |
PX_BIT_TRIGGER_EDGE.
IOCPALQZ with an argument of 0 in order to disable
the higher-frequency PAL quartz and digitize 640 pixels per line.
If you use pxlive and pxcontrol to change parameters,
you can try this sequence:
$ ./pxlive /dev/px0Hpgm & $ ./pxcontrol setparams 0 640 480 3 25 480 $ ./pxcontrol settrigger 10 palqz 0
To get details on setparams, pxcontrol.
The driver still misses any time-related operation (like single-frame acquisition).
The driver didn't undergo serious auditing and testing.
All the sample application parse the command line in the same way.
The device name can be either the first or last command line argument.
The device name is identified by being a full pathname (i.e., it has
a leading "/").
If none is specified on the commandline, the PXDEVICE environment
variable is used to retrieve a default device entry point; if the
variable is unset, the default is using device 0 (the actual default
entry point is either the control node or the low-resolution PGM node.
See General Information.
The pxtest program prints information about the frame grabber
associated to the device special file it opens. It uses the control
entry point by default in order not to allocate a DMA buffer.
This is an example of a pxtest run on the host called borea,
as of version 0.20 of the device driver:
borea% ./pxtest ./pxtest: using device /dev/px0ctl Device name: PX610, interface bus: PC104+ Hardware information: hardware revision: 0x34 protection key: 0x55 has cache ram: no PIC revision date: 4/21/97 Software information: dma buffer: 0x03e00000 (size 0x0006c000), remapped at 0xc403c000 registers at 0xefffe000, remapped at 0xc403a000 image size (640x500): 320000 usage 3, isup 5 irq 11, currently 11 Status information: status: 0x37 status2: 0x09 port X: 0x00 port Y: 0x4c port Z: 0x01 has video: y video type: pal
The program displays the flow of images from the device by printing it
to the text screen. I use mostly text mode, so I like this tool. It
reads /dev/px0 by default and it assumes the device is 320x240 pixels
(i.e., an NTSC camera). It adapts the output to the actual screen size
(whether it is an xterm or a text console).
The program makes live video on an X window. This tool is quite slow as it doesn't directly access X data structures; it's not like a real live video, just a simple demonstration.
If the pacco tool is available, pxlive uses it to gain better
speed and better resolution. If pacco is not available, the tool
runs using the photo widget of Tk, which is much slower. Pacco is
available from <ftp://ftp.prosa.it/pub/software> and
<ftp://ftp.systemy.it/pub/develop>. Like other sample programs,
this accepts a device name on the commandline or as an environment
variable. The program must access a pgm entry point (either low or high
resolution).
The More... button of the program opens an additional window that
lets you play with some of the configurable parameters of the grabber.
Operation with the More... window is especially slow since it
executes an external command (pxcontrol) for each configuration
change. Again, my aim is not speed but something easy to show things
out.
The program is a slightly modified pxlive that uses two cameras (/dev/px0 and /dev/px1). Thanks to Rob Steele for contributing this: although he didn't consider it ready for prime time (as it lacks some details as well as Pacco support), I think it is interesting. I planned to reintegrate it back to the normal pxlive but maybe it will never happen for real.
The program shows or sets the gain for the frame grabber. Remember that
the gain is reset to "1 0" on first open, so you need to keep the device
open while changing the gain. You can run pxgain while running
pxshow or pxlive to see real-time changes (but note that
pxlive in its configuration window allows playing with the gina.
The auto option to pxgain enables auto-gain. An optional
argument in addition to auto tells the maximum amount of gain
change from one frame to the next. Default is 5; 0 disables
autogain.
pxgain auto 10 auto-gain, maxstep is 10 pxgain auto default step pxgain auto 0 disables auto-gain
The pxlut program allows reading and writing the gray level
look-up table of the device. Call it without arguments to get help.
The program is a general-purpose wrapper for ioctl(). Call it with no arguments to have a list of allowed command line options. You can specify several commands at the same time on the command line, one after another.
All commands accepted by the program get numeric arguments. The meaning
of the arguments should be clear by itself or needs checking the
px500.h header (for example, to pass a bitmask to the program
you'll need to look up the value of individual bits; this applies for
instance to the setrigger command.
The only command that needs a special description is setparams.
The command is meant as an helper to invoke the IOCSSIZE
ioctl command. The data structure used in ioctl is described in
Special Cameras, and the setparams command takes 6 numeric
arguments:
dmahole is set to be equal to the
horizontal size (unless progressive-scan input is enabled). If the
argument is not zero, decimation is set to 1 and dmahole is
cleared. The value must be specified as non-zero to acquire single
fields (the default if you open the low-resolution devices).
xsize.
ysize.
PX_PARAMETER_FLAG_PROGRESSIVE (1)
and PX_PARAMETER_FLAG_WEN (2).
Use of setparams is exempified in An Example Using WEN.
The mapper is general-purpose memory-map frontend. It receives
arguments on the command line: the device to map, the initial offset
and the size of the memory map. Mapped data is printed to the standard
output. The following example shows how to acquire a image from
an NTSC camera via mmap():
./mapper /dev/px0 0 `exptr 320 \* 240` | rawtopgm 320 240 > img.pgm
To use the library you should include px500.h and link with
-lpxdrv (which is installed in /usr/local/lib). The
library is made up of functions, preprocessor macros and external
commodity variables (the variables are instrumental to the workings of
some of the macros. They are not documented here as such.
Please note that direct use of ioctl is still the preferred way to interact with the device; some of the library functions I offer haven't been tested.
The fd argument of all the functions is a file descriptor that
must refer to a frame grabber device. If you use thee standard I/O
library (fopen() and file pointers), you can extract the
descriptor from a FILE pointere by calling fileno(). The return
argument of the library functions, unless otherwise described, is 0 or
positive in case of success and a negative value in case of failure,
with errno set to describe the type of error.
The following functions are implemented, most as simple wrappers around ioctl():
int Px_Command(int fd, int command, int value);
int Px_SetReg(int fd, unsigned long register, unsigned long val);
int Px_GetReg(int fd, unsigned long register);
ioctl(PX_IOCGETREG)
to avoid ambiguity.
As a matter of facts, reading and writing registers should not
be needed during grabber operation.
int Px_Setport(int fd, unsigned long port, unsigned long val);
int Px_GetPort(int fd, unsigned long port);
int Px_GetDev(int fd, Px_Dev *ptr);
int Px_Reset(int fd);
int Px_ProtKey(int fd);
int Px_Revision(int fd);
int Px_ReleaseYear(int fd);
int Px_ReleaseMonth(int fd);
int Px_ReleaseDay(int fd);
pxtest using these macros.
int Px_Status(int fd);
int Px_Status2(int fd);
int Px_PortX(int fd);
int Px_PortY(int fd);
int Px_PortZ(int fd);
pxtest sample program uses them to print
the current value of the status ports.
int Px_HasRam(int fd);
int Px_HaveVideo(int fd);
int Px_VideoType(int fd);
int Px_PalVideo(int fd);
int Px_NtscVideo(int fd);
PX_NTSC_VIDEO or PX_PAL_VIDEO (or
-1 if an error
occcurs), while the other two are booleean (an error is
reported as 0). Note that the video mode is not a meaningful
information unless Px_HaveVideo() returns true.
int Px_SetGain(int fd, Px_Gain *ptr);
int Px_GetGain(int fd, Px_Gain *ptr);
struct Px_Gain.
int Px_AutoGain(int fd, int value);
int Px_SetLut(int fd, Px_Lut *ptr);
int Px_GetLut(int fd, Px_Lut *ptr);
struct Px_Lut data structure,
and use of the two functions is exemplified by the
pxlut sample program.
int Px_GetParameters(int fd, Px_Parameters *ptr);
int Px_SetParamaters(int fd, Px_Parameters *ptr);
mapper: mapper
Px_AutoGain: Library Functions
PX_BIT_TRIGGER_DEBN: Triggers
PX_BIT_TRIGGER_EDGE: Triggers
PX_BIT_TRIGGER_ENABLE: Triggers
PX_BIT_TRIGGER_OCCURRED: Triggers
PX_BIT_TRIGGER_POL: Triggers
Px_command: Library Functions
Px_EnableStrobes: Strobes
Px_Fire_Strobe: Strobes
PX_FLAG_AUTOGAIN: Device Flags
PX_FLAG_DEVICE104: Device Flags
PX_FLAG_DEVICE510: Device Flags
PX_FLAG_DEVICE610: Device Flags
PX_FLAG_DEVICENAME: Device Flags
PX_FLAG_HASCACHE: Device Flags
PX_FLAG_NONSYNC: Device Flags
PX_FLAG_PERSIST: Device Flags
Px_GetDev: Library Functions
Px_GetGain: Library Functions
Px_GetLut: Library Functions
Px_GetParameters: Library Functions
Px_GetPort: Library Functions
Px_GetReg: Library Functions
Px_GetStrobes: Strobes
Px_HasRam: Library Functions
Px_HaveVideo: Library Functions
Px_InitStrobes: Strobes
PX_IOCAUTOGAIN: Higher-Level Commands
PX_IOCDRIVEENA: Higher-Level Commands
PX_IOCGCOMPARE: Higher-Level Commands
PX_IOCGDEV: Low-Level Commands
PX_IOCGFLAGS: Higher-Level Commands
PX_IOCGGAIN: Higher-Level Commands
PX_IOCGLUT: Higher-Level Commands
PX_IOCGMUX: Higher-Level Commands
PX_IOCGOFF: Higher-Level Commands
PX_IOCGPORT: Low-Level Commands
PX_IOCGREG: Low-Level Commands
PX_IOCGSIZE: Higher-Level Commands
PX_IOCGTRIGGER: Higher-Level Commands
PX_IOCHARDRESET: Low-Level Commands
PX_IOCPALQZ: Higher-Level Commands
PX_IOCRESET: Low-Level Commands
PX_IOCSCOMPARE: Higher-Level Commands
PX_IOCSFLAGS: Higher-Level Commands
PX_IOCSGAIN: Higher-Level Commands
PX_IOCSLUT: Higher-Level Commands
PX_IOCSMUX: Higher-Level Commands
PX_IOCSOFF: Higher-Level Commands
PX_IOCSPORT: Low-Level Commands
PX_IOCSREG: Low-Level Commands
PX_IOCSSIZE: Higher-Level Commands
PX_IOCSTRIGGER: Higher-Level Commands
PX_IOCSTROBEENA: Higher-Level Commands
PX_IOCTRIGSTROBE: Higher-Level Commands
PX_IOCWTRIGGER: Higher-Level Commands
px_load: Compiling and Loading
PX_NTSC_VIDEO: Library Functions
Px_NtscVideo: Library Functions
PX_PAL_VIDEO: Library Functions
Px_PalVideo: Library Functions
Px_Parameters: Special Cameras
Px_PortX: Library Functions
Px_PortY: Library Functions
Px_PortZ: Library Functions
Px_ProtKey: Library Functions
Px_ReleaseDay: Library Functions
Px_ReleaseMonth: Library Functions
Px_ReleaseYear: Library Functions
Px_Reset: Library Functions
Px_Revision: Library Functions
Px_SetGain: Library Functions
Px_SetLut: Library Functions
Px_SetParameters: Library Functions
Px_SetPort: Library Functions
Px_SetReg: Library Functions
Px_Status: Library Functions
Px_Status2: Library Functions
Px_StrobePolarity: Strobes
Px_TimeStrobe: Strobes
Px_TimeStrobes: Strobes
px_unload: Compiling and Loading
Px_VideoType: Library Functions
pxcontrol: pxcontrol
pxgain: pxgain
pxlive: pxlive
pxlut: pxlut
pxshow: pxshow
pxstereo: pxstereo
pxtest: pxtest