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>
pthread-stubs >= 0.4 simply passes -pthread which is similar to what
dependency('threads') returns. And make it a private dependency
for subprojects even on Linux.
Reviewed-by: Emmanuel Vadot <manu@FreeBSD.org>
These new functions can be used to allocate and free syncpoints, as well
as wait for a syncpoint threshold to be reached. Jobs can also be waited
on if a syncpoint was attached to them.
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
These new functions can be used to create a job on a given channel, add
commands to the job using its push buffer and submit the job.
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
These new functions can be used to open a channel to a given engine, map
and unmap buffer objects to that channel, and close the channel.
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This makes sure that the proper dependencies are created and that the
file is distributed.
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This produces no differences in the generated output. I've had to
manually add `requires : 'libdrm'` to libdrm_intel, otherwise libdrm
ends up in `Requires.private` instead of `Requires`.
Signed-off-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
This allows meson to check if the compiler supports gnu style symbol
visibility, and apply the appropriate flags as necessary, rather than us
adding them by hand
Signed-off-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
This allows consumers of libdrm as a subproject to use the simpler
`dependency('libdrm', fallback : 'libdrm')` syntax, as the libdrm build
files already tell meson that they override a dependency called
"libdrm".
Signed-off-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
This allows users to select the library type (static or shared)
using the Meson -Ddefault_library built-in option.
Issue: https://gitlab.freedesktop.org/mesa/drm/-/issues/45
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Fang Tan <tanfang@uniontech.com>
Now that symbols that should be exported are annotated accordingly, make
all the rest hidden by default.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Helpful if your nm executable has a prefix based on the
architecture, for example.
Signed-off-by: Heiko Becker <heirecka@exherbo.org>
Cc: Timo Gurr <timo.gurr@gmail.com>
[Eric: v2: rebase and add Meson support]
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This patch adds a complete meson build system, including tests and
install. It has the necessary hooks to allow it be used as a subproject
for other meson based builds such as mesa.
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-and-tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
