> 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.veli...@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.
