Define 4 new config methods that provide the functionality
of the existing 11 similar methods. The usage of the existing
methods will be replaced by the new methods in successive
commits.
These new methods will also give control back to the test
cases to handle config attributes depending on need/use-case
and reduce the number fixture member variables needed.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
The m_ prefix for a variable indicates it's a member
variable. The g_ prefix indicates it's a global variable.
Use the correct prefix in test_data.h for global variables
and update usage accordingly.
Also, cleanup test_data.h formatting.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
m_querySurfaceAttribList was redefined in
doQuerySurfacesWithConfigAttribs which shadows the member
variable of the same name. Removing the redefinition does
not break tests, so remove it.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Add method to get minimum allowed surface resolution.
If driver does not specify, then assume 1x1 is min.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
If driver does not specify the max surface resolution,
then assume "any" max is allowed (up to numeric_limits).
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
880 (360 direct, 520 indirect) bytes in 1 blocks are definitely lost in loss record 12 of 15
at 0x4C2EF35: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x503FED9: va_newDisplayContext (in /usr/lib/libva.so.2.0.0)
by 0x4E39F32: vaGetDisplayDRM (in /usr/lib/libva-drm.so.2.0.0)
by 0x11ADD1: VAAPI::VAAPIFixture::getDisplay() (test_va_api_fixture.cpp:80)
by 0x11AE2E: VAAPI::VAAPIFixture_getDisplay_Test::TestBody() (test_va_api_fixture.cpp:527)
Signed-off-by: Victor Toso <victortoso@redhat.com>
This patch should not change the outcome as m_vaDisplay is NULL for
each failed vaGetDisplayDRM().
This is minor code readability improvement. Another approach would be
to break the loop when we find a valid VADisplay.
While at it, remove the empty line before variable declaration which
is not common in the majority of the source code.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Without a proper driver, vaInitialize() will fail at va_openDriver().
There is no point in returning a VADisplay in that case.
Without driver, instead segfault we will get:
16855 FAILED TESTS
Fix#77
Signed-off-by: Victor Toso <victortoso@redhat.com>
Don't expect vaMaxNumConfigAttributes to be 32.
vaMaxNumConfigAttributes result is defined by the driver
implementation and may not be the same for all drivers.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Some tests manipulate the LIBVA_DRIVER_NAME environment
variable for various reasons. This causes tests that
execute later on to behave unexpectedly.
Store the original user-defined LIBVA_DRIVER_NAME before
every test runs and restore it to the original value
when each test finishes. This allows the test suite
to be executed with any VAAPI driver.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
add a new test that will printout which profile/entrypoint
combinations will be skipped while running the suite.
Skipped tests are now recording a property and using test_streamable
to print profile/entrypoint without function calling.
Fixes#2
Signed-off-by: Daniel Charles <daniel.charles@intel.com>
This initial set of files covers the va.h API for all the
functions used to exercise successfully the VA-API.
Tests are divided per VA-API function with a common Fixture that
contains all calling functions to the VA-API. For the use cases
covered already there are tests for the proper functionality and also
for expected error situations.
The tests creates combinations with all the inputs to the VA-API function
and then it checks the results based on what the driver implementation reports
as supported
The set of tests can be run on any h/w supported and any driver.
The VendorString test is assuming Intel i965 driver, please help
adding the test for other drivers
More tests will be continously added
Signed-off-by: Daniel Charles <daniel.charles@intel.com>