[Mesa-dev] [PATCH] Don't use libudev for glx/dri3

[Daniel Vetter]

On Sat, Dec 14, 2013 at 3:33 AM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On 11/18/2013 12:58 PM, Emil Velikov wrote:
>> On 18/11/13 01:08, Keith Packard wrote:
>>> libudev doesn't have a stable API/ABI, and if the application wants to use one
>>> version, we'd best not load another into libGL.
>>>
>>> Signed-off-by: Keith Packard <keithp at keithp.com>
>>> ---
>>>
>> Hi Keith,
>>
>> Did you had the chance to look at src/gallium/targets/egl-static/egl.c?
>> It has a different implementation of drm_fd_get_pci_id, whenever udev is
>> not available.
>>
>> AFAICS it goes back to the kernel via the relevant ioctl to retrieve the
>> deviceid/chipid. Currently all but nouveau provide such information. I'm
>> thinking that this approach might be more reasonable for those concerned
>> with portability of the udev bits (think on *BSD).
>>
>> I'm not nitpicking, just thought you might find this interesting.
>>
>> Cheers,
>> Emil
>
> Possibly.  But looking at that code, it either:
> 1. Uses libudev
> 2. On Android only...strcmps the driver string to guess the family and
> then uses kernel ioctls...
> 3. Fails.
>
> The Android only nature makes me a bit wary.

The string mapping of the kernel driver name to a dri.so is what I
kinda expected to be used as the generic thing. Imo we don't ever need
the pci id in common code, drivers can load that through a private
ioctl from the kernel (like i915 and radeon do) or load some other
device id from somewhere (nouveau has that at the special reg offset 0
in the bar, also exposed through some ioctl iirc). That way we also
avoid hassles on SoCs which lack enumerable buses. And due to abi
guarantees those drm driver names will stay the same forever.

Also there's the entire drmOpenByBusid stuff which gives you at least
something reasonable for pci devices (not anywhere else though), so we
could do that dance in reverse if we want to have a pci id based
lookup.

Anyway I've never read through the loader code, just figured it won't
hurt if I drop my uninformed opinion ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch