Verify DirectDraw (Compact 7)
3/12/2014
The Verify DirectDraw test analyzes basic DirectDraw functionality including block image transfers (blits), scaling, color keying, color filling, flipping, and overlaying. This test runs only if the display hardware on the target device supports DirectDraw.
Test Prerequisites
Your device must meet the following requirements before you run this test.
The following table shows the hardware requirement for the DirectDraw Test.
Requirement | Description |
---|---|
Video subsystem |
A video subsystem that supports DirectDraw. |
The following table shows the software requirements for the DirectDraw Test.
Requirements | Description |
---|---|
Tux.exe |
Tux test harness, required for executing the test |
Kato.dll |
Kato logging engine, required for logging test data |
DDrawTK.dll |
Test library |
Before you run the DirectDraw Test, you must include Microsoft DirectX and DirectDraw in your operating system (OS) design. The SYSGEN_DDRAW Sysgen variable adds the required functionality to your OS design.
Note: When you run the DirectDraw Test, the Windows Embedded Compact Test Kit (CTK) temporarily copies files to the root directory of the target device. While the test runs, the test dynamically consumes program memory on the target device. Before running the test, verify that there is at least 0.9 megabytes (MB) of free storage memory on the target device. Also verify that there is at least 1.5 MB of free program memory on the target device. If there is not sufficient space in the root directory of the target device or there is not sufficient program memory, the test cannot run.
Subtests
The table below lists the subtests included in this test.
SubTest ID | Description |
---|---|
100 |
Get Caps : Retrieves the capabilities of the hardware abstraction layer (HAL), verifies that the operation is successful, and then displays all capabilities retrieved. This test case fails if it cannot retrieve the capabilities of the HAL. |
101 |
Enumerate Display Modes : Enumerates the DirectDraw display modes, verifies that the enumeration completes, and then displays the results of the enumeration. |
102 |
Verify Surface Creation: The test cycles through the different surface types (disregard what has been reported as being supported) and verify if the surface can be created successfully. The test case fails if a supported surface cannot be created or if an unsupported surface can be created. |
110 |
VBID Surface Creation: The test tries to create VBID surfaces with different settings and verify if it can be created and execute a variety of operations for the surface created with valid parameters. The test case fails if invalid creation succeeds, valid creation fails or the following operation's behavior on valid surface is not as expected. |
120 |
VBID Surface Data Handling: Verifies if the VBID data was properly handled. The test case creates a surface with valid VBID description, then runs through with invalid type and field data, invalid type with valid field, valid type with random field and valid data with valid field. The test case fails if the behavior of unlock of VBID surface is different than expected. |
200 |
Blt (Windowed Mode) : Executes blits to and from various surfaces. The test case verifies that the actual destination matches the expected destination for each blit. This test case fails if any blits are unsuccessful. |
210 |
ColorKey Blt (Windowed Mode) : Executes a variety of color key blits to and from assorted surfaces. The test case verifies that the actual destination matches the expected destination for each test. This test case fails if any color key blits are unsuccessful. |
220 |
Color Filling Blts (Windowed Mode) : Executes a variety of color fill blits to assorted surfaces. The test case verifies that the surface is filled with the specified color. This test case fails if any color fill blits are unsuccessful. |
230 |
Set/GetPixel Verification (Windowed Mode): Tests that SetPixel() and GetPixel() work correctly. The tests set pixel to black/white color and get it back for verification, then release the DC and lock it again, then use direct memory access to verify it is the color set by SetPixel(). The test fails if any of these verification steps fails. |
240 |
Flip (Windowed Mode): Executes a variety of blits to a flipping chain and verifies that the flips are successful and that all surfaces display correctly. This test case fails if any flips or surface verifications fail. |
250 |
Flip Interlaced (Windowed Mode): Tests that Flip() works correctly in interlaced Flipping surface, by doing flip with a variety of flags. The test verifies if the flip succeeds with valid flag settings and fails with invalid ones. The test will fail if the behavior is not as expected. |
260 |
Get Surface Description Test (Windowed Mode) : Tests that GetSurfaceDesc() works correctly in all supported display modes/orientations. |
300 |
Blt (Exclusive Mode) : Executes a variety of blits to and from assorted surfaces. The test case verifies that the actual destination matches the expected destination for test. This test case fails if any blits are unsuccessful. |
310 |
ColorKey Blt (Exclusive Mode) : Executes a variety of color key blits to and from assorted surfaces. The test case verifies that the actual destination matches the expected destination for each test. This test case fails if any color key blits are unsuccessful. |
320 |
Color Filling Blts (Exclusive Mode) : Executes a variety of color fill blits to assorted surfaces. The test case verifies that the surface is filled with the specified color. This test case fails if any color fill blits are unsuccessful. |
330 |
Flip (Exclusive Mode) : Executes a variety of blits to a flipping chain and verifies that the flips are successful and that all surfaces display correctly. This test case fails if any flips or surface verifications fail. |
340 |
Set/GetPixel Verification (Exclusive Mode): Tests SetPixel() and GetPixel() work correctly. The test sets first pixel to black/white color and gets it back for verification. After that it releases the DC and locks it again then uses direct memory access to verify the first pixel is the color set by SetPixel(). The test fails if any of these verification steps fails. |
350 |
Flip Interlaced (Exclusive Mode): Tests that Flip() works correctly in interlaced Flipping surface, by doing flip with a variety of flags. The test verifies if the flip succeeds with valid flag settings and fails with invalid ones. The test will fail if the behavior is not as expected. |
360 |
Get Surface Description Test (Exclusive Mode) : Tests that GetSurfaceDesc() works correctly in all supported display modes/orientations. |
400 |
CreateVideoPort (Video Port Container Test) : Enumerates the available video ports and connections for the video ports. This test case then verifies that each enumerated connection can be created. |
410 |
EnumVideoPorts (Video Port Container Test) : Enumerates the available video ports and then enumerates the video ports based on specific capabilities. |
420 |
GetVideoPortConnectInfo (Video Port Container Test) : Verifies that the GetVideoPortConnectInfo function appropriately handles a variety of input conditions. |
430 |
QueryVideoPortStatus (Video Port Container Test) : Verifies that the QueryVideoPortStatus function appropriately handles each video port. |
500 |
GetBandwidthInfo (Video Port Test) : Verifies that the GetBandwidthInfo function returns consistent information about each type of video port available. |
502 |
GetSetColorControls (Video Port Test) : Verifies that the GetColorControls and SetColorControls functions set and return consistent color controls if color control is supported. |
504 |
GetInputOutputFormats (Video Port Test): Verifies that the GetInputFormats and GetOutputFormats functions return consistent information under a variety of calling conditions. |
506 |
GetFieldPolarity (Video Port Test) : Verifies that the GetFieldPolarity function returns consistent information about the field polarity of a video port. |
508 |
GetVideoLine (Video Port Test) : Verifies that the GetVideoLine function returns consistent information. |
510 |
GetVideoSignalStatus (Video Port Test) : Verifies that the GetVideoSignalStatus function returns consistent information. |
512 |
SetTargetSurface (Video Port Test) : Verifies that the SetTargetSurface function appropriately handles improper input. |
514 |
StartVideo (Video Port Test) : Verifies that calls to the StartVideo function succeed with a variety of flags set. |
516 |
StopVideo (Video Port Test) : Verifies that a call to the StopVideo function succeeds. |
518 |
UpdateVideo (Video Port Test) : Verifies that calls to the UpdateVideo function succeed with a variety of flags set. |
520 |
WaitForSync (Video Port Test) : Verifies that the WaitForSync function behaves consistently with each possible flag. |
1200 |
Blt (Interactive Windowed Mode) : Executes blits that include color fills and scaling. You must manually verify that each blit is successful. |
1240 |
Overlay Blt (Interactive Windowed Mode) : Executes blits to an overlay surface. The test cannot verify that the contents of the overlay surface display correctly, so you should manually verify that the output is correct. If the test succeeds, an overlay appears in the middle of the screen with a blue and yellow checkerboard pattern. This test may run as many as three times with the same output, testing RGB, YUYV, and VYUY pixel formats on the overlay surface. |
1250 |
ColorKeyOverlay Blt (Interactive Windowed Mode) : Executes color key blits to an overlay surface. The test cannot verify that the contents of the overlay surface display correctly, so you should manually verify that the output is correct. If the test succeeds, a blue checkerboard pattern appears in a variety of locations across the display of the target device. If the driver enables stretching, the test also stretches the checkerboard pattern. This test may run as many as three times with the same output, testing RGB, YUYV, and VYUY pixel formats on the overlay surface. |
1260 |
ColorFill Overlay Blt (Interactive Windowed Mode) : Executes color fill blits to an overlay surface. The test cannot verify that the contents of the overlay surface display correctly, so you should manually verify that the output is correct. This test case cycles through red, green and blue on the primary overlay surface. This test may run as many as three times with the same output, testing RGB, YUYV, and VYUY pixel formats on the overlay surface. |
1270 |
Interlaced Overlay Flip (Interactive Windowed Mode): The test animates two boxes on the screen. Each box is 2 pixels tall. One box will start on an odd line, the other box will start on an even line. The boxes will be right next to each other (to be easily distinguished, one from the other. In half the cases, the boxes will move up by two pixels every frame, the other half of the cases the boxes will move down by two pixels. The tester will need to determine which of the two boxes will look "better" (based on which field of the frame is being drawn first, the two boxes will appear slightly different: one will appear to be a solid box, while the other will flicker and appear to be two smaller boxes that "dance"). |
1300 |
Blt (Interactive Exclusive Mode) : Executes blits that you must verify when prompted. The test does not contain an automated mechanism for verifying scaling. |
1340 |
Overlay Blt (Interactive Exclusive Mode) : Executes blits to an overlay surface. The test cannot verify that the contents of the overlay surface display correctly, so you should manually verify that the output is correct. If the test succeeds, an overlay is located in the middle of the screen on the target device with blue and yellow horizontal lines. The primary surface behind the overlay surface should fill the entire display. This test may run as many as three times with the same output, testing RGB, YUYV, and VYUY pixel formats on the overlay surface. |
1350 |
ColorKeyOverlay Blt (Interactive Exclusive Mode) : Executes color key blits to an overlay surface. The test cannot verify that the contents of the overlay surface display correctly, so you should manually verify that the output is correct. If the test succeeds, blue horizontal bars appear across the display of the target device. The primary surface behind the overlay surface should fill the entire display. This test may run as many as three times with the same output, testing RGB, YUYV, and VYUY pixel formats on the overlay surface. |
1360 |
ColorFill Overlay Blt (Interactive Exclusive Mode) : Executes color key blits to an overlay surface. The test cannot verify that the contents of the overlay surface display correctly, so you should manually verify that the output is correct. If the test succeeds, blue horizontal bars appear across the display of the target device. The primary surface behind the overlay surface should fill the entire display. This test may run as many as three times with the same output, testing RGB, YUYV, and VYUY pixel formats on the overlay surface. |
1370 |
Interlaced Overlay Flip (Interactive Exclusive Mode): The test animates two boxes on the screen. Each box is 2 pixels tall. One box will start on an odd line, the other box will start on an even line. The boxes will be right next to each other (to be easily distinguished, one from the other. In half the cases, the boxes will move up by two pixels every frame, the other half of the cases the boxes will move down by two pixels. The tester will need to determine which of the two boxes will look "better" (based on which field of the frame is being drawn first, the two boxes will appear slightly different: one will appear to be a solid box, while the other will flicker and appear to be two smaller boxes that "dance"). |
Setting Up the Test
This test has no additional requirements, beyond the standard test environment setup.
Running the Test
Command Line Parameters for the DirectDraw Test
Command line parameter | Description |
---|---|
i |
Runs test cases 1200 through 1360 interactively. If you specify this option, the test prompts you to verify that each image for these test cases displays correctly. |
d |
Pauses the test while displaying each image for test cases 1200 through 1360. If you specify this option, the test pauses momentarily to allow you to view the image. The test does not allow you to provide data indicating whether the image is correctly displayed. If the test encounters an unrecognized pixel format, the test can continue, but the colors displayed may not match the expected colors. |
a |
Automates the test. If you specify this option, the test verifies internally that each image displays correctly. |
Verifying the Test
When the test completes running, verify that "PASS" appears in the test log for all subtests.
Troubleshooting the Test
The following table shows problems that you may encounter while running the DirectDraw Test and suggestions for resolving each problem.
Description | Resolution |
---|---|
Multiple test cases abort with the message Set Display Mode Failed. The driver may be returning display modes other than the current display mode in the HALInit function and display mode switching is not supported. |
Verify that the driver returns an appropriate display mode in the HALInit function. |
Multiple test cases fail when trying to create surfaces in system memory. The driver may be returning an incorrect error when the CreateSurface callback function is called. |
When the CreateSurface callback function is called with a surface type that the driver cannot handle, the driver should return DDHAL_DRIVER_HANDLED with ddRVal=DDERR_UNSUPPORTEDFORMAT. |
Test cases fail while locking or unlocking. The driver may not be allocating video memory outside of the Graphics, Windowing, and Events Subsystem (GWES) process space. |
Allocate video memory outside of the GWES process space with file mapping. |
For additional platform specific issues, consult the CTK articles on the TechNet wiki.