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

[Zhou, Jammy]

> There have been plenty of reports opened wrt libudev/libgcc_s/libstdc++ on their trackers and seemingly limited interest to fix things.

Yes, there are a bunch of issues reported for this already. But it looks like Valve has no plan to fix these issues. For example,
https://github.com/ValveSoftware/steam-runtime/issues/13

IMHO, we can probably use sysfs first, and when the issue is solved by Valve, we can switch to the udev solution later.

Regards,
Jammy

-----Original Message-----
From: Emil Velikov [mailto:emil.l.velikov at gmail.com] 
Sent: Friday, August 14, 2015 5:08 PM
To: Kai Wasserbäch
Cc: Zhou, Jammy; Daniel Vetter; ML dri-devel
Subject: Re: [PATCH 1/5] drm: add interface to get drm devices on the system v2

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.