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

[Daniel Vetter]

On Mon, Dec 16, 2013 at 11:19:56AM -0800, Eric Anholt wrote:
> Daniel Vetter <daniel at ffwll.ch> writes:
> 
> > 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
> 
> [snip]
> 
> There is more than one userspace driver per kernel driver.  (i915 vs
> i965, for example)

Oh right ... so I guess we'd need a shim which figures out the details.
Which is kinda what that hack in the gallium egl loader does. I guess I
better hide in the kernel again ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch