MATRIX VISION - mvVirtualDevice Technical Documentation


System requirements

Currently supported Windows versions are:

  • Microsoft Windows 7 (32-bit, 64-bit)
  • Microsoft Windows 8.1 (32-bit, 64-bit)
  • Microsoft Windows 10 (32-bit, 64-bit)

Consecutively the installation for Windows® will be described. The description for the Linux® installation can be found here: Linux® .

Software installation

You can download all necessary drivers for Windows® and Linux® from our website:


The standard MATRIX VISION frame grabber drivers have been ported to Linux. A common code base ensures that the names and parameters of all the functions are identical to the Windows / DOS versions. This makes porting your existing Windows applications to Linux especially easy. We are constantly improving and updating so you should always take a look at our website for newer versions (

System requirements

Software requirements

  • Linux kernel 2.4.x or 2.6.x running on i386 CPU.
    It is possible that older kernels will also work.
    Following things are required:
    • You will need to have support for kernel modules turned on in your kernel configuration.
      (This is the default for all major Linux distributions).
    • For the shared versions of the library, the "GNU C runtime library libc6" is required.
      All recent Linux distributions should have this (e.g. SuSE Linux 9.0, 9.1, 9.2).
    • The libraries have been compiled using "glibc 2.3.3." on a SuSE 9.0 installation.
      If you use an older version of glibc you may experience problems.
      The libraries have been compiled using gcc version 3.3.1 (SuSE Linux).
      Using a system based on gcc 2.x is not recommended and may not work correctly.
    • For display functions: a framebuffer, the svga library or for X applications, a correctly installed X system.
      It is also possible to use a framebuffer device. Check your distribution for a package called svga (or similar) or download and compile the sources for this library if you are not using X and you wish to display images or use a framebuffer (e.g. vesafb, rivafb etc.).

To compile the kernel modules you will need a correctly configured GNU compiler and at least the kernel header files and Makefiles installed. It is usually advisable to install all of the kernel sources. The kernel configuration should exactly match the kernel you are using. During installation the kernel modules will be compiled for your system using exactly the same configuration as for the kernel. If you have not compiled your own kernel you will probably have to install the source package for your kernel and retrieve the correct kernel configuration for the running kernel too. This is often stored as file in the /boot directory (Red Hat, Debian, Mandrake) or can be generated from /proc/config.gz in the case of SuSE or for 2.6.x kernels which have the appropriate kernel option turned on.

Software installation

  1. Copy the appropriate driver tarball from the CD or web to your computer (e.g. CD-ROM is mounted on /cdrom and directory /mypath exists):
    >cp -v /cdrom/linux/dist_titan-030801.tgz /mypath
  2. Unpack the tgz-file using:
    >tar -xvzf FILENAME.tgz
  3. and then...

    > ./configure
    > make

Settings behavior during startup

Settings contain all the parameters that are needed to prepare and program the device for the image capture. Every image can be captured with completely different set of parameters. In almost every case, these parameters are accessible via a property offered by the device driver. A setting e.g. might contain

  • the gain to be applied to the analog to digital conversion process for analog video sources or
  • the AOI to be captured from the incoming image data.

So for the user a setting is the one an only place where all the necessary modifications can be applied to achieve the desired form of data acquisition.

Now, whenever a device is opened, the driver will execute following procedure:

Figure 1: wxPropView - Device setting start procedure
  • Please note that each setting location step in the figure from above internally contains two search steps. First the framework will try to locate a setting with user scope and if this can't be located, the same setting will be searched with global (system-wide) scope. On Windows® this e.g. will access either the HKEY_CURRENT_USER or (in the second step) the HKEY_LOCAL_MACHINE branch in the Registry.
  • Whenever storing a product specific setting, the device specific setting of the device used for storing will be deleted (if existing). So when the user is currently working with a device 'VD000001' belonging to the product group 'VirtualDevice' and there is a setting exclusively for this device storing a product specific setting now will automatically delete the setting for 'VD000001'. Otherwise a product specific setting would never be loaded as a device specific setting will always be found first.
  • The very same thing will also happen when opening a device from any other application! wxPropView does not behave in a special way but only acts as an arbitrary user application.
  • Whenever storing a device family specific setting, the device specific or product specific setting of the device used for storing will be deleted (if existing). See above to find out why.
  • On Windows® the driver will not look for a matching XML file during start-up automatically as the native storage location for settings is the Windows® Registry. This must be loaded explicitly by the user by using the appropriate API function offered by the SDK. However, under Linux XML files are the only setting formats understood by the driver framework thus here the driver will also look for them at start-up. The device specific setting will be an XML file with the serial number of the device as the file name, the product specific setting will be an XML file with the product string as the filename, the device family specific setting will be an XML file with the device family name as the file name. All other XML files containing settings will be ignored!
  • Only the data contained in the lists displayed as "Image Setting", "Digital I/O" and "Device Specific Data" under wxPropView will be stored in these settings!
  • Restoring of settings previously stored works in a similar way. After a device has been opened the settings will be loaded automatically as described above.
  • A detailed description of the individual properties offered by a device will not be provided here but can be found in the C++ API reference, where descriptions for all properties relevant for the user (grouped together in classes sorted by topic) can be found. As wxPropView doesn't introduce new functionality but simply evaluates the list of features offered by the device driver and lists them any modification made using the GUI controls just calls the underlying function needed to write to the selected component. wxPropView also doesn't know about the type of component or e.g. the list of allowed values for a property. This again is information delivered by the driver and therefore can be queried by the user as well without the need to have special inside information. One version of the tool will always be delivered in source so it can be used as a reference to find out how to get the desired information from the device driver.