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

[Bryce Harrington]

On Wed, Aug 26, 2015 at 11:05:28AM +0100, Daniel Stone wrote:
> Hi,
> 
> 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:
> >> On 24/08/15 06:27 AM, Pekka Paalanen wrote:
> >> > From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> >> >
> >> > Bumping libdrm requirement by 3 years just for output connector name
> >> > constants was a bit much. Fix the problem introduced in
> >> > 89c49b3060a115e846ba1e7fbef94d14894244f2 by conditionally using the new
> >> > additions.
> >> >
> >> > Both VIRTUAL and DSI came in the same libdrm commit
> >> > 566c3ce877a4be72697e15cdfc421ce965f7c37d, so we check only for DSI.
> >>
> >> 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".

Bryce