On Mon, Dec 16, 2013 at 11:19:56AM -0800, Eric Anholt wrote: > Daniel Vetter <daniel@xxxxxxxx> writes: > > > On Sat, Dec 14, 2013 at 3:33 AM, Kenneth Graunke <kenneth@xxxxxxxxxxxxx> 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@xxxxxxxxxx> > >>>> --- > >>>> > >>> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
