dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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