On Friday, July 25, 2014 04:02:48 AM Emil Velikov wrote: > On 25/07/14 03:14, Matt Turner wrote: > > On Thu, Jul 24, 2014 at 5:17 PM, Emil Velikov <emil.l.veli...@gmail.com> > > wrote: > >> On 24/07/14 22:08, Dylan Baker wrote: > >>> On Thursday, July 24, 2014 09:32:38 PM Emil Velikov wrote: > >>>> On 22/07/14 19:43, Dylan Baker wrote: > >>>>> GBM_DRIVERS_PATH is not documented, and only used to set the location of > >>>>> gbm drivers, while LIBGL_DRIVERS_PATH is used for everything else, and > >>>>> is documented. > >>>>> > >>>>> Generally this split leads to confusion as to why gbm doesn't work. > >>>>> > >>>>> This patch makes LIBGL_DRIVERS_PATH the main variable, but uses > >>>>> GBM_DRIVERS_PATH as a fallback if LIBGL_DRIVERS_PATH is NULL. > >>>> > >>>> Dylan if we're going the LIBGL road, can we please use the GBM variable > >>>> first and then fallback to the LIBGL one ? This way things won't break > >>>> for > >>>> people using the former. Meanwhile I'm writing docs/gbm.html with some > >>>> rough description what gbm is and all the env vars used :-) > >>>> > >>> > >>> Is there a usecase for having a seperate GBM_DRIVERS_PATH? > >> Guess we'll know that when people come complaining that it broke their > >> setup. > >> It will be piglit's "OMG this broke my setup - revert revert. But this has > >> been on the ML for xx days", story all over again. > > > > Isn't this a vacuous problem? The drivers GBM opens are the same > > drivers specified by LIBGL_DRIVERS_PATH, and there's never been any > > difference or way to install "GBM drivers" elsewhere. I.e., no one > > ever has specified something different for GBM_DRIVERS_PATH and > > LIBGL_DRIVERS_PATH intentionally. > > > Still don't see what the problem is: you wanted LIBGL to control do world - > sure, go ahead. All I asked for is to not rub the middle finger in someone's > face just because they never came to personally tell you that's the way they > do things. Essentially I'm trying to find a compromise that works for everyone > yet you come with the "no one" and "ever" statements, which are a bit silly > IMHO, especially in the context of an open-source project. > > I'm quite "enjoying" this bike-shedding. People just refuse that others may > have with different work flow than theirs. Well... I'm off this topic enjoy > your "world domination" plan :P > > -Emil
Emil, You seem really upset for some reason, and I don't understand why. Nobody has evil plans for "world domination" here. Dylan, Eric, Kristian, Jordan, Ben, and I have all concretely wasted time on a number of occasions due to GBM not respecting the standard, documented LIBGL_DRIVERS_PATH variable. When Dylan proposed his patch, we expressed our opinion that it would save us time debugging unnecessary problems. So far, I haven't heard that his patch would make things concretely worse for you personally. What I've heard is that you dislike the change in behavior, because /someone/ (other than you) may have /some/ use case which benefits from GBM having an additional separate driver search path. The other people in the discussion have asked for a single Mesa developer to say "This benefits me in a concrete way." Which to me, seems like a very reasonable request. But so far, no one has stepped forward to say that. Piglit is a little different. Although there are a wide variety of use cases, people are always able to quickly explain their workflow and why something is concretely useful to them. But, all the people affected aren't present in the discussion, because we're all too busy to read the Piglit list consistently. In contrast, people actually read mesa-dev - especially single patch threads with obvious subject lines. There are very few users of GBM, and I think virtually all of them are here. I think it's reasonable to assume people are paying attention, and the only reason we haven't heard objections from others is that they simply don't care. For what it's worth, I'm fine with your suggestion of reading GBM_DRIVERS_PATH first, then LIBGL_DRIVERS_PATH. It's the sensible way to do things - it adds the new useful behavior the 6 of us want, while preserving the existing behavior more closely. But it also doesn't affect me. I also agree with you that LIBGL_DRIVERS_PATH is not the best variable name. It made sense when the only loader (outside the X server) was in libGL. But, now we also have libEGL and libgbm. If we were adding it today, I would suggest DRI_DRIVERS_PATH. But it's been LIBGL_* for years, and is documented, and well known...so I don't think it's worth changing. Which does bring up another data point: there isn't a separate LIBEGL_DRIVERS_PATH variable for specifying the DRI driver path - it just uses LIBGL_DRIVERS_PATH like libGL/GLX. Nobody has asked for one either... --Ken
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
