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

[Emil Velikov]

On 14 August 2015 at 09:26, Kai Wasserbäch <kai at dev.carbon-project.org> wrote:
> Emil Velikov wrote on 14.08.2015 10:17:
>> 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.
>
> 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,
There is a saying (roughly translated to) "The wiser man always steps
back". Or we could/should be like Linus - "F* you $company"

> 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).
>
There have been plenty of reports opened wrt
libudev/libgcc_s/libstdc++ on their trackers and seemingly limited
interest to fix things.

This is a catch 20/20 afaics. "FOSS drivers do not work thus they are
s**t" is how a sizeable hunk of people think. They rarely consider
what the actual issue might be, because "I installed the nvidia/amd
proprietary drivers and things work now".

> Anyway, this was just my two cents and you can obviously decide in any way you
> deem to be the best.
>
Personally, I'd love if there was no "options" and we can just use
libfoo. Who knows Valve devs might get a wake up call and fix the
problem ?


-Emil
P.S. Fun fact: Valve's annual "TI" Dota2 tournament managed to
accumulate some 66 million USD gross income, over 100 days.