We have wrappers for PRIME_HANDLE_TO_FD and PRIME_FD_TO_HANDLE,
but not for GEM_CLOSE. Add it so that callers don't need to
manually call drmIoctl.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
`sysfs_uevent_get()` returns a `strndup()`ed string, which must be `free()`d.
Fixes: bf63f8acdc ("libdrm: Handle usb_interface devices for usb parsing")
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
As format modifiers can be encoded in quite complex forms, the static
table previously added is not sufficient to retrieve, extract and decode
the token formats to a human-readable string. This patch introduces a
vendor specific callback which could be used to perform an additional
search to match up with vendor encoding scheme, which, will be used
first, before resorting to searching the static table.
With it, add support for decoding the ARM format modifiers.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Introduces two new methods to retrieve a human readable representation of a
format modifier:
drmGetFormatModifierName() - returns a format modifier as a string,
from a token modifier
drmGetFormatModifierVendor() - returns the vendor as a string, from a
token modifier
and the fourcc_mod_get_vendor macro that returns the vendor.
New format modifiers added in drm_fourcc.h uapi kernel header should be
sync'ed up with libdrm and should include a human readable
representation for that format modifier, in order to display it
correctly as a string.
That happens with the help of a python script that reads up drm_fourcc
header file and outputs a static table comprised of token modifiers
alongside a vendor table (Suggested-by Simon Ser <contact@emersion.fr>).
The reason for doing it in libdrm is to have a unified place instead of each
user of libdrm having a way to keep track of the format modifiers.
With this patch, modetest has also been modified to make use of it.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
If info.count is large, drmMalloc() / alloca() may fail, and the
resulting null pointer is not null checked before dereference.
Issue: https://gitlab.freedesktop.org/mesa/drm/-/issues/62
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Alistair Delva <adelva@google.com>
Do as the documentation says - when devices non NULL, cap the reported
devices to max_devices. Otherwise we risk out-of-bound access
for users of the API.
v2:
- Fix this w/o breaking the API
v3:
- Drop local variables, flip inverted conditional (Simon)
Issue: https://gitlab.freedesktop.org/mesa/drm/-/issues/56
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
This reverts commit 8cb12a2528.
The commit fixed the OOB, yet it broke drmDevices2(0, NULL, 0) - aka we
did not return the total devices list.
Reviewed-by: Simon Ser <contact@emersion.fr>
Do as the documentation says - cap the number of reported devices to the
requested amount - aka max_devices. Otherwise we risk out-of-bound access
for users of the API.
Issue: https://gitlab.freedesktop.org/mesa/drm/-/issues/56
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
log() is affected by FP control word and can provide inaccurate result.
Fixes Killer Instinct under Wine not being able to find AMD vulkan
device.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Paul Gofman <pgofman@codeweavers.com>
./xf86drm.c: In function 'drmNodeIsDRM':
../xf86drm.c:2825:7: error: "__FreeBSD__" is not defined [-Werror=undef]
#elif __FreeBSD__
^
../xf86drm.c: In function 'drmGetMinorNameForFD':
../xf86drm.c:2938:7: error: "__FreeBSD__" is not defined [-Werror=undef]
#elif __FreeBSD__
^
../xf86drm.c: In function 'drmParsePciBusInfo':
../xf86drm.c:3258:7: error: "__FreeBSD__" is not defined [-Werror=undef]
#elif __FreeBSD__
^
../xf86drm.c: In function 'drmParsePciDeviceInfo':
../xf86drm.c:3427:7: error: "__FreeBSD__" is not defined [-Werror=undef]
#elif __FreeBSD__
^
../xf86drm.c: In function 'drmGetDeviceNameFromFd2':
../xf86drm.c:4305:7: error: "__FreeBSD__" is not defined [-Werror=undef]
#elif __FreeBSD__
^
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Since we now always returns the /dev/dri/ node for
drmGet<nodetype>DeviceNameFromFd, be consistant with the names returned
in drmGetDeviceNameFromFd.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Emmanuel Vadot <manu@FreeBSD.org>
Fix the FreeBSD variant by getting the node type represented by fd to deduce
the target minor name.
We then return the full /dev/dri/<minorname><id> version.
Fix: #41
Fixes: 6818a50b12
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Emmanuel Vadot <manu@FreeBSD.org>
Currently the code expects that the device found at
/sys/char/$maj:$min/device for USB devices is a "usb_device". However,
at least for some devices, such as for the udl driver, they are instead
a "usb_interface".
A usb_interface is a child of the usb_device we're interested in, so we
walk up one in the /sys path to get there.
For example, with a USB device I have, trimmed to show the relevant
information:
```
$ udevadm info /dev/dri/card1
P: /devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-4/1-4:1.0/drm/card1
E: DEVTYPE=drm_minor
$ udevadm info /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-4/1-4:1.0
E: DEVTYPE=usb_interface
E: DRIVER=udl
$ udevadm info /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-4
E: DEVTYPE=usb_device
E: DRIVER=usb
E: BUSNUM=001
E: DEVNUM=009
```
Signed-off-by: Scott Anderson <scott@anderso.nz>
This fixes bug in drmParseSubsystemType() that cases situation when
subsequent call to readlink() from get_subsystem_type() will result in
EACCESS.
Signed-off-by: Mikhail Golubev <mikhail.golubev@opensynergy.com>
The FreeBSD kernel expose a pseudo-device /dev/pci to obtain information
about present PCI device.
Uee the PCIOCGETCONF ioctl on this device to look up the desired device
information.
Signed-off-by: Emmanuel Vadot <manu@FreeBSD.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The FreeBSD drm driver expose a sysctl hw.dri.%d.busid which contain
the busid.
Use this sysctl to parse the busid information based on the major/minor
that allow us to implement FreeBSD support for drmParsePciBusInfo.
Signed-off-by: Emmanuel Vadot <manu@FreeBSD.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The FreeBSD variant of drmGetDeviceNameFromFd can already handle
the different node type so just call it.
Signed-off-by: Emmanuel Vadot <manu@FreeBSD.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
FreeBSD have some support for DRM on !PCI device but no code is currently
upstream. Default to PCI for now.
Signed-off-by: Emmanuel Vadot <manu@FreeBSD.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Use the FreeBSD variant function to obtain the minor name and the
device node.
Return the correct path based on where the node is (drm/ versus dri/).
Signed-off-by: Emmanuel Vadot <manu@FreeBSD.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Get the major/minor via fstat and after checking that this is a drm node
construct the full device node name using devname.
Note that we should be able to use fdevname to avoid calling fstat + devname
but for some reason it doesn't work on drm node (probably due to how the device
node are created in the linux compat code for drm on FreeBSD).
Signed-off-by: Emmanuel Vadot <manu@FreeBSD.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Resolve the minor type based on the device node path.
The minor type is either in /dev/drm/X where X is the type or
in a Linux-compatible device node in /dev/dri/
This means we need the major number on FreeBSD so add it to the function
arguments.
Signed-off-by: Emmanuel Vadot <manu@FreeBSD.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
FreeBSD devfs only provides on the fly generated major/minor.
The major number is irrelevant for FreeBSD so remove the special case.
Signed-off-by: Emmanuel Vadot <manu@FreeBSD.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
FreeBSD devfs have on the gly generated major minor so we cannot use them
to test if the device is a drm node.
Instead get the devfs node name and test if it is in a subdirectory "drm/"
or "dri/".
Historycally DRM device on FreeBSD are created in /dev/drm/ and link are
present in /dev/dri/ for compatibility reason.
Signed-off-by: Emmanuel Vadot <manu@FreeBSD.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Currently the code assumes that a virtio based device is always located
on the PCI bus.
Modify the parser to make it check the device's parent directory to
determine on which bus it is located.
Output for virtio-pci is the PCI bus.
Output for virtio-mmio is the Platform bus.
Signed-off-by: Vasyl Vavrychuk <vasyl.vavrychuk@opensynergy.com>
Signed-off-by: Mikhail Golubev <Mikhail.Golubev@opensynergy.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Move the code, which used to get the device subsystem type from a device
path in sysfs, to a separate function to be reusable.
Signed-off-by: Vasyl Vavrychuk <vasyl.vavrychuk@opensynergy.com>
Signed-off-by: Mikhail Golubev <Mikhail.Golubev@opensynergy.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
v2: nit-picks fix
Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Christian König <Christian.Koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
For the xf86drm.[ch] part : Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Adapted from a local patch carried by DragonFlyBSD:
bc056f88f7/graphics/libdrm/files/patch-xf86drm.h
Patch is sadly uncredited (a bot authored the commit), so I can't credit
the author here either.
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
drm render nodes have the same major as drm primary devices but offset
the minor by a base of 128.
I expected the name of the device to have numbering starting at 0 when
these non-linux codepaths were added (before OpenBSD had render nodes).
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Acked-by: Eric Engestrom <eric.engestrom@intel.com>
Unlike Linux the OpenBSD primary "drm" device name is substring of the
"drmR" render node device name and strncmp() tests resulted in render
nodes being flagged as primary nodes.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Acked-by: Eric Engestrom <eric.engestrom@intel.com>
Avoid additional drm device open and close.
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Alistair Strachan <astrachan@google.com>
Cc: Marissa Wall <marissaw@google.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
This reverts commit 56c21f877b.
There were issues pointed out during review that were not addressed.
Would love to have this re-land, once those are addressed.
Saw a couple of typos fixes in the patch DragonFlyBSD carries [1], so
I ran codespell (a spell checker for code) on the whole repo.
[1] https://github.com/DragonFlyBSD/DPorts/blob/master/graphics/libdrm/files/patch-xf86drm.c
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This fixes a bug, which was introduced with commit ee798b98
"xf85drm: de-duplicate drmParse{Platform.Host1x}{Bus,Device}Info".
where accessing *compatible[i] with i>0 results in a segfault.
Signed-off-by: Andreas Baierl <ichgeh@imkreisrum.de>
Fixes: ee798b9847 "xf85drm: de-duplicate drmParse{Platform.Host1x}{Bus,Device}Info"
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
[Eric: add the same fix to the free() below]
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
For multiple GPUs which has the same BDF, but has different domain ID,
the drmOpenByBusid will return the wrong fd when startx.
The reproduce sequence as below:
1. Call drmOpenByBusid to open Card0, then will return the right fd0, and the
fd0 is master privilege;
2. Call drmOpenByBusid to open Card1. In function drmOpenByBusid, it will
open Card0 first, this time, the fd1 for opening Card0 is not master
privilege, and will call drmSetInterfaceVersion to identify the
domain ID feature, as the fd1 is not master privilege, then drmSetInterfaceVersion
will fail, and then won't compare domain ID, then return the wrong fd for Card1.
Solution:
First loop search the best match fd about drm 1.4.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Xserver has struct members named `bool`, which means the last commit
breaks its build with errors like this:
error: two or more data types in declaration specifiers
Bool bool;
^
Fix this by making it return a 0/1 integer, with the same semantic as
the boolean it was before.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109587
Fixes: 17dfe3ac93 "xf86drm: Add drmIsMaster()"
Cc: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
We can't use drmSetMaster to query whether or not a drm fd is master
because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd.
Pick DRM_IOCTL_MODE_ATTACHMODE as a long-deprecated ioctl that is
DRM_MASTER but not DRM_ROOT_ONLY as the probe by which we can detect
whether or not the fd is master.
This is useful for code that might get master by open()ing the drm device
while no other master exists, but can't call drmSetMaster itself because
it's not running as root or is in a container, where container-root isn't
real-root.
v2: Use the AUTH_MAGIC request rather than MODE_ATTACHMODE, as it's more
clearly related to master status.
v3: [Emil] Don't expose internals, check for -EACCES.
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v2)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The functions are virtually identical, fold them up.
v2: foo -> tmp_name (Eric)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Some devices can lack OF data or it may not be available in the uevent
file. Fallback to the MODALIAS data in those cases.
We strip any leading "MODALIAS=.*:" thus the resulting information is
compatible with existing code in Mesa.
v2: foo -> tmp_name
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Tested-by: Lucas Stach <l.stach@pengutronix.de> (v1)
It is a cleaner and less fragile way to get PCI IDs than the one
currently used by local DPorts patches.
Signed-off-by: François Tigeot <ftigeot@wolfpond.org>
Dennis Tsiang
Simon Ser
Eric Engestrom
Marius Vlad
Alistair Delva
Emil Velikov
Paul Gofman
Heiko Thiery
Emmanuel Vadot
Scott Anderson
Mikhail Golubev
Vasyl Vavrychuk
Chunming Zhou
Eric Engestrom
Jonathan Gray
Prabhanjan Kandula
Andreas Baierl
Emily Deng
Christopher James Halse Rogers
Emil Velikov
François Tigeot