Make modetest available to vendors on Android. libdrm_util and
libdrm_test_headers is also made available to vendors since these are
depenencies of modetest. This results in the module target
modetest.vendor being availble to vendor modules.
Signed-off-by: Rob Barnes <robbarnes at google.com>
Fixes the following building error:
external/libdrm/xf86drm.c:158:10: fatal error: 'generated_static_table_fourcc.h' file not found
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Change-Id: I1b0cac498ed63ebec6e8c03629bbf4a1b6a9618d
Reviewed-by: Mauro Rossi <issor.oruam@gmail.com>
Currently modetest supports only the YUV420 and YVU420 planar YCbCr
plane formats (aka YV12 and YU12). Extend the code to add support for
YUV422 / YVU422 and YUV444 / YVU444 plane formats.
Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
In preparation to adding more planar YUV formats, introduce X, Y
subsampling ratios and use them to calculate plane offsets and buffer
size.
Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Whenever `util_open()` is called to open a device for the first matching
module, it will skip devices for the `nvidia_drm` kernel module which
is not in the list. We could add this module for now, but keeping this
list of DRM modules up to date is cumbersome.
At the same time walking a list of modules and calling `drmOpen()` for
each of them is incredibly expensive (when the user doesn't explicitly
specify one with `-M`), as each each call opens every DRM node just
to see if they are associated to the requested module. And for no
good reason: all we want is the first `DRM_NODE_PRIMARY` (which is what
`drmOpen()` also returns) to use by default.
For example on the `"msm"` driver, which used to be the 9th in the
modules list, all nodes are opened for the 9th time before e.g.
`modetest` returns a useful result, which takes ages unless the user
painstakingly provides the module for the currently known device on
the cmdline.
This is very simply solved by calling `drmGetDevices(2)()`, which
iterates through all DRM nodes only once and allows us to immediately
find + `open()` the first device that has a PRIMARY node. A random
search for the error shows that this was also attempted in (a fork of?)
kmscube:
https://git.ti.com/cgit/glsdk/kmscube/commit/?id=456cabc661caac5c60729751d45efd668faa8e97
Finally we add a `drmIsKMS()` check to make sure we only include primary
nodes that actually support rendering, and also print the values from
`drmGetVersion()` on success to make it easier to identify the device.
In the future we could extrapolate this feature by letting query
commands like `modetest -c` list connectors for every device/module, not
just the first PRIMARY node that we found.
Bionic libc ships with `ioctl` that has two signatures, one with an
unsigned `request` parameter and one with a signed request parameter.
This leads to compilation failing due to `__typeof__(ioctl)` being used
by DRM which fails to resolve which overload to use, this has been fixed
by defining `BIONIC_IOCTL_NO_SIGNEDNESS_OVERLOAD` on Android.
Signed-off-by: Mark Collins <mark@igalia.com>
There is an excellent writeup explaining this requirement here:
https://gitlab.freedesktop.org/wayland/wayland/-/issues/175
In short, for mixed environments such as the Steam Runtime and other
container-like environments, choosing which libdrm to link into the
client's address space is a hard problem. If the runtime has a newer
libdrm than the host, then it should be preferred, because the client
may be using newly-added symbols. But if the host has a newer libdrm,
then that should be used, because drivers may be depending on those.
Bumping the DSO minor version is transparent to all users because apps
only link against the major version, e.g. DT_NEEDED libdrm.so.2; the
fact that libdrm.so.2 is a link to libdrm.so.2.122.0 is a detail known
only to the loader, but it does let a smart runtime make better
decisions.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When the GPU feature is turned on in crosvm, these modules are added as
dependencies. Since crosvm is included in the virt APEX, add the APEX to
the apex_available properties of the modules to make them available in
the APEX.
To do so, crosvm and its dependencies have the apex_available property
set to "//apex_available:platform", "com.android.virt" to explicitly
acknowledge the joining.
drm_property_type_is function in xf86drmMode.h file can cause compiler
error because it performs unsigned to signed conversion. Some Android.mk
modules have been avoiding this by adding "-isystem external/libdrm"
flag, because warnings from system headers are suppressed.
This changes exported_include_dirs to export_system_include_dirs
to workaround the potential error with the same manner above.
... to make drm format header visible for host wayland server.
Adds -Wno-implicit-function-declaration for vasprintf() on
xf86drm.c:2965.
Adds -Wno-int-conversion for drm_mmap() on libdrm_macros.h:60.
Also, drive-by alphabetize cflags.
See build/soong/README.md for more information about Soong.
Removes BOARD_GPU_DRIVERS, which wasn't affecting anything, since none
of the HAVE_* macros are defined. Even if they were, we'd prefer to
compile all of them so that a single library can support multiple
boards.
Some platforms (eg. SunOS) explicitly need extra symbols in order to define
those functions. There're many files needing the __EXTENSIONS__ symbol,
so doing this on a global scale.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Synchronize drm_fourcc.h and drm_mode.h to drm-next.
Generated using make headers_install.
Generated from drm-next branch commit 541b1b0a8fc235bca355921eb7f3f59a8efa3e9a
Signed-off-by: Simon Ser <contact@emersion.fr>
The <linux/fb.h> header only exists on Linux, but isn't used anymore,
so drop it entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several drivers still including <linux/stddef.h>, but not using anything
from it, thus breaking build on non-Linux platforms (eg. FreeBSD).
Since not needed at all, just stop including it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
../xf86drm.c:4622:9: error: use of undeclared identifier 'written'; did you mean 'write'?
if (written + 1 > max_node_length)
^~~~~~~
write
../xf86drm.c:4624:21: error: use of undeclared identifier 'sbuf'; did you mean 'sbrk'?
if (stat(node, &sbuf))
^~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
fix commit cc3c80c6("tests/amdgpu: refactor dispatch/draw test")
../../SOURCES/drm/tests/amdgpu/shader_code.h:113:2: error: initializer
element is not constant
ps_##_ps##_shader_patchinfo_code_size_gfx##_n, \
^
Signed-off-by: Flora Cui <flora.cui@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
../../drm/tests/amdgpu/shader_test_util.c: In function
‘amdgpu_dispatch_init’:
../../drm/tests/amdgpu/shader_test_util.c:296:9: warning: enumeration
value ‘AMDGPU_TEST_GFX_MAX’ not handled in switch [-Wswitch]
296 | switch (test_priv->info->version) {
| ^~~~~~
Signed-off-by: Flora Cui <flora.cui@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The issue was found by a static analysis tool:
Error: LOCK_EVASION (CWE-543):
libdrm-2.4.115/amdgpu/amdgpu_cs.c:596: thread1_checks_field:
Thread1 uses the value read from field "context" in the
condition "sem->signal_fence.context". It sees that the
condition is false. Control is switched to Thread2.
libdrm-2.4.115/amdgpu/amdgpu_cs.c:596: thread2_checks_field:
Thread2 uses the value read from field "context" in the
condition "sem->signal_fence.context". It sees that the
condition is false.
libdrm-2.4.115/amdgpu/amdgpu_cs.c:598: thread2_acquires_lock:
Thread2 acquires lock "amdgpu_context.sequence_mutex".
libdrm-2.4.115/amdgpu/amdgpu_cs.c:599: thread2_modifies_field:
Thread2 sets "context" to a new value. Note that this write can
be reordered at runtime to occur before instructions that do
not access this field within this locked region. After Thread2
leaves the critical section, control is switched back to
Thread1.
libdrm-2.4.115/amdgpu/amdgpu_cs.c:598: thread1_acquires_lock:
Thread1 acquires lock "amdgpu_context.sequence_mutex".
libdrm-2.4.115/amdgpu/amdgpu_cs.c:599: thread1_overwrites_value_in_field:
Thread1 sets "context" to a new value. Now the two threads have
an inconsistent view of "context" and updates to fields of
"context" or fields correlated with "context" may be lost.
libdrm-2.4.115/amdgpu/amdgpu_cs.c:596: use_same_locks_for_read_and_modify:
Guard the modification of "context" and the read used to decide
whether to modify "context" with the same set of locks.
# 597| return -EINVAL;
# 598| pthread_mutex_lock(&ctx->sequence_mutex);
# 599|-> sem->signal_fence.context = ctx;
# 600| sem->signal_fence.ip_type = ip_type;
# 601| sem->signal_fence.ip_instance = ip_instance;
Check `sem->signal_fence.context` in the locked region to avoid a race
condition.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: José Expósito <jexposit@redhat.com>
I always need to double-check what the return value means when
using that function (since it's not a bool).
Signed-off-by: Simon Ser <contact@emersion.fr>
str.format used to allow any type as an argument, which often resulted
in using an internal string representation. This is considered broken
behavior, and is deprecated since Meson 1.3.0.
Signed-off-by: Joaquim Monteiro <joaquim.monteiro@protonmail.com>
The devices weren't removed from dev_list.
Instead of just fixing the issue by adding:
if (*node) *node = dev->next;
after the while loop, use this opportunity to use a clearer
control flow.
Fixes: 7275ef8e ("amdgpu: add amdgpu_device_initialize2")
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Tested-by: Mike Lothian <mike@fireburn.co.uk>
