📄 readme-cp2.html
字号:
<tr>
<td>65878</td>
<td>Polygon region calculation error</td>
</tr>
<tr>
<td>65968</td>
<td>Synchronization of window closing and paint requests can cause a crash</td>
</tr>
<tr>
<td>67776</td>
<td>uglPolyFill crashes if coordinates are negative</td>
</tr>
<tr>
<td>67837</td>
<td>Test for invalid line is not correct in uglGenericLine</td>
</tr>
<tr>
<td>68362</td>
<td>With UNICORN defined for the MediaGX driver, a different value
is suggested for VM_STATE_FOR_IO than standard MediaGX driver</td>
</tr>
<tr>
<td>69117</td>
<td>Event compression references an uninitialized event</td>
</tr>
<tr>
<td>69122</td>
<td>Generic fill routines don't support raster ops</td>
</tr>
<tr>
<td>69123</td>
<td>Simsolaris needs to support Solaris 2.7</td>
</tr>
<tr>
<td>69178</td>
<td>Acceration problem with SH4</td>
</tr>
<tr>
<td>69179</td>
<td>Optimizations for SH need to be turned on</td>
</tr>
<tr>
<td>69319</td>
<td>Generic 1bit fill routines do not support raster ops</td>
</tr>
</table>
<h3>
4.3 Additional Features/Capabilities</h3>
<p><br>In addition to the above bugs, the patch also contains the following
new features:
<br>
<blockquote>
<li>
Support the Tvia IGS 5050 on the Malta MIPs platform (provides graphics
and video in big and little endian and audio in little endian)</li>
<li>
Support for tool chains other than the standard gnu tool chain when using
the WindML configuration tool. The desired tool chain is selected
from the Miscellaneous page</li>
<li>
Improved 3rd party driver integration. See <a href="#Integration">Integration
of Additional Device Drivers</a></li>
</blockquote>
<hr width="100%">
<h2>
5. <a NAME="Agfa"></a>Agfa Monotype Font Engine Installation and Configuration</h2>
<h3>
5.1 Agfa Installation</h3>
The AGFA font engine for WindML must be obtained from Agfa Monotype. After
installing WindML, follow the instructions provided by Agfa Monotype to
install the font engine.
<h3>
5.2 Agfa Configuration from the WindML Config Tool</h3>
Once installed, the AGFA font engine is reflected in the WindML configuration
tool. When Agfa Fonts is selected from the Configuration Item menu of the
configuration tool, the configuration items for AGFA fonts are displayed.
These items are:
<p><b>Path</b> - location of the support files pcl___zf.fco and plug__zf.fco
on the target file system. The default, /mem indicates that these files
are found in the VxWorks memory-resident file system (memDrv()). (See <a href="#5.5 Memory Resident">Memory
Resident Fonts</a>, for more information.) If a different file system is
used, these files must be copied from the directory
<p>$WIND_BASE/target/src/ugl/fonts/agfa/mtfonts
<p>to the target file system, and the Path field must indicate the directory
in which these files are located.
<p><b>Type Path</b> - location of the files uif.ss, umt.ss, and utt.ss.
These files must be copied from
<p>$WIND_BASE/target/src/ugl/fonts/agfa/support
<p>to a location where they can be found by the target file system, and
this location must be entered in the Type Path field.
<p><b>File Name</b> - file containing the fonts. At present, this file
must be pcl___zf.fco, which contains the AGFA Micro-Type fonts. If a different
font file is required, including True-Type fonts, manual configuration
is necessary. (See <a href="#5.3 Manual Configuration of Agfa">Manual Configuration</a>,
for more information.)
<p><b>Plugin name</b> -this must not be changed from plug__zf.fco. Again,
if a different file is needed, manual configuration is necessary. (See
<a href="#5.3 Manual Configuration of Agfa">Manual
Configuration</a>, for more information.) Note that a forward slash ("/")
must be used for the directory separator character in the path fields.
<p>If any fonts are included from the font list, the AGFA font engine is
automatically included in the WindML build.
<h3>
<a NAME="5.3 Manual Configuration of Agfa"></a>5.3 Manual Configuration
of Agfa</h3>
Manual configuration is required when building WindML from the command
line or when a font file other than the default Micro-Type font file pcl___zf.fco
is desired. This means that True-Type fonts require manual configuration.
<p>The following are general instructions for manually configuring AGFA:
<p>1. Identify the font files to be included in the configuration. These
may be AGFA Micro-Type fonts, or True Type fonts. Note that only the Micro-Type
files that end with *zf.fco are supported.
<p>2. If using true type fonts, edit the file udAgfa.h in the directory
$WIND_BASE/target/h/ugl/driver/font and make the following changes:
<p><tt>#undef INCLUDE_UGL_AGFA_MICROTYPE</tt>
<br><tt>#define INCLUDE_UGL_AGFA_TRUETYPE</tt>
<p>3. Using the file ufpcl.c found in the directory $WIND_BASE/target/src/ugl/fonts/agfa/mtfonts
as a template, create a C source code file that contains font descriptors
for each of the fonts to be used. (See the UGL_AGFA_FONT_DESC type definition
in target/h/ugl/driver/font/udAgfa.h for more information about the font
descriptors.) Note that the font descriptors for True-Type fonts are slightly
different than those for micro-type fonts.
<p>4. Edit the Makefile found in $WIND_BASE/target/src/ugl/fonts/agfa and
ensure that the SUBDIRS definition includes the subdirectory containing
the file created in step 3.
<p>5. Edit the file uglAgfaCfg.c found in $WIND_BASE/target/src/ugl/config
and do the following:
<p>- Make sure uglAgfaPath and uglAgfaTypePath specify the proper directories
on the target file system. These are the same directories entered into
the Path and Type Path fields of the configuration utility as described
in the previous section.
<p>- Make sure that uglAgfaFileName specifies the correct font file. (This
string is only used for micro-type fonts. True-Type font files are specified
in the font descriptors created in step 3.)
<p>- Make sure that uglAgfaPluginName specifies the correct plug-in. This
should be plug__zf.fco.
<p>- Edit the uglAgfaFontData array to include all the desired font descriptors
created in step 3. Corresponding extern definitions for these font descriptors
should be added in this file, or in udAgfa.h.
<p>6. Change directories to $WIND_BASE/target/src/ugl and build WindML.
For example:
<p><tt>% cd $WINDBASE/target/src/ugl</tt>
<br><tt>% make CPU=CPU_TYPE AGFA=TRUE</tt>
<p>For a list of build options and instructions, type "make help". Make
sure to define AGFA=TRUE when building from the command line.
<h3>
5.4 Anti-Aliasing</h3>
A special routine, uglAgfaFontGrayscaleSet() is provided by the AGFA font
driver to turn on anti-aliasing for a particular font. (Note that the term
"grayscale" is used loosely as the actual output may be various shades
of any color.) The prototype for this is call is shown below:
<p><tt>UGL_STATUS uglAgfaFontGrayscaleSet</tt>
<br><tt>(</tt>
<br><tt>UGL_FONT * pFont,</tt>
<br><tt>int alignment,</tt>
<br><tt>int numXsubpixels,</tt>
<br><tt>int numYsubpixels,</tt>
<br><tt>int numXphase,</tt>
<br><tt>int numYphase</tt>
<br><tt>);</tt>
<p><b>pFont</b> - identifies the font to be anti-aliased.
<br><b>Alignment</b> - specifies the grid alignment scheme. These schemes
are shown below.
<p>Consult AGFA documentation for information about these schemes:
<p><tt>#define UGL_AGFA_GAGG 0 /* GRID in X, GRID in Y */</tt>
<br><tt>#define UGL_AGFA_GAGH 1 /* GRID in X, HALFGRID in Y */</tt>
<br><tt>#define UGL_AGFA_GAGP 2 /* GRID in X, PHASE in Y */</tt>
<br><tt>#define UGL_AGFA_GAHG 3 /* HALFGRID in X, GRID in Y */</tt>
<br><tt>#define UGL_AGFA_GAHH 4 /* HALFGRID in X, HALFGRID in Y */</tt>
<br><tt>#define UGL_AGFA_GAHP 5 /* HALFGRID in X, PHASE in Y */</tt>
<br><tt>#define UGL_AGFA_GAPG 6 /* PHASE in X, GRID in Y */</tt>
<br><tt>#define UGL_AGFA_GAPH 7 /* PHASE in X, HALFGRID in Y */</tt>
<br><tt>#define UGL_AGFA_GAPP 8 /* PHASE in X, PHASE in Y */</tt>
<p><b>numXsubpixels</b> and <b>numYsubpixels</b> - Used to set the grayscale
factor. For example, the values x=4, y=4 provide a grayscale pixel value
between 0 (foreground color) and 15 (background color). Consult AGFA documentation
for more information.
<p><b>numXphase</b> and <b>numYphase</b> - specify the directional shifts
of a sampling grid. The value 1 indicates phasing is disabled. Consult
AGFA documentation for more information.
<p>The code sample given below shows a typical call to uglAgfaFontGrayscaleSet()
that generally produces good results:
<p><tt>uglAgfaFontGrayscaleSet (myFontId, 0, 4, 4, 1, 1);</tt>
<h3>
<a NAME="5.5 Memory Resident"></a>5.5 Memory Resident Fonts</h3>
Agfa fonts are retrieved from a file system. The VxWorks memory-resident
file system driver, memDrv(), may be used when a physical file system is
not available, or to improve performance. Note that loading of fonts is
very slow when using the Target Server File System (TSFS). The procedure
for using memDrv() is summarized below:
<p>1. Configure Agfa and retain the default path /mem in the Path and Type
Path fields of the AGFA configuration.
<p>2. Create a temporary directory and copy the files required for the
desired fonts to that directory. Consult the Agfa documentation for the
files required for a specified font. For example:
<p><tt>% cd target/src/ugl/fonts/agfa</tt>
<br><tt>% mkdir myagfa</tt>
<br><tt>% cp mtfonts/pcl___zf.fco myagfa</tt>
<br><tt>% cp mtfonts/plug__zf.fco myagfa</tt>
<br><tt>% cp support/uif.ss myagfa</tt>
<br><tt>% cp support/umt.ss myagfa</tt>
<br><tt>% cp support/utt.ss myagfa</tt>
<p>3. Run the memdrvbuild tool from the Tornado bin directory:
<p><tt>% memdrvbuild -o agfafonts -m /mem myagfa</tt>
<p>This creates two files, agfafonts.c and agfafonts.h.
<p>4. Copy the two files, agfafonts.c and agfafonts.h, into your project
directory, and include them in your VxWorks project so that they are built
and linked into the VxWorks image.
<p>5. To make sure the memory driver gets linked into the image and initialized
at startup, add the lines to usrAppInit.c:
<p><tt>memDrv();</tt>
<br><tt>memDrvAddFiles_mem();</tt>
<br>
<hr width="100%">
<h2>
6. <a NAME="Integration"></a>Integration of Additional Device Drivers</h2>
This cumulative patch allows the integration of new device drivers into
the configuration tool without requiring the modification of any WindML
source files (including header and Makefiles). The source and header
files for a device driver may be placed in any directory. This means
that the driver may be located within a BSP directory and compiled as part
of the VxWorks BSP or the target/src/ugl/drivers/graphics directory.
<h3>
6.1 Building the Driver Using the Configuration Tool</h3>
If it is desired to build the device driver using the WindML configuration
tool, then the source for the driver must be placed within the target/src/driver/graphics
directory for a graphics device. A new subdirectory must be created
for the driver source files. For example, if a new driver called
"stormpad" is to be added, then a directory named "stormpad" should be
added to the graphics subdirectory. The actual name isn't important. Place
all source files within this directory.
<p>If adding a new device driver for either a keyboard or a mouse, then
the source file for the new keyboard or mouse should be added to the target/src/ugl/driver/keyboard
or target/src/ugl/driver/mouse directories, as appropriate. Note
that a new subdirectory is not created for the new mouse or keyboard device.
<p>If it is not desired to build the driver using the WindML configuration
tool, then the source for the driver may be placed anywhere within the
Tornado tree. In this case the configuration tool may be used to specify
the configuration of the device even if it is a directory outside of the
WindML directory tree. In this case, everything but the driver will continue
to be built via the WindML configuration tool.
<h3>
6.2 Hooking the driver into the Configuration Tool</h3>
Hooking a device driver into the configuration tool involves the creation
of a configuration data base file. The configuration data base file
must be located within the host/resource/ugl directory. The name
of the configuration data base file can be any name that suits the device
driver writer as long as the file name ends in .cfg. For example,
the "stormpad" device driver example above may have a configuration file
called stormpad.cfg. After this data base file is properly formatted
to describe the driver capabilities and placed in the host/resource/ugl
directory, Tornado will need to be restarted in order to see the file.
<p>After Tornado is restarted and the WindML configuration tool is started,
the new device will be available for selection.
<h3>
6.3 Configuration Data Base Format</h3>
The configuration database for a new device driver extends the basic WindML
configuration provided in the uglDB.cfg file. After the uglDB.cfg
file is read, all other *.cfg files are read to augment the basic configuration.
<p>The data base file consists of several sections to define the pointer,
keyboard, output device types, and graphics devices.
<p>Lines that start with a single "#" signifies a comments, for example:
<p><tt># This is a comment line</tt>
<p>Lines that start with a "##" is a section marker. Following the
"##" there is a space and then the name of the section.
<h3>
6.4 Pointer Definition</h3>
The pointer definition section starts with a "## POINTER" and ends with
"END". In between each of these statements are the statements to define
the pointer that consists of device name, supported processor architectures,
location of the header file to define the pointer, etc.
<p>The database entries that are required to define a pointer are:
<p><b>DEVICE</b> - name of the device. This is the name of the device
that will appear in the pull-down menu of the configuration tool.
<p><b>ARCH</b> - identifies the processor architectures that the pointer
device will operate. At least one ARCH entry must be present.
Additional ARCH entries may be present to specify the additional processor
architectures that the new pointer device may be used.
<p><b>SELECT</b> - identifies the #define directive to include the
support for the pointer. This value will be placed within the generated
header file.
<p><b>DEVNAME</b> - the default name of the I/O device that is used for
the pointer.
<p><b>HEADER</b> - path to the header file that defines miscellaneous data
items required for the configuration process. This path name should
be relative to the setting of WIND_BASE. Refer to the section on
device header file requirements for definitions needed to support the configuration
process.
<p><b>BSPHDR</b> - not used, but must be present
<p>The following is an example entry to define a new type of PS-2 mouse:
<p><tt>## POINTER</tt>
<br><tt>#</tt>
<br><tt># Pointer for the Stormpad</tt>
<br><tt>#</tt>
<br><tt>START</tt>
<p><tt># Stormpad PS-2 mouse</tt>
<p><tt>DEVICE Stormpad PS-2 Mouse</tt>
<br><tt>ARCH ARMARCH4</tt>
<br><tt>SELECT INCLUDE_SP_PS2_POINTER</tt>
<br><tt>DEVNAME "/ps2/0"</tt>
<br><tt>HEADER target/config/stormpad/stormpad.h</tt>
<br><tt>BSPHDR</tt>
<p><tt>END</tt>
<h3>
6.5 Keyboard Definition</h3>
The keyboard definition section starts with a "## KEYBOARD TYPES" and ends
with "END". In between each of these statements are the statements
to define the keyboard that consists of device name, supported processor
architectures, location of the header file to define the keyboard, etc.
<p>The database entries that are required to define a keyboard are:
<p><b>DEVICE</b> - name of the device. This is the name of the device
that will appear in the pull-down menu of the configuration tool.
<p><b>ARCH</b> - identifies the processor architectures that the keyboard
device will operate. At least one ARCH entry must be present.
Additional ARCH entries may be present for additional architectures.
<p><b>SELECT</b> - identifies the #define directive to include the
support for the keyboard. This value will be placed within the generated
header file.
<p><b>DEVNAME</b> - the default name of the I/O device used for the keyboard.
<p><b>MAP</b> - defines the keyboard maps that are supported, these can
be any combinations of:
<p>INCLUDE_KMAP_ENGLISH_US
<br>INCLUDE_KMAP_ENGLISH_UK
<br>INCLUDE_KMAP_GERMAN
<br>INCLUDE_KMAP_ITALIAN
<br>INCLUDE_KMAP_FRENCH
<br>INCLUDE_KMAP_SWEDISH
<br>INCLUDE_KMAP_NONE
<p><b>HEADER</b> - path to the header file that defines miscellaneous data
items required for the configuration process. This path name should
be relative to the setting of WIND_BASE. Refer to the section on
device header file requirements for definitions needed to support the configuration
process.
<p><b>BSPHDR</b> - not used, but must be present
<p>The following is an example entry to define a new type of keyboard to
support an infrared keyboard:
<p><tt>## KEYBOARD TYPES</tt>
<br><tt>#</tt>
<br><tt># Infra red keyboard</tt>
<br><tt>#</tt>
<br><tt>START</tt>
<p><tt># stormpad consumer IR keyboard</tt>
<p><tt>DEVICE Stormpad IR keyboard</tt>
<br><tt>ARCH ARMARCH4</tt>
<br><tt>MAP INCLUDE_KMAP_ENGLISH_US</tt>
<br><tt>MAP INCLUDE_KMAP_ENGLISH_UK</tt>
<br><tt>MAP INCLUDE_KMAP_GERMAN</tt>
<br><tt>MAP INCLUDE_KMAP_ITALIAN</tt>
<br><tt>MAP INCLUDE_KMAP_FRENCH</tt>
<br><tt>MAP INCLUDE_KMAP_SWEDISH</tt>
<br><tt>MAP INCLUDE_KMAP_NONE</tt>
<br><tt>SELECT INCLUDE_SP_IR_KEYBOARD</tt>
<br><tt>DEVNAME "/irKbd/0"</tt>
<br><tt>HEADER target/config/stormpad/stormpad.h</tt>
<br><tt>BSPHDR</tt>
<p><tt>END</tt>
<h3>
6.6 Output Device Definition</h3>
Frequently when a new graphics device is added, new output devices are
also required, such as flat panel displays. The "Output" section
of the database is used to define new entries that are added to the list
of output device types that may be selected for a graphics device.
The output section is started by the entry "## OUTPUT DEVICE TYPES".
This section has a single entry to define the output type and include directive
to include the output type, as follows:
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -