Re: [PATCH v1] xf86drm: Add drmHandleMatch func

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey Emil,

On 27.04.2018 15:48, Emil Velikov wrote:
On 27 April 2018 at 12:31, Robert Foss <robert.foss@xxxxxxxxxxxxx> wrote:
drmHandleMatch is intended to allow for userspace to filter out
devices that it does not want to open.

Opening specific devices using paths alone is not a reliable due to
probing order. This function intends to provide a mechanism
for filtering out devices that don't fit what you need using an
extensible set of filters.

drm_match_key_t is intended to be extended with whatever
filter that would come in handy down the line.

As a catch-all filter, the DRM_MATCH_FUNCTION was included
which allows the caller to filter based on an arbitrary function.

An function pointer filter could of course filter based on
anything. But for the sake of convenience a few other simple
filters have been included.

If the function pointer filter ends up being called with a
boilerplate fp by mutliple libdrm users, perhaps that funtion
could be moved into libdrm at a future date.

Signed-off-by: Robert Foss <robert.foss@xxxxxxxxxxxxx>
---

This patch implements a simple function for matching DRM device FDs
against the desired properties of a device that you are looking for.

The discussion that led to this series can be found here:
https://lists.freedesktop.org/archives/mesa-dev/2018-January/183878.html

The RFC can be found here:
https://www.spinics.net/lists/dri-devel/msg172398.html

Since the RFC I opted to rework the patch to be more extensible.
The previous implementation would have been problematic if the
drmVersion or drmDevice structs ever needed to be changed or
removed. Or indeed if more properties were to become interesting.

As it is now, it is basially implemented as per Daniel Stones suggestion in
the RFC discussion.

Changes since RFC:
  - Reworked proposal to be not be based on structs in order to be more
    flexible.
  - Now uses filters of different types.
  - Caller can supply any number of predefined and function pointer
    filter.

  xf86drm.h     | 24 ++++++++++++++++++++
  xf86drmMode.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  2 files changed, 94 insertions(+)

Instead of spending too much time thinking of a future-proof API, can
I suggest getting a handful of users first.
And only after that lifting it to a helper - If needed.

Here are some examples - anv [1] and xf86-video-amdgpu [2]. Note
latter is not merged yet.
Practically any implementation is as trivial as:

ret = drmGetDevices2(...)
for (i = 0; i < ret; i++) {
     compare_device_specifics(...)
}
drmFreeDevices(...)

What do you guys think?

I was hoping to have all probing functionality eventually implemented in libdrm, since it is duplicated in multiple codebases. Where this function&patch would be the first step.

But there seems to be some friction to this idea, so maybe it dropping this patch is the way to go forward.


Emil

[1] https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/vulkan/anv_device.c#n615
[2] https://lists.freedesktop.org/archives/amd-gfx/2018-April/020936.html
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux