[PATCH 1/5] drm: add interface to get drm devices on the system v2

Emil Velikov emil.l.velikov at gmail.com
Fri Aug 14 01:17:48 PDT 2015


On 14 August 2015 at 08:59, Kai Wasserbäch <kai at dev.carbon-project.org> wrote:
> Zhou, Jammy wrote on 14.08.2015 07:59:
>> We tried several different ways already for the enumeration interface (libpciaccess, libudev, etc). But we ran into some problems with these options for example when run Steam games which ships 32bit libraries (including libudev) in the steam runtime, so finally we decided to use sysfs directly to avoid introducing some additional dependencies into libdrm.
>
> The reason sounds wrong. There was a similar discussion over at Mesa. I think
> you (as in hardware/driver vendors like AMD/Intel/Nvidia) need to push Valve (or
> the game devs through Valve or directly) to fix their setup. Steam runtime is
> fine and all, but please only pre-load it, if needed (ie. library foo is missing
> on the system and can't be installed through the package manager). IIRC the
> VMWare guys said in the Mesa discussion, they have a script in place for their
> virtualisation products, that checks whether a library needs to be loaded from
> their "baseline directory" or from the system.
>
> Working around a bug/design flaw in Steam's Linux version doesn't sound like a
> supportable solution in the long run. As long as you let them get away with
> that, you will face this problem over and over with different libraries. (For me
> it's usually libstdc++ (needed by LLVM), libncurses and a few X(CB) libraries I
> need to remove from Steam, before anything works. Though I do have script for
> that, that I can run after every upgrade, this is not a solution for everyone.)
>
Helping and applying pressure to resolve the issue is the way to go.
But until that is resolved it's great to have a solution that does not
lead to a crash. It feels rude towards you and other users to
deliberately use the problematic combo and expect from you to remove
libfoo.so.

When things get sorted out, we can easily replace this (a tad ugly
implementation) with libudev.

-Emil


More information about the dri-devel mailing list