This adds a function to get a drmDevicePtr from a dev_t identifier
of a device. This is useful for Wayland that uses these to identify
devices over the protocol.
This is done by taking the implementation of drmGetDevice2, and removing
the call to fstat to find the dev_t.
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Add support for parsing IN_FORMATS property blobs. Providing libdrm
with this functionality helps to standardise how user-space reads
kernel blobs and decreases duplication on the client side.
drmModeFormatModifierBlobIterNext() allows the caller to view
formats and associated modifiers given a valid property blob.
An example is available inside the libdrm unit test, modetest.c.
Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
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>
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 a device has a primary node, it doesn't necessarily mean it's
suitable for KMS usage. For instance, render-only drivers also
expose primary nodes.
The check is extracted from Weston [1].
The motivation for this new function is two-fold:
- Avoid an unnecessary GETRESOURCES call. To check whether a
primary node is suitable for KMS, we don't actually need to
retrieve the object IDs we just need to check the counts.
- Avoid confusion in user-space and make sure user-space implements
the check properly. For instance, wlroots doesn't [2]: it uses
drmGetVersion which succeeds with render-only drivers.
[1]: https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/drm.c#L2689
[2]: a290d7a78d/backend/session/session.c (L268)
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Add a wrapper around the getfb2 ioctl, which returns extended
framebuffer information mirroring addfb2, including multiple planes and
modifiers.
Changes since v7:
- add new symbols to core-symbol.txt (Eric Engestrom)
Changes since v5:
- style change
Changes since v4:
- Set fb_id at init instead of memclear() and set (Eric Engestrom)
Changes since v3:
- remove unnecessary null check in drmModeFreeFB2 (Daniel Stone)
Changes since v2:
- getfb2 ioctl has been merged upstream
- sync include/drm/drm.h in a seperate patch
Changes since v1:
- functions should be drm_public
- modifier should be 64 bits
- update ioctl number
Signed-off-by: Juston Li <juston.li@intel.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
All the libdrm_* submodules have symbols checks, no reason to keep core
libdrm wild.
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>