| Age | Commit message (Collapse) | Author |
|---|
|
After scheduling an HPD toggle event, make sure that we wait for the
hotplug event for each connector that may be sent by the driver.
Depending on the scheduling there could be 1 event or as many events as
connectors we scheduled an HPD toggle event on, depending on the timing.
So if we don't yet see the expected connector state on a given connector
try to wait for an additional hotplug event and reprobe/recheck the
state.
v2:
- s/igt_assert(x >= y)/igt_assert_lte(y, x)/ to see the actual limits in
the debugging output. (Lyude)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110534
Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Cc: Lyude Paul <lyude@redhat.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-By: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
|
|
The audio test is now run multiple times with a variety of playback sampling
rates.
We now query the capture audio format from the Chamelium XML-RPC API instead of
hardcoding it.
One limitation is that we need to start sending an audio signal before being
able to query the capture audio format. However we need the capture sample rate
to decide which frequencies we generate. For now we use the playback rate and
check that it's the same as the capture rate.
Another limitation is that the DP receiver reports an unknown sampling rate
during the 44.1KHz test. In this case we assume the capture rate is the same as
the playback rate. We'll fail later anyway if this assumption is incorrect
since we check the signal we receive.
Chameleon bug: https://crbug.com/950913
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
Send a different signal to each channel and make sure captured audio channels
are not swapped or mixed up.
The Chamelium device has a bug and already swaps the left and right channels.
For this reason, clients need to retrieve the Chamelium channel mapping and
accomodate for this. See https://crbug.com/950922 for a discussion about this.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This commit updates the audio test to make sure we receive a signal from both
audio channels. However this commit doesn't check that left and right channels
are not swapped. Such a check requires some more work (because the Chamelium
device does swap left and right channels) and will be implemented in a future
commit.
This commit adds a new channel argument to audio_signal_add_frequency, to add
a frequency to a single channel only.
Some light refactoring has been performed: a proper audio_signal_fini
function has been introduced and size_t in now used when it should be.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
Before this patch, the audio test first sends an audio signal for 2s, and then
checks whether the captured signal matches.
This patch makes it so we send and check the signal in parallel. Thus we can
stop the test as soon as we receive the correct signal. This saves ~2s per
audio test.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This new test ensures DisplayPort audio works by using the Chamelium.
It enables the DisplayPort output and sends an audio signal containing a set of
frequencies we choose to all HDMI/DisplayPort audio devices. It starts
recording audio on the Chamelium device and uses the stream server to retrieve
captured audio pages. It then checks that the capture audio signal contains the
frequencies we sent, and only those, by computing a FFT.
A new library has been added to libigt to communicate with the stream server.
It implements a simple custom TCP protocol.
In case the test fails, a WAV file with the captured data is saved on disk.
Right now the test has a few limitations:
- Only the first channel is checked
- IGT only generates audio with a single sampling rate (48 KHz)
- Audio data is not captured in real-time
These limitations will be lifted in future patches.
PulseAudio must not run during the tests since ALSA is used directly. To ensure
this, edit /etc/pulse/client.conf and add `autospawn=no`. Then run
`pulseaudio --kill`.
This commit deletes the existing audio tests. They weren't run and required an
exotic configuration (HDMI audio splitter, dummy HDMI sink and a line-in port
on the DUT).
This patch also changes lib/igt_audio to use uint16_t instead of short. The
rationale is:
- The standard says a short is at least 16 bit wide, but a short can be
larger (in practice it won't happen, but better use types correctly)
- It makes it clearer that the audio format is S16_LE, since "16" is
in the type name.
This patch depends on the following Chameleon bugs:
- https://crbug.com/948060
- https://crbug.com/950857
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This function checks whether a port is an analog bridge. Analog
bridges provide their own EDID thus the vendor should be different
from "IGT".
There was a typo that made the function always return true for VGA
ports. The condition was essentially:
thing != 'I' || thing != 'T'
which is always true.
Apparently this didn't cause any harm, but it's probably better to fix
it anyway in case some tests were skipped and shouldn't.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Acked-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
Newer platforms don't support this format, but the tests don't check
if the format is supported on the primary plane.
After enabling an output we also don't refresh the output connection,
calling igt_output_set_pipe(output, PIPE_NONE) will do so, and prevent
skips because no connected output is detected.
Changes since v1:
- Use igt_plane_has_format_mod (Ville).
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
This introduces a new test for the Chamelium, that sets up planes
with randomized properties such as the format, dimensions, position,
in-framebuffer offsets and stride. The Chamelium capture is checked
against the reference generated by cairo with either a CRC or the
checkerboard-specific comparison method.
This test also includes testing of the VC4-specific T-tiled and
SAND-tiled modes, in all formats supported by the hardware.
Since this test does not share much with previous Chamelium display
tests (especially regarding KMS configuration), most of the code is
not shared with other tests.
This test can be derived with reproducible properties for regression
testing in the future. For now, it serves as a fuzzing test
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
Now that the checkerboard frame checking method is available through
the frame match helper, make use of it in YUV tests to increase the
reliability of the results.
The analog test tends to provide false positives, which are properly
detected by the checkerboard method in most instances.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
In prevision of adding support for another type of frame matching,
rename chamelium_assert_analog_frame_match_or_dump to drop the
analog part and feed it the check type. This way, the bulk of the
helper can apply to other frame matching types.
This requires moving the chamelium_check enum from the test to the
common chamelium header.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The modifier is part of how a frame is represented, so add it as an
extra argument so that it can be specified when converting framebuffers.
For now, only a linear modifier is supported.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
The NV12, NV16, NV21, NV61, YUV420, YVU420, YUV422 and YVU422 are YUV
formats that are currently supported in IGT.
We'll want to test those formats in addition to the RGB formats, so
let's add some subtests. One thing worth noting is some hardware isn't
able to output a pixel-perfect image, so we do the same kind of
comparison than for VGA.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The VGA tests were run so far as part of a separate function. However,
the only difference between that function and the do_test_display
function was the kind of comparison we wanted to use. Indeed, VGA
being an analog output, we can't rely on a pixel perfect image, and
thus only compare the CRCs, but we need to make some more advanced
comparison.
Let's add a new check method, add support for the analog check to
do_test_display and remove the old version.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The various tests in kms_chamelium are really variants of one another
but share little code.
In addition to the duplication, this gets in the way of the
introduction of more tests, or to be able to run all the tests on all
the output, which isn't the case at the moment, with the HDMI and DP
tests and the VGA tests being different.
Start by introducing a check parameter to the do_test_display
function, that will tell which test method we want to use to compare
the frames.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
This adds a new block size argument to the pattern generation helpers so
that different sizes of blocks can be used.
In the future, this allows us to use different block sizes when testing
overlay planes, making it visually explicit what is part of the main
plane and what is part of the overlay plane.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
In order to reuse the pattern generation helper for overlay planes,
let's provide the pattern generation helper with the explicit dimensions
instead of the mode (that only applies to the primary plane).
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
Using the width from the selected mode is not sufficient to correctly
paint a pattern on the framebuffer memory: the stride also has to be
taken in account for proper line start alignment.
Pass the stride and use it in chamelium_paint_xr24_pattern.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The xr24 pattern for chamelium testing appears mangled when checking it
on an actual display. This is because the horizontal and vertical
display sizes are inverted when used as width and height.
Put them back in order.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The connector and EDID blob retrieved when checking for analog bridges
need to be freed before returning from the associated function.
Fixes: f8d6afa67 ("tests/chamelium: Detect analog bridges and handle EDID accordingly")
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
|
|
Now that we have everything in place, we can add the support for the
subtests testing the output of planes setup with formats other than XR24.
Since YUV will be a bit trickier to handle, start with various common RGB
formats.
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
In order to introduce CRC subtests for DRM formats, we need to take an
intermediate step.
The current code will generate a pattern in XR24, and will try to compare
the CRC returned by the Chamelium for each frames.
This CRC is computed on an XR24 format as well, so it works. However, as
soon as we will start implementing other formats, if we just change the
format of the pattern, the raw content of the buffer, and therefore the
CRC's won't match anymore.
In order to address that, we will need an intermediate step, and we will
now still create the XR24 pattern, and compute its CRC, then convert it to
the format we want to test, and finally retrieve the CRC from the Chamelium
to compare it with the one from the XR24 pattern.
The current code is converted to the new prototype that will take the
fourcc of the format to test, even though we're still using XR24 everywhere
for now.
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The current pattern being used is the one generated through the
igt_create_color_pattern_fb.
However, in order to deal with multiple formats and the upsampling /
downsampling issues that might arise from converting back and forth between
formats, we will need to have a pattern with quite precise color values,
and without any shades or gradient of colors.
Let's create a function that will generate that pattern in the chamelium
code if we need to convert the framebuffer to a smaller depth, and use the
current pattern otherwise.
The easiest way to do that will be to only use values that would have the
same part on the common most significant bits (5, to deal with most
formats) and have the same bit repeated on the least significant bits that
are going to be dropped and / or padded when converting between formats.
Pixman will fill the lowest bits with 1, and our hardware (this has been
tested on a Raspberry Pi's VC4) is able to support that, so the easiest is
to just use all 1's for our components in order to still be able to compute
the CRCs.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
We have two use cases in our current sub-test suites: the tests that test
all the modes exposed by the driver, and the ones just picking up one.
Instead of having to deal with this two cases in the same function as it is
currently done, move the part that test a single mode into a separate
function, and just call it for every mode that we want to test if needs be.
This will result in a simpler function that will be easier to extend to
support formats.
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
If KMS is not supported on the device, drmModeGetResources() will return
NULL, often this is an indication that we should not attempt to run the
test. Although it would be preferred to use something like
igt_require_display() as the canonical check and assert that
drmModeGetResources() did not hit an error, it is not always practical
as the tests do not utilize the common igt_display abstraction.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Simple rule of thumb, if a kms_* test calls igt_display_init() in its
global fixture, skip the entire test if the driver has disabled KMS.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
Only try to set those values if the properties are supported.
This fixes the kms_chameium tests to run on vc4 again.
Reported-by: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Martin Peres <martin.peres@linux.intel.com>
|
