[PATCH weston] build, compositor-drm: fix output name constants another way

[Daniel Stone]

Hi,

On 26 August 2015 at 21:17, Bryce Harrington <bryce at osg.samsung.com> wrote:
> On Wed, Aug 26, 2015 at 11:05:28AM +0100, Daniel Stone wrote:
>> On 25 August 2015 at 00:32, Bryce Harrington <bryce at osg.samsung.com> wrote:
>> > On Mon, Aug 24, 2015 at 12:32:33PM -0500, Derek Foreman wrote:
>> >> Hmm, this is somewhat gross.  Is there a solid reason to care about
>> >> people who want to run new weston and ancient libdrm?
>> >
>> > I've been on the other side of this equation.  libdrm can be a royal
>> > PITA to have to change out, I can totally imagine there are several
>> > quite solid reasons one would want to run new weston and oldish libdrm.
>>
>> Hm, how so? It doesn't break backwards compatibility, only adds new
>> symbols; the only exception I can think of is Nouveau when it had its
>> ABI break, but that was exceptional in a lot of ways.
>
> Where I ran into troubles was in relation to proprietary driver madness.
> The first time was when we initially introduced poulsbo on Ubuntu, since
> it required a special modified libdrm that was a PITA to roll out safely
> to users.  Second time was enabling Steam on Ubuntu; the Valve guys
> needed the ability to "easily" upgrade LTS user's X stack esp. including
> NVIDIA drivers; libdrm ended up being the one piece we had to kind of
> brute force into place.
>
> None of which is libdrm's fault.  Proprietary drivers just make life
> difficult.  But I can sympathize with people that find themselves in a
> situation where they can't "just upgrade libdrm".

Oh yeah, that makes total sense. The usual scenario here is in the
embedded world, where people get a hacked-to-bits BSP from Mentor or
similar, and either can't upgrade it, or have to pay some large fee to
do so; usually involving re-doing validation. I was just wondering if
there were cases where that held true for open systems or not.

Cheers,
Daniel