From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenneth Graunke Subject: Re: [PATCH] Don't use libudev for glx/dri3 Date: Fri, 13 Dec 2013 18:33:09 -0800 Message-ID: <52ABC365.1010001@whitecape.org> References: <1384736112-6023-1-git-send-email-keithp@keithp.com> <1384736916-25285-1-git-send-email-keithp@keithp.com> <528A7F6B.3020905@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <528A7F6B.3020905@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mesa-dev-bounces@lists.freedesktop.org Errors-To: mesa-dev-bounces@lists.freedesktop.org To: Emil Velikov , Keith Packard , mesa-dev@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org 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 >> --- >> > 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.