[RFC vmmouse] Install support files to try and have the driver loaded automatically via udev.

Dan Nicholson dbn.lists at gmail.com
Wed Apr 7 09:10:22 PDT 2010


2010/4/7 Michel Dänzer <michel at daenzer.net>:
> On Tue, 2010-04-06 at 19:27 -0700, Dan Nicholson wrote:
>> 2010/4/6 Michel Dänzer <michel at daenzer.net>:
>> > On Thu, 2010-04-01 at 14:47 -0700, Dan Nicholson wrote:
>> >> >
>> >> > diff --git a/configure.ac b/configure.ac
>> >> > index e39fcbb..b3d006f 100644
>> >> > --- a/configure.ac
>> >> > +++ b/configure.ac
>> >> > @@ -59,6 +59,14 @@ AC_ARG_WITH(xorg-module-dir,
>> >> >  inputdir=${moduledir}/input
>> >> >  AC_SUBST(inputdir)
>> >> >
>> >> > +AC_ARG_WITH(xorg-conf-dir,
>> >> > +            AC_HELP_STRING([--with-xorg-conf-dir=DIR],
>> >> > +                           [Default xorg.conf.d directory [[default=$libdir/X11/xorg.conf.d]]]),
>> >> > +            [xorgconfdir="$withval"],
>> >> > +            [xorgconfdir="$libdir/X11/xorg.conf.d"])
>> >> > +XORG_CONF_DIR=${xorgconfdir}
>> >> > +AC_SUBST(XORG_CONF_DIR)
>> >>
>> >> I think you want this to default to $sysconfdir/X11/xorg.conf.d rather
>> >> than $libdir/X11/xorg.conf.d. We might think about exporting this from
>> >> xorg-server.pc.
>> >
>> > Yeah, I'm leaning towards relying on that instead of making any other
>> > guesses.
>> >
>> > Unfortunately, the new patch below breaks distcheck:
>> >
>> > Making install in udev
>> > make[2]: Entering directory `/home/daenzer/src/xorg-git/driver/xf86-input-vmmouse/build-amd64/xf86-input-vmmouse-12.6.7/_build/udev'
>> > make[3]: Entering directory `/home/daenzer/src/xorg-git/driver/xf86-input-vmmouse/build-amd64/xf86-input-vmmouse-12.6.7/_build/udev'
>> > make[3]: Nothing to be done for `install-exec-am'.
>> > test -z "/usr/local/share/X11/xorg.conf.d" || /bin/mkdir -p "/usr/local/share/X11/xorg.conf.d"
>> > /bin/mkdir: cannot create directory `/usr/local/share/X11/xorg.conf.d': Permission denied
>> > make[3]: *** [install-dist_confDATA] Error 1
>> > make[3]: Leaving directory `/home/daenzer/src/xorg-git/driver/xf86-input-vmmouse/build-amd64/xf86-input-vmmouse-12.6.7/_build/udev'
>> > make[2]: *** [install-am] Error 2
>> > make[2]: Leaving directory `/home/daenzer/src/xorg-git/driver/xf86-input-vmmouse/build-amd64/xf86-input-vmmouse-12.6.7/_build/udev'
>> > make[1]: *** [install-recursive] Error 1
>> > make[1]: Leaving directory `/home/daenzer/src/xorg-git/driver/xf86-input-vmmouse/build-amd64/xf86-input-vmmouse-12.6.7/_build'
>> > make: *** [distcheck] Error 1
>> >
>> > Any idea what's going on?
>> >
>> > make -C build-amd64 install DESTDIR=$PWD/build-amd64/install
>> >
>> > works fine.
>>
>> It's a stupid issue with distcheck. It's trying to do a non-DESTDIR
>> install with --prefix=$tmpdir or something like that, but using the
>> directory from xorg-server.pc means the file won't be under $prefix.
>> So, the way to fix it is to set DISTCHECK_CONFIGURE_FLAGS =
>> --with-xorg-conf-dir='$${datadir}/X11/xorg.conf.d' in the top-level
>> Makefile.am.
>
> Ah, indeed that works, thanks!
>
>
>> > Something else I'm wondering: Does it make sense to install the
>> > xorg.conf.d snippet unconditionally, or will it hurt with the server
>> > using HAL?
>>
>> It's kind of delicate. I think it should be done unconditionally, but
>> it might cause user configuration regressions. Since the settings in
>> xorg.conf.d will override the backend supplied options (fdi settings
>> in the case of hal), you could end up overloading some user's setup.
>> Ultimately, this is the way to go to be compatible with any server
>> backend, whether udev or hal or some other fictitious service, so I
>> think it's the right thing to do.
>
> But (how) will the InputClass be associated with anything from HAL?

For hal, you'll want to set the input.tags key to vmmouse in the fdi
file. See server commit c6d9bc092c84ad5c68083a126aa7577baa42cef7. Or,
I should say that you should have hal-probe-vmmouse also set the
input.tags key to vmmouse.

>> > diff --git a/configure.ac b/configure.ac
>> > index e39fcbb..01d30ac 100644
>> > --- a/configure.ac
>> > +++ b/configure.ac
>> > @@ -59,6 +59,18 @@ AC_ARG_WITH(xorg-module-dir,
>> >  inputdir=${moduledir}/input
>> >  AC_SUBST(inputdir)
>> >
>> > +sysconfigdir=$(pkg-config --variable=sysconfigdir xorg-server)
>>
>> Stupid nitpick. Use `` backticks for maximum shell compatibility.
>> Also, the server patch to do this hasn't landed yet, but I think you
>> knew that.
>
> Yeah, feeling optimistic. :)
>
>
>> > +            [xorgconfdir="$withval"],
>> > +            [xorgconfdir="$sysconfigdir"])
>> > +XORG_CONF_DIR=${xorgconfdir}
>> > +AC_SUBST(XORG_CONF_DIR)
>> > +
>> > +AM_CONDITIONAL(HAS_XORG_CONF_DIR, [test "x$XORG_CONF_DIR" != x])
>>
>> Beware that if the user passed --without-xorg-conf-dir (pretty valid),
>> you'll end up with XORG_CONF_DIR=no. That obviously would bomb at some
>> point. It might be better to do a check for server >= 1.8 instead. See
>> Peter's original evdev patch:
>>
>> http://lists.x.org/archives/xorg-devel/2010-March/006602.html
>>
>> I might do this whole section like this:
>>
>> [...]
>
> Thanks, but I prefer checking for the feature rather than a version -
> the xorg.conf.d support has already been backported to 1.7.x for the
> next versions of Debian and Ubuntu, I think other distros as well. Also,
> if the xorg.conf.d path can't be determined with pkg-config, I think
> it's adequate to require it being specified explicitly, as in that case
> any guess seems very likely to be wrong, leading to either the vmmouse
> snippet or worse, all other snippets being ignored.

Sounds good. They're all little corner cases that probably won't be
encountered much anyway.

> Updated patch posted (whoops, forgot to make the subject less generic),
> thanks again for all your feedback and suggestions!

Thanks for taking the time to try to adjust to the new order.

--
Dan


More information about the xorg-devel mailing list