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

[Bryce Harrington]

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.

> Shouldn't anyone doing that be responsible for their own sketchy out
> of tree patches to make things go?

Perhaps.  I certainly have had to do that myself for Ubuntu.  But
it adds inconvenience to have to have local patches, and then you're not
running *exactly* upstream's code, so reporting bugs upstream becomes
more involved, etc.

In this case the patch we'd need to carry is fairly tiny, and it
presumably will help not only this guy but anyone else in the same
situation.  Like pq pointed out, this got flagged so quickly there could
be quite a few others.
 
> At this point I guess atomic isn't likely to land in time for 1.9, but
> as soon as it does (presumably before 1.10) an even newer libdrm will be
> required anyway.
> 
> Can you add a comment about why we have the ifdef so there's a greater
> chance someone will actually remove it after the mandatory version bump
> happens for 1.10?

Perhaps a patch to remove the #ifdefs could be added to the atomic kms
patch stack, so no one has to remember to do anything.  :-)
 
> (either that or just ignore those two weird connector types and let them
> be unknown - what are they anyway?)

I'd be fine with that too, but I really don't see the harm in having
them there but #ifdef'd.

Bryce
 
> That done,
> Reviewed-by: Derek Foreman <derekf at osg.samsung.com>
> 
> > This patch also reverts faee330c5e027011941d50533156683be3a67ca3.
> > 
> > Reported-by: Eugen Friedrich <friedrix at gmail.com>
> > Cc: Derek Foreman <derekf at osg.samsung.com>
> > Signed-off-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> > ---
> >  configure.ac         | 2 +-
> >  src/compositor-drm.c | 2 ++
> >  2 files changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/configure.ac b/configure.ac
> > index d70777d..425f071 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -171,7 +171,7 @@ AC_ARG_ENABLE(drm-compositor, [  --enable-drm-compositor],,
> >  AM_CONDITIONAL(ENABLE_DRM_COMPOSITOR, test x$enable_drm_compositor = xyes)
> >  if test x$enable_drm_compositor = xyes; then
> >    AC_DEFINE([BUILD_DRM_COMPOSITOR], [1], [Build the DRM compositor])
> > -  PKG_CHECK_MODULES(DRM_COMPOSITOR, [libudev >= 136 libdrm >= 2.4.59 gbm mtdev >= 1.1.0])
> > +  PKG_CHECK_MODULES(DRM_COMPOSITOR, [libudev >= 136 libdrm >= 2.4.30 gbm mtdev >= 1.1.0])
> >    PKG_CHECK_MODULES(DRM_COMPOSITOR_GBM, [gbm >= 10.2],
> >  		    [AC_DEFINE([HAVE_GBM_FD_IMPORT], 1, [gbm supports dmabuf import])],
> >  		    [AC_MSG_WARN([gbm does not support dmabuf import, will omit that capability])])
> > diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> > index c85a462..f5f125a 100644
> > --- a/src/compositor-drm.c
> > +++ b/src/compositor-drm.c
> > @@ -1760,8 +1760,10 @@ static const char * const connector_type_names[] = {
> >  	[DRM_MODE_CONNECTOR_HDMIB]       = "HDMI-B",
> >  	[DRM_MODE_CONNECTOR_TV]          = "TV",
> >  	[DRM_MODE_CONNECTOR_eDP]         = "eDP",
> > +#ifdef DRM_MODE_CONNECTOR_DSI
> >  	[DRM_MODE_CONNECTOR_VIRTUAL]     = "Virtual",
> >  	[DRM_MODE_CONNECTOR_DSI]         = "DSI",
> > +#endif
> >  };
> >  
> >  static char *
> > 
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel