From: Keith Packard <keithp@keithp.com>
To: mesa-dev@lists.freedesktop.org
Cc: emil.l.velikov@gmail.com, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] Don't use libudev for glx/dri3
Date: Mon, 18 Nov 2013 22:46:55 -0800 [thread overview]
Message-ID: <868uwk3n34.fsf@miki.keithp.com> (raw)
In-Reply-To: <528A7F6B.3020905@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1351 bytes --]
Emil Velikov <emil.l.velikov@gmail.com> writes:
> 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@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.
Yeah, it's ugly in a different way from the udev technique...
> 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'd encourage some kind of standard IOCTL from DRM that returns the
PCI-ID of the underlying device, rather than relying on the level of
kludge present in either the udev (or my fake udev) method or the
non-udev path in the egl code...
> I'm not nitpicking, just thought you might find this interesting.
Definitely interesting; it's almost what we want -- the kernel knows the
information, there just isn't a clean way of getting it (and no way at
all for some devices).
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]
[-- Attachment #2: Type: text/plain, Size: 156 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
next prev parent reply other threads:[~2013-11-19 6:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-18 0:55 [PATCH] Don't use libudev for glx/dri3 Keith Packard
2013-11-18 1:08 ` Keith Packard
2013-11-18 1:31 ` Emil Velikov
2013-11-18 2:43 ` Keith Packard
2013-11-18 4:08 ` Kenneth Graunke
2013-11-18 6:03 ` Keith Packard
2013-11-18 21:59 ` Ian Romanick
2013-11-18 20:58 ` Emil Velikov
2013-11-19 6:46 ` Keith Packard [this message]
2013-12-14 2:33 ` Kenneth Graunke
2013-12-14 10:37 ` [Mesa-dev] " Daniel Vetter
2013-12-16 19:19 ` Eric Anholt
2013-12-16 19:57 ` [Mesa-dev] " Daniel Vetter
2013-11-19 18:41 ` Eric Anholt
2013-11-19 19:41 ` Keith Packard
2013-11-19 20:19 ` [Mesa-dev] " Eric Anholt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=868uwk3n34.fsf@miki.keithp.com \
--to=keithp@keithp.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
--cc=mesa-dev@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox