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

From: "Kai Wasserbäch" <kai@dev.carbon-project.org>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 1/5] drm: add interface to get drm devices on the system v2
Date: Fri, 14 Aug 2015 10:26:30 +0200	[thread overview]
Message-ID: <55CDA636.1080407@dev.carbon-project.org> (raw)
In-Reply-To: <CACvgo51TzqoD_LuYXnMc-aupCSpvOKAi1g9tHOfc=n2KiOgctg@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 2665 bytes --]

Emil Velikov wrote on 14.08.2015 10:17:
> On 14 August 2015 at 08:59, Kai Wasserbäch <kai@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.

Well, I'd rather remove stuff from Steam's runtime than burden you and other
developers with maintaing code that is unnecessrily ugly. (Though that's
obviously just my opinion.)

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

As long as you allow this behaviour by working around it, I don't see Valve/game
developers "invest" in a real solution (because it works now). Businesses
usually only move from a position, when there's outside pressure and a clear
advantage to do so (here: no bug reports about crashing games).

Anyway, this was just my two cents and you can obviously decide in any way you
deem to be the best.

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 630 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel