There is very little information available for creating customized installations of the Matrox G-series driver. I contacted Matrox who sent me the following:
For G-Series Unified Driver Packages
Version 2.00.01 SE and Up
Overview
--------
The Setup Program’s goal is to allow easy installation of the Matrox display driver packages.
The Setup program can run under various conditions (in “silent mode†or “batch mode†for OEMs or
IT deployment scenarios, from a CD-ROM installation program, etc.). This flexibility is obtained by
the use of entries specified in a configuration file suited to handle complex situations.
In addition, the Setup program displays a simple, user-friendly interface for the users who want to
initiate the driver installation through the wizard instead of by Windows’ “Have Disk†procedure
(which calls the INF procedure in silent mode).
Furthermore, the Setup utility is designed to install (and/or pre-install) any Matrox board present
or not in the computer as long as it is supported by the shipped drivers. The default entries used
with the Setup program (specified below) will affect the default parameters used during the
installation of all boards.
1 Setup.ini File Format
-----------------------
The file is composed of sections. A section begins with a section identifier, which is the section
name enclosed in square brackets ‘[]’. The section identifier stands by itself on a single line:
[SectionName]
The section content is defined as the lines following the section identifier until another section
identifier is encountered or the end of the file is reached. Each line is considered an independent
entry, unless one of the following conditions is encountered:
· A line-continuation symbol is present, in which case the following line is considered part of
the current line (see section 1.2 below).
· A line is a section inclusion statement, in which case the line is replaced by the included
section content (see section 1.3 below).
1.1End-Of-Line Comments
-----------------------
Each section line can be accompanied by a comment to the right of the line’s useful statement
(a.k.a. the line entry). The comment identifier ‘\*’ must be placed before the actual comment.
ValueName = ValueContent \* This is a comment
1.2Multi-Line Entries
---------------------
It is possible to format an entry on multiple lines (this might be useful for readability reasons). Use
the line-continuation identifier ‘\|’ at the end of the entry, but before the comment (if any). The
following section fragment:
ValueName = 00,01,02,03, \|
04,05,06,07
ValueName2 = 00,01,02,03, \| \* Comment on part 1
04,05,06,07 \* Comment on part 2
Is processed as if it was written like this:
ValueName = 00,01,02,03,04,05,06,07
ValueName2 = 00,01,02,03,04,05,06,07 \* Comment on part 1 Comment on part 2
1.3Section Inclusion
--------------------
It is also possible to insert the content of another section at a specific location in the current
section. This is achieved by using the #include<> statement, where the name of the section to
include is located between the < and > characters.
For example, the following section fragment:
[Section1]
Value1 = 1
#include<Section2>
Value2 = 2
[Section2]
ValueA = a
ValueB = b
Is processed as if it was written like this:
[Section1]
Value1 = 1
ValueA = a
ValueB = b
Value2 = 2
2 Setup.ini Content
-------------------
In the following specification, the configuration file refers to the Setup.ini file. All section
headers listed in the configuration file must be enclosed with []. Ex: the setup section is labeled
[Setup]. In addition, quotation marks are unnecessary for any parameters and must not be used
in the actual Setup.ini unless explicitly specified.
2.1[Setup] Section
------------------
2.2Display Configuration Overview
---------------------------------
This section’s goal is to describe the various aspects of display configuration and how to go about
specifying a given configuration in unattended installation scenario.
There are up to three aspects to display configuration on any given display adapter:
1. The number of independent displays reported to Windows. This is the number of monitors
shown in the Microsoft-provided Display Properties’ Settings page.
2. What type of behaviour the primary display will exhibit. Can be one of the following
behaviours:
a. Single
b. Merge (all flavours)
c. Clone
3. The mode applied on a given display
The following scenarios are possible:
Select Multiple Independent Displays
Select Mode to apply to each display
Select Single Independent Display
Select the behaviour of the display
Select the mode to apply on the display
To choose between one and multiple independent displays, see EnableIndependentDisplaEnableIndependentDisplay in the
[Setup] section. Note: Automatic attachment of displays is not directly supported – see Migration
Tool for this capability.
To select the appropriate behaviour of a single independent display, see ApplyDisplaySetup in the
[Command] section. Note: merged displays are not directly supported for MMS boards – see
Migration Tool for this capability.
To attach to the desktop a specific independent display in a given mode, see AttachDisplay in the
[Command] section.
To apply a specific mode (resolution, pixel depth and refresh rate) on a specific display, see
ApplyMode in the [Command] section.
2.3[Setup] Section
------------------
This section contains all directives related to the Driver Package Installation Process as a whole.
AutoMigrateG550
Description: Enables automatic migration of G550 driver settings from a driver version
older than 5.93 to the 5.96 driver.
Default value: False
EnableIndependentDisplays
Description: If set to true, will configure the display driver to publish independent displays
after the setup-initiated reboot.
Note: Supported on fresh install or when ResetDriverSettings is set to
True (see this command’s limitations).
If Setup is to be run via INF (no setup.exe) and no prompting is to occur, set
PromptForIndependentDisplays to False for the current entry to take
effect.
Default value: False.
Supported on: G400, G450, G550.
ForceInstall
Description: Specifies that the installation should always install the driver files regardless if
they are an older or same version as the drivers currently installed. (If set to
False, installation fails when trying to install an older driver).
Default value: True.
ForceNoReboot
Description: Prevent any reboot from occurring (a reboot may be needed to complete the
device(s) installation).
Default value: False.
InstallPowerDeskVisible
Description: If set to True, the PowerDesk Install Page1 is to be visible during setup. It
allows the user to control installation of the PowerDesk utilities.
Default value: False.
LogFile
Description: If present, specifies the path and file name of a log file where Setup will write
details about the installation process – including error messages. The log
entries are appended to the file.
Default value: None.
PreInstall
Description: True to enable pre-installation, False to disable it.
Default value: False.
PreInstallVisible
Description: If set to True, the pre-install check box is to be visible during setup.
Default value: False.
PreSelectAllFamily
Description: True to pre-select all families for installation, False to only pre-select boards
found in the system for installation.
Default value: False.
ResetAllSettings
Description: If set to True, delete all driver and PowerDesk settings before installation.
Default value: False.
Supported on: Windows XP, Windows Server 2003.
ResetAllSettingsVisible
Description: If set to True, the “overwrite PowerDesk Settings†option is to be visible
during setup.
Note: Supported only if SilentInstall (below) is set to False.
Default value: True.
Supported on: Windows XP, Windows Server 2003.
PromptForIndependentDisplays
Description: If set to True, the user will be prompted to enable independent displays for
each installed device.
Default value: True.
Supported on: G400, G450, G550.
SilentInstall
Description: If set to True, installs without any user interface being shown.
Default value: False.
2.4 [Command] Section
---------------------
This section contains commands to execute after each device installation. The commands in the
section will be executed following the order in which they appear in the section.
1 PowerDesk Install Page: page in the wizard asking the user if they want to install PowerDesk.
Note: The following commands are meant to provide a mean to automate tasks you can
manually perform with your product. Do NOT attempt to apply changes which cannot be
made manually through the user interface: such behavior is undefined and may render
your configuration unusable.
Possible commands are:
AttachDisplay
Description: Specifies to attach the specified display to the desktop.
Syntax: AttachDisplay(<Display index>, <Width>x<Height>[x<Pixel depth>]
[@<Refresh rate>][,<Left>,<Top>])
Where:
Display index: The index identifying the display published by the adapter where the
mode is to be applied. 0 is the primary display of the adapter, 1 and up
are the secondary displays of the adapter.
Width: The width (in pixels) of the mode. This parameter is required.
Height: The height (in pixels) of the mode. This parameter is required.
Pixel depth: The pixel depth (8, 16, 32…) of the mode. This parameter is optional.
Refresh rate: The refresh rate of the mode. This parameter is optional.
Left, Top: The location on the desktop where the specified display is to be
attached. These parameters are optional.
Examples: AttachDisplay(0, 1024x768)
AttachDisplay(1, 800x600x32, 1024, 0)
AttachDisplay(2, 1024x768@85, 1024, 0)
ApplyDisplaySetup
Description: Specifies a display setup to apply to the specified adapter.
Syntax: ApplyDisplaySetup(<Display setup>)
Where:
Display setup: represents the type of display setup to apply. Can be one of the
following values:
Single: The adapter reports a single display composed of a single
monitor where multi-display features are supported (and are to
be shown on a secondary monitor)
Merge2: The adapter reports a single display composed of 2 monitors.
Clone: The adapter reports a single display composed of one monitor,
but the monitor content is duplicated on a second monitor.
Examples: ApplyDisplaySetup(SingleNoFeature)
ApplyDisplaySetup(Single)
ApplyDisplaySetup(Merge2)
ApplyMode
Description: Specifies a mode to apply to the specified display of the installed adapter.
Syntax: ApplyMode(<Display index>,<Width>x<Height>[x<Pixel
depth>][@<Refresh rate>])
Where:
Display index: The index identifying the display published by the adapter where the
mode is to be applied. 0 is the primary display of the adapter, 1 and up
are the secondary displays of the adapter.
Width: The width (in pixels) of the mode. This parameter is required.
Height: The height (in pixels) of the mode. This parameter is required.
Pixel depth: The pixel depth (8, 16, 32…) of the mode. This parameter is optional.
Refresh rate: The refresh rate of the mode. This parameter is optional.
Examples: ApplyMode(0, 1024x768)
ApplyMode(1, 1280x1024x16)
ApplyMode(0, 1280x1024@85)
ApplyMode(1, 1600x1200x32@72)
Note: When a parameter is omitted, Windows decides which value to use for this
parameter.
ApplyTvStandard
Description: Specifies the TV standard to apply to the specified adapter output.
Syntax: ApplyTvStandard(<TV standard>)
Where:
TV standard: Represents the TV standard to apply. Can be one of the following
values:
NTSC: NTSC standard (used in North America)
PAL: PAL standard (used in Europe)
2.4.1 Device-Type-Specific [Command] Sections
---------------------------------------------
In order to control the Command section behaviour with a per-device-type precision, variations of
the [Command] section can be created. A device-type-specific [Command] section contains a devicetype-
specific suffix in the section name (see Appendix A).
For each device being installed, the generic [Command] section will be parsed and executed first,
followed by the [Command.<DeviceID>] section (if found), then finally the
[Command.<DeviceID>.<SubSystemID>] section (if found). When writing device-type-specific
command sections, be particularly careful about the sequence of execution described above.
2.5Advanced Customization
-------------------------
2.5.1 [AddReg] Section
----------------------
This section contains registry entries to add at install time. The [AddReg] section allows writing to
any location in the windows Registry. Each line represents an entry to write in the registry.
[AddReg] section entries respect the following syntax:
Syntax: <Base key>:<Path>:<Value name>:<Value type>:<Value>
Where:
Base key: Can be one of the following values:
HKCC HKEY_CURRENT_CONFIG
HKCR HKEY_CLASSES_ROOT
HKCU HKEY_CURRENT_USER
HKLM HKEY_LOCAL_MACHINE
HKU HKEY_USERS
HKR Registry key of the device being installed.
Path: Path to the key where the value is to be written. If the path contains
spaces, the path should be enclosed in double quotes.
NOTE: for the HKR base key value, no path exists – this section is empty
(the entry should read HKR::<Value name>:<Value type>:<Value>).
Value name: Name of the registry value. If the value name contains spaces, it should
be enclosed in double quotes.
Value Type: The type of value to write. The following types are supported:
BINARY: Used to store a single byte or a sequence of bytes.
DWORD: Used to store an integer value.
STRING: Used to store text.
Value: Actual value to write. The value formats for the supported types are:
BINARY: Each byte should be separated from the next by a comma. No
space is allowed.
DWORD: The value should be written in hexadecimal notation (prefixed by
0x) or as a decimal number.
STRING: A single word without the colon (:) character can be written as-is.
For multiple words or a string containing the colon character,
enclose the string in double-quotes.
Examples: HKLM:software\test:valueName1:STRING:"this is a test"
HKLM:software\test:valueName2:STRING:test
HKLM:software\Test:valueName3:STRING:â€ÂwordWith:Colonâ€Â
HKLM:"software\test with spaces":"value name with spaces":STRING:"this is a test"
HKLM:software\test:valueName4:BINARY:00,11,22,33,44
HKLM:software\test:valueName5:DWORD:0x123456AB
HKLM:software\test:valueName6:DWORD:12345678
HKLM:software\test:valueName7:DWORD:0x123456ab
2.5.1.1 Device-Type-Specific [AddReg] sections
----------------------------------------------
In order to add registry entries on a per-device-type basis, variations of the [AddReg] section can
be created. A device-type-specific [AddReg] section contains a device-type-specific suffix in the
section name (see Appendix A).
Note that the [AddReg] sections processing is performed from the generic to the specific – i.e. the
[AddReg] section is processed first, then the [AddReg.<DeviceID>] section (if any), then finally
the [AddReg.<DeviceID>.<SubSystemID>] section (if any).
2.5.2 [DelReg] Section
----------------------
This section contains registry entries to remove at install time. It allows the deletion of any registry
value or key. The [DelReg] section is processed before the corresponding [AddReg] section.
[DelReg] section entries respect the following syntax:
Syntax: <base key>:<path>:<value name>
Where:
Base key: Can be one of the following values:
HKCC HKEY_CURRENT_CONFIG
HKCR HKEY_CLASSES_ROOT
HKCU HKEY_CURRENT_USER
HKLM HKEY_LOCAL_MACHINE
HKU HKEY_USERS
HKR Registry key of the device being installed.
Path: Path to the key to the value to delete. If the path
contains spaces, the subpath should be enclosed in double
quotes. NOTE: for the HKR base key value, no subpath exists –
this section is empty (the entry should read HKR::<value
name>).
Value name: Name of the registry value to delete. If the value name contains spaces,
it should be enclosed in double quotes.
Examples: HKLM:software\test: test2
HKLM:"software\test with spaces": "value name with spaces"
2.5.2.1.1 Device-Type-Specific [DelReg] sections
------------------------------------------------
In order to remove registry entries on a per-device-type basis, variations of the [DelReg] section
can be created. A device-type-specific [DelReg] section contains a device-type-specific suffix in the
section name (see Appendix A).
Note that the [DelReg] variations sections are executed before the corresponding [AddReg]
sections – resulting in the following sequence:
1. [DelReg]
2. [AddReg]
3. [DelReg.<DeviceID>]
4. [AddReg.<DeviceID>]
5. [DelReg.<DeviceID>.<SubSystemID>]
6. [AddReg.<DeviceID>.<SubSystemID>]
2.6[ExecuteOnDeviceInstall] Section
-----------------------------------
This section contains all processes to execute on each device installation. It allows programs to be
executed after each device has been installed. The programs are executed following the order in
which they appear in the section.
[Execute] section entries respect the following syntax:
Syntax: <Execution type>:<Executable path and arguments>
Where:
Execution type: Can be one of the following values:
Launch: Start execution of the program without waiting for it to complete.
Wait: Start the execution of the program and wait for it to terminate
before proceeding with the following entries and / or the rest of
the setup sequence.
Executable path
And arguments: The fully qualified path and filename of the executable, followed by the
program arguments, if any.
NOTE: if the path and/or executable name contain white spaces,
enclose the path in double-quotes (“).
Examples: [ExecuteOnInstall]
Wait:Notepad.exe c:\boot.ini
Launch:â€ÂD:\Program Files\Accessories\Acrobat Reader\Acrobat\Acrobat.exe†help.pdf
Appendix A – Device-Type-Specific Descriptor Syntax
---------------------------------------------------
In order to add or remove registry entries on a per-device-type basis, variations of the [AddReg]
and [DelReg] sections can be created. A device-type-specific section contains a device-typespecific
suffix in the section name. A device-type-specific section will be processed only if the
installed device matches the section descriptor.
The syntax of device-type-specific descriptors is as follows:
Syntax: .<DeviceId>[.<SubSystemId>]
Where:
DeviceId: Is the PCI device ID of the display adapter. (See the appropriate Device
ID table document). This member is required.
SubSystemId: Is the PCI subsystem ID of the display adapter. (See the appropriate
Device ID table document). This member is optional.
For example, the following descriptors are valid:
.0527 Describes all devices based on the Parhelia graphics accelerator.
.0527.0840102B Describes the Parhelia 128MB Dual DVI device.
Note that the [AddReg] sections processing is performed from the generic to the specific – i.e. the
[AddReg] section is processed first, then the [AddReg.<DeviceID>] section (if any), then finally
the [AddReg.<DeviceID>.<SubSystemID>] section (if any). Also note that a [DelReg] section is
executed before the corresponding [AddReg] section.
The execution sequence is as follows:
[DelReg]
[AddReg]
[DelReg.<DeviceID>]
[AddReg.<DeviceID>]
[DelReg.<DeviceID>.<SubSystemID>]
[AddReg.<DeviceID>.<SubSystemID>]
Not all sections need to be present.
There is very little information available for creating customized installations of the Matrox G-series driver. I contacted Matrox who sent me the following:
For G-Series Unified Driver Packages
Version 2.00.01 SE and Up
Overview
--------
The Setup Programâs goal is to allow easy installation of the Matrox display driver packages.
The Setup program can run under various conditions (in âsilent modeâ or âbatch modeâ for OEMs or
IT deployment scenarios, from a CD-ROM installation program, etc.). This flexibility is obtained by
the use of entries specified in a configuration file suited to handle complex situations.
In addition, the Setup program displays a simple, user-friendly interface for the users who want to
initiate the driver installation through the wizard instead of by Windowsâ âHave Diskâ procedure
(which calls the INF procedure in silent mode).
Furthermore, the Setup utility is designed to install (and/or pre-install) any Matrox board present
or not in the computer as long as it is supported by the shipped drivers. The default entries used
with the Setup program (specified below) will affect the default parameters used during the
installation of all boards.
1 Setup.ini File Format
-----------------------
The file is composed of sections. A section begins with a section identifier, which is the section
name enclosed in square brackets â[]â. The section identifier stands by itself on a single line:
[SectionName]
The section content is defined as the lines following the section identifier until another section
identifier is encountered or the end of the file is reached. Each line is considered an independent
entry, unless one of the following conditions is encountered:
· A line-continuation symbol is present, in which case the following line is considered part of
the current line (see section 1.2 below).
· A line is a section inclusion statement, in which case the line is replaced by the included
section content (see section 1.3 below).
1.1End-Of-Line Comments
-----------------------
Each section line can be accompanied by a comment to the right of the lineâs useful statement
(a.k.a. the line entry). The comment identifier â\*â must be placed before the actual comment.
ValueName = ValueContent \* This is a comment
1.2Multi-Line Entries
---------------------
It is possible to format an entry on multiple lines (this might be useful for readability reasons). Use
the line-continuation identifier â\|â at the end of the entry, but before the comment (if any). The
following section fragment:
ValueName = 00,01,02,03, \|
04,05,06,07
ValueName2 = 00,01,02,03, \| \* Comment on part 1
04,05,06,07 \* Comment on part 2
Is processed as if it was written like this:
ValueName = 00,01,02,03,04,05,06,07
ValueName2 = 00,01,02,03,04,05,06,07 \* Comment on part 1 Comment on part 2
1.3Section Inclusion
--------------------
It is also possible to insert the content of another section at a specific location in the current
section. This is achieved by using the #include<> statement, where the name of the section to
include is located between the < and > characters.
For example, the following section fragment:
[Section1]
Value1 = 1
#include<Section2>
Value2 = 2
[Section2]
ValueA = a
ValueB = b
Is processed as if it was written like this:
[Section1]
Value1 = 1
ValueA = a
ValueB = b
Value2 = 2
2 Setup.ini Content
-------------------
In the following specification, the configuration file refers to the Setup.ini file. All section
headers listed in the configuration file must be enclosed with []. Ex: the setup section is labeled
[Setup]. In addition, quotation marks are unnecessary for any parameters and must not be used
in the actual Setup.ini unless explicitly specified.
2.1[Setup] Section
------------------
2.2Display Configuration Overview
---------------------------------
This sectionâs goal is to describe the various aspects of display configuration and how to go about
specifying a given configuration in unattended installation scenario.
There are up to three aspects to display configuration on any given display adapter:
1. The number of independent displays reported to Windows. This is the number of monitors
shown in the Microsoft-provided Display Propertiesâ Settings page.
2. What type of behaviour the primary display will exhibit. Can be one of the following
behaviours:
a. Single
b. Merge (all flavours)
c. Clone
3. The mode applied on a given display
The following scenarios are possible:
Select Multiple Independent Displays
Select Mode to apply to each display
Select Single Independent Display
Select the behaviour of the display
Select the mode to apply on the display
To choose between one and multiple independent displays, see EnableIndependentDisplaEnableIndependentDisplay in the
[Setup] section. Note: Automatic attachment of displays is not directly supported â see Migration
Tool for this capability.
To select the appropriate behaviour of a single independent display, see ApplyDisplaySetup in the
[Command] section. Note: merged displays are not directly supported for MMS boards â see
Migration Tool for this capability.
To attach to the desktop a specific independent display in a given mode, see AttachDisplay in the
[Command] section.
To apply a specific mode (resolution, pixel depth and refresh rate) on a specific display, see
ApplyMode in the [Command] section.
2.3[Setup] Section
------------------
This section contains all directives related to the Driver Package Installation Process as a whole.
AutoMigrateG550
Description: Enables automatic migration of G550 driver settings from a driver version
older than 5.93 to the 5.96 driver.
Default value: False
EnableIndependentDisplays
Description: If set to true, will configure the display driver to publish independent displays
after the setup-initiated reboot.
Note: Supported on fresh install or when ResetDriverSettings is set to
True (see this commandâs limitations).
If Setup is to be run via INF (no setup.exe) and no prompting is to occur, set
PromptForIndependentDisplays to False for the current entry to take
effect.
Default value: False.
Supported on: G400, G450, G550.
ForceInstall
Description: Specifies that the installation should always install the driver files regardless if
they are an older or same version as the drivers currently installed. (If set to
False, installation fails when trying to install an older driver).
Default value: True.
ForceNoReboot
Description: Prevent any reboot from occurring (a reboot may be needed to complete the
device(s) installation).
Default value: False.
InstallPowerDeskVisible
Description: If set to True, the PowerDesk Install Page1 is to be visible during setup. It
allows the user to control installation of the PowerDesk utilities.
Default value: False.
LogFile
Description: If present, specifies the path and file name of a log file where Setup will write
details about the installation process â including error messages. The log
entries are appended to the file.
Default value: None.
PreInstall
Description: True to enable pre-installation, False to disable it.
Default value: False.
PreInstallVisible
Description: If set to True, the pre-install check box is to be visible during setup.
Default value: False.
PreSelectAllFamily
Description: True to pre-select all families for installation, False to only pre-select boards
found in the system for installation.
Default value: False.
ResetAllSettings
Description: If set to True, delete all driver and PowerDesk settings before installation.
Default value: False.
Supported on: Windows XP, Windows Server 2003.
ResetAllSettingsVisible
Description: If set to True, the âoverwrite PowerDesk Settingsâ option is to be visible
during setup.
Note: Supported only if SilentInstall (below) is set to False.
Default value: True.
Supported on: Windows XP, Windows Server 2003.
PromptForIndependentDisplays
Description: If set to True, the user will be prompted to enable independent displays for
each installed device.
Default value: True.
Supported on: G400, G450, G550.
SilentInstall
Description: If set to True, installs without any user interface being shown.
Default value: False.
2.4 [Command] Section
---------------------
This section contains commands to execute after each device installation. The commands in the
section will be executed following the order in which they appear in the section.
1 PowerDesk Install Page: page in the wizard asking the user if they want to install PowerDesk.
Note: The following commands are meant to provide a mean to automate tasks you can
manually perform with your product. Do NOT attempt to apply changes which cannot be
made manually through the user interface: such behavior is undefined and may render
your configuration unusable.
Possible commands are:
AttachDisplay
Description: Specifies to attach the specified display to the desktop.
Syntax: AttachDisplay(<Display index>, <Width>x<Height>[x<Pixel depth>]
[@<Refresh rate>][,<Left>,<Top>])
Where:
Display index: The index identifying the display published by the adapter where the
mode is to be applied. 0 is the primary display of the adapter, 1 and up
are the secondary displays of the adapter.
Width: The width (in pixels) of the mode. This parameter is required.
Height: The height (in pixels) of the mode. This parameter is required.
Pixel depth: The pixel depth (8, 16, 32â¦) of the mode. This parameter is optional.
Refresh rate: The refresh rate of the mode. This parameter is optional.
Left, Top: The location on the desktop where the specified display is to be
attached. These parameters are optional.
Examples: AttachDisplay(0, 1024x768)
AttachDisplay(1, 800x600x32, 1024, 0)
AttachDisplay(2, 1024x768@85, 1024, 0)
ApplyDisplaySetup
Description: Specifies a display setup to apply to the specified adapter.
Syntax: ApplyDisplaySetup(<Display setup>)
Where:
Display setup: represents the type of display setup to apply. Can be one of the
following values:
Single: The adapter reports a single display composed of a single
monitor where multi-display features are supported (and are to
be shown on a secondary monitor)
Merge2: The adapter reports a single display composed of 2 monitors.
Clone: The adapter reports a single display composed of one monitor,
but the monitor content is duplicated on a second monitor.
Examples: ApplyDisplaySetup(SingleNoFeature)
ApplyDisplaySetup(Single)
ApplyDisplaySetup(Merge2)
ApplyMode
Description: Specifies a mode to apply to the specified display of the installed adapter.
Syntax: ApplyMode(<Display index>,<Width>x<Height>[x<Pixel
depth>][@<Refresh rate>])
Where:
Display index: The index identifying the display published by the adapter where the
mode is to be applied. 0 is the primary display of the adapter, 1 and up
are the secondary displays of the adapter.
Width: The width (in pixels) of the mode. This parameter is required.
Height: The height (in pixels) of the mode. This parameter is required.
Pixel depth: The pixel depth (8, 16, 32â¦) of the mode. This parameter is optional.
Refresh rate: The refresh rate of the mode. This parameter is optional.
Examples: ApplyMode(0, 1024x768)
ApplyMode(1, 1280x1024x16)
ApplyMode(0, 1280x1024@85)
ApplyMode(1, 1600x1200x32@72)
Note: When a parameter is omitted, Windows decides which value to use for this
parameter.
ApplyTvStandard
Description: Specifies the TV standard to apply to the specified adapter output.
Syntax: ApplyTvStandard(<TV standard>)
Where:
TV standard: Represents the TV standard to apply. Can be one of the following
values:
NTSC: NTSC standard (used in North America)
PAL: PAL standard (used in Europe)
2.4.1 Device-Type-Specific [Command] Sections
---------------------------------------------
In order to control the Command section behaviour with a per-device-type precision, variations of
the [Command] section can be created. A device-type-specific [Command] section contains a devicetype-
specific suffix in the section name (see Appendix A).
For each device being installed, the generic [Command] section will be parsed and executed first,
followed by the [Command.<DeviceID>] section (if found), then finally the
[Command.<DeviceID>.<SubSystemID>] section (if found). When writing device-type-specific
command sections, be particularly careful about the sequence of execution described above.
2.5Advanced Customization
-------------------------
2.5.1 [AddReg] Section
----------------------
This section contains registry entries to add at install time. The [AddReg] section allows writing to
any location in the windows Registry. Each line represents an entry to write in the registry.
[AddReg] section entries respect the following syntax:
Syntax: <Base key>:<Path>:<Value name>:<Value type>:<Value>
Where:
Base key: Can be one of the following values:
HKCC HKEY_CURRENT_CONFIG
HKCR HKEY_CLASSES_ROOT
HKCU HKEY_CURRENT_USER
HKLM HKEY_LOCAL_MACHINE
HKU HKEY_USERS
HKR Registry key of the device being installed.
Path: Path to the key where the value is to be written. If the path contains
spaces, the path should be enclosed in double quotes.
NOTE: for the HKR base key value, no path exists â this section is empty
(the entry should read HKR::<Value name>:<Value type>:<Value>).
Value name: Name of the registry value. If the value name contains spaces, it should
be enclosed in double quotes.
Value Type: The type of value to write. The following types are supported:
BINARY: Used to store a single byte or a sequence of bytes.
DWORD: Used to store an integer value.
STRING: Used to store text.
Value: Actual value to write. The value formats for the supported types are:
BINARY: Each byte should be separated from the next by a comma. No
space is allowed.
DWORD: The value should be written in hexadecimal notation (prefixed by
0x) or as a decimal number.
STRING: A single word without the colon (:) character can be written as-is.
For multiple words or a string containing the colon character,
enclose the string in double-quotes.
Examples: HKLM:software\test:valueName1:STRING:"this is a test"
HKLM:software\test:valueName2:STRING:test
HKLM:software\Test:valueName3:STRING:âwordWith:Colonâ
HKLM:"software\test with spaces":"value name with spaces":STRING:"this is a test"
HKLM:software\test:valueName4:BINARY:00,11,22,33,44
HKLM:software\test:valueName5:DWORD:0x123456AB
HKLM:software\test:valueName6:DWORD:12345678
HKLM:software\test:valueName7:DWORD:0x123456ab
2.5.1.1 Device-Type-Specific [AddReg] sections
----------------------------------------------
In order to add registry entries on a per-device-type basis, variations of the [AddReg] section can
be created. A device-type-specific [AddReg] section contains a device-type-specific suffix in the
section name (see Appendix A).
Note that the [AddReg] sections processing is performed from the generic to the specific â i.e. the
[AddReg] section is processed first, then the [AddReg.<DeviceID>] section (if any), then finally
the [AddReg.<DeviceID>.<SubSystemID>] section (if any).
2.5.2 [DelReg] Section
----------------------
This section contains registry entries to remove at install time. It allows the deletion of any registry
value or key. The [DelReg] section is processed before the corresponding [AddReg] section.
[DelReg] section entries respect the following syntax:
Syntax: <base key>:<path>:<value name>
Where:
Base key: Can be one of the following values:
HKCC HKEY_CURRENT_CONFIG
HKCR HKEY_CLASSES_ROOT
HKCU HKEY_CURRENT_USER
HKLM HKEY_LOCAL_MACHINE
HKU HKEY_USERS
HKR Registry key of the device being installed.
Path: Path to the key to the value to delete. If the path
contains spaces, the subpath should be enclosed in double
quotes. NOTE: for the HKR base key value, no subpath exists â
this section is empty (the entry should read HKR::<value
name>).
Value name: Name of the registry value to delete. If the value name contains spaces,
it should be enclosed in double quotes.
Examples: HKLM:software\test: test2
HKLM:"software\test with spaces": "value name with spaces"
2.5.2.1.1 Device-Type-Specific [DelReg] sections
------------------------------------------------
In order to remove registry entries on a per-device-type basis, variations of the [DelReg] section
can be created. A device-type-specific [DelReg] section contains a device-type-specific suffix in the
section name (see Appendix A).
Note that the [DelReg] variations sections are executed before the corresponding [AddReg]
sections â resulting in the following sequence:
1. [DelReg]
2. [AddReg]
3. [DelReg.<DeviceID>]
4. [AddReg.<DeviceID>]
5. [DelReg.<DeviceID>.<SubSystemID>]
6. [AddReg.<DeviceID>.<SubSystemID>]
2.6[ExecuteOnDeviceInstall] Section
-----------------------------------
This section contains all processes to execute on each device installation. It allows programs to be
executed after each device has been installed. The programs are executed following the order in
which they appear in the section.
[Execute] section entries respect the following syntax:
Syntax: <Execution type>:<Executable path and arguments>
Where:
Execution type: Can be one of the following values:
Launch: Start execution of the program without waiting for it to complete.
Wait: Start the execution of the program and wait for it to terminate
before proceeding with the following entries and / or the rest of
the setup sequence.
Executable path
And arguments: The fully qualified path and filename of the executable, followed by the
program arguments, if any.
NOTE: if the path and/or executable name contain white spaces,
enclose the path in double-quotes (â).
Examples: [ExecuteOnInstall]
Wait:Notepad.exe c:\boot.ini
Launch:âD:\Program Files\Accessories\Acrobat Reader\Acrobat\Acrobat.exeâ help.pdf
Appendix A â Device-Type-Specific Descriptor Syntax
---------------------------------------------------
In order to add or remove registry entries on a per-device-type basis, variations of the [AddReg]
and [DelReg] sections can be created. A device-type-specific section contains a device-typespecific
suffix in the section name. A device-type-specific section will be processed only if the
installed device matches the section descriptor.
The syntax of device-type-specific descriptors is as follows:
Syntax: .<DeviceId>[.<SubSystemId>]
Where:
DeviceId: Is the PCI device ID of the display adapter. (See the appropriate Device
ID table document). This member is required.
SubSystemId: Is the PCI subsystem ID of the display adapter. (See the appropriate
Device ID table document). This member is optional.
For example, the following descriptors are valid:
.0527 Describes all devices based on the Parhelia graphics accelerator.
.0527.0840102B Describes the Parhelia 128MB Dual DVI device.
Note that the [AddReg] sections processing is performed from the generic to the specific â i.e. the
[AddReg] section is processed first, then the [AddReg.<DeviceID>] section (if any), then finally
the [AddReg.<DeviceID>.<SubSystemID>] section (if any). Also note that a [DelReg] section is
executed before the corresponding [AddReg] section.
The execution sequence is as follows:
[DelReg]
[AddReg]
[DelReg.<DeviceID>]
[AddReg.<DeviceID>]
[DelReg.<DeviceID>.<SubSystemID>]
[AddReg.<DeviceID>.<SubSystemID>]
Not all sections need to be present.
Questions & Answers related to MATROX G-Series Unified Driver Package
Blogs (0)
Blog posts related to MATROX G-Series Unified Driver Package
Links (0)
Links related to MATROX G-Series Unified Driver Package
Reviews (0)
Reviews related to MATROX G-Series Unified Driver Package
This website uses cookies.
By continuing to use this site and/or clicking the "Accept" button you are providing consent
Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our
websites or when you do business with us. For more information about our
Privacy Policy and our data protection
efforts, please visit
GDPR-HQ
