Re: [build bug] uvc_status_cleanup(): undefined reference to `input_unregister_device'

[Mauro Carvalho Chehab <mchehab@redhat.com>]

On Wed, 11 Feb 2009 12:47:39 +0100
Laurent Pinchart <laurent.pinchart@skynet.be> wrote:

> Hi Mauro,
> 
> On Wednesday 11 February 2009 09:29:33 Mauro Carvalho Chehab wrote:
> > On Tue, 10 Feb 2009 01:44:22 +0100
> >
> > Laurent Pinchart <laurent.pinchart@skynet.be> wrote:
> > >
> > > I'm not completely satisfied with this though, as the
> > > USB_VIDEO_CLASS_INPUT_EVDEV completely disappears from the configuration
> > > menu if INPUT is set to 'm' and USB_VIDEO_CLASS to 'y'. Being no Kconfig
> > > guru, I'd appreciate if someone could help me to find a nicer fix (if
> > > that's possible at all).
> >
> > This doesn't seem to be right. You're just disabling INPUT, if CONFIG_INPUT
> > = m and USB_VIDEO_CLASS=y. You should, instead, force USB_VIDEO_CLASS to be
> > 'm' or 'n' on such case.
> >
> > IMO, a better approach would be the one on the patch bellow.
> >
> > Cheers,
> > Mauro
> >
> > Fix input dependencies on uvc driver
> >
> > As reported by Ingo:
> > -tip testing found that certain (user-reachable) Kconfig combinations
> > can cause this build failure on latest mainline:
> >
> >  drivers/built-in.o: In function `uvc_status_cleanup':
> >   (.text+0x221cca): undefined reference to `input_unregister_device'
> >   drivers/built-in.o: In function `uvc_status_init':
> >   (.text+0x221d4c): undefined reference to `input_allocate_device'
> >   drivers/built-in.o: In function `uvc_status_init':
> >   (.text+0x221db3): undefined reference to `input_free_device'
> >   drivers/built-in.o: In function `uvc_status_init':
> >   (.text+0x221ec6): undefined reference to `input_register_device'
> >   drivers/built-in.o: In function `uvc_status_complete':
> >   uvc_status.c:(.text+0x2222ec): undefined reference to `input_event'
> >
> > triggered on v2.6.29-rc3-697-gae1a25d. The problem is this combination:
> >
> >   CONFIG_INPUT=m
> >   CONFIG_USB_VIDEO_CLASS=y
> >   CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> >
> > diff --git a/drivers/media/video/uvc/Kconfig
> > b/drivers/media/video/uvc/Kconfig index c2d9760..fab4733 100644
> > --- a/drivers/media/video/uvc/Kconfig
> > +++ b/drivers/media/video/uvc/Kconfig
> > @@ -1,5 +1,6 @@
> >  config USB_VIDEO_CLASS
> >  	tristate "USB Video Class (UVC)"
> > +	depends on !USB_VIDEO_CLASS_INPUT_EVDEV || INPUT
> >  	---help---
> >  	  Support for the USB Video Class (UVC).  Currently only video
> >  	  input devices, such as webcams, are supported.
> > @@ -9,7 +10,7 @@ config USB_VIDEO_CLASS
> >  config USB_VIDEO_CLASS_INPUT_EVDEV
> >  	bool "UVC input events device support"
> >  	default y
> > -	depends on USB_VIDEO_CLASS && INPUT
> > +	depends on INPUT
> >  	---help---
> >  	  This option makes USB Video Class devices register an input device
> >  	  to report button events.
> 
> That's even worse. The following configurations would then be valid
> 
> INPUT = m/y
> USB_VIDEO_CLASS = n
> USB_VIDEO_CLASS_INPUT_EVDEV = m/y
> 
> USB_VIDEO_CLASS_INPUT_EVDEV must depend on USB_VIDEO_CLASS to be displayed as 
> a child of USB_VIDEO_CLASS in the configuration menu.

USB_VIDEO_CLASS_INPUT_EVDEV can't be m, since it is bool. But, you're right:
we'll loose the dependency of USB_VIDEO_CLASS_INPUT_EVDEV and USB_VIDEO_CLASS.

There's another alternative, if we consider that all systems but a few embedded
ones have input defined.

We may do something like:

diff --git a/drivers/media/video/uvc/Kconfig b/drivers/media/video/uvc/Kconfig index c2d9760..14e7537 100644
--- a/drivers/media/video/uvc/Kconfig
+++ b/drivers/media/video/uvc/Kconfig
@@ -1,5 +1,6 @@
 config USB_VIDEO_CLASS
 	tristate "USB Video Class (UVC)"
+	depends on INPUT
 	---help---
 	  Support for the USB Video Class (UVC).  Currently only video
 	  input devices, such as webcams, are supported.

I suspect that this will work fine for all practical usages.

Another option would be to have a generic option at V4L for evdev interfaces
(config MEDIA_EVDEV), that is independent of uvc (the same kind of dependency
exists on other drivers at the subsystem, like cx88, saa7134, etc). It will be
a larger changeset, but maybe useful, since someone may disable EVDEV interface
for other V4L/DVB drivers as well.

Cheers,
Mauro.