Bug 48293 - Dependency of xf86-input-evdev-2.7.0 on mtdev should be optional.
Summary: Dependency of xf86-input-evdev-2.7.0 on mtdev should be optional.
Status: RESOLVED WONTFIX
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/evdev (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-04 05:25 UTC by teika kazura
Modified: 2012-04-14 17:48 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Patch for configure.ac. (906 bytes, patch)
2012-04-04 05:25 UTC, teika kazura
no flags Details | Splinter Review

Description teika kazura 2012-04-04 05:25:11 UTC
Created attachment 59472 [details] [review]
Patch for configure.ac.

xf86-input-evdev-2.7.0 depends on mtdev, but it should be optional.
More precisely, when the configure script detects mtdev, the evdev driver always depends on mtdev. But it doesn't  necessarily have to be so.

This can simply be fixed by adding "--without-mtdev" option to the configure script. I attach a patch. (Of coures I tested the patch, but it's my first time to touch configure.ac. I hope I'm correct.)

This is important for source-based linux distros like Gentoo:
http://www.gentoo.org/proj/en/qa/automagic.xml

Thanks beforehand.
Comment 1 Chí-Thanh Christopher Nguyễn 2012-04-04 05:40:36 UTC
It would probably be good if configure bails out when a user specifies --with-mtdev but lacks mtdev or recent enough inputproto/xorg-server.
Comment 2 teika kazura 2012-04-04 23:46:14 UTC
You're right. But I can't spare that much time to learn autoconf. Sorry.
Comment 3 Peter Hutterer 2012-04-09 18:04:57 UTC
what is your exact use-case here? mtdev is needed, we wrap all multitouch devices through it. without mtdev, you won't get multitouch support, so I don't quite see why this is useful here.
Comment 4 teika kazura 2012-04-10 05:53:21 UTC
Good question. I know it doesn't matter for binary distros, but it does for Gentoo Linux.

> mtdev is needed,

Let us be exact. mtdev is optional, as you said later. But current configure.ac almost forces mtdev dependency to be mandatory, not an option.

The biggest problem is the dependency is determined solely by the installation order, not by users' will. For testing (by developers) or whichever purpose, there may already exist mtdev. If you don't want evdev-driver to have mtdev support, or want to drop the multitouch feature after some trouble, then you have to uninstall mtdev before building evdev-driver. (If you insist it's a Gentoo's defect, I can't refute. =P) My patch changes it to an explicit option.

The above patch is necessary to fix this Gentoo bug:
  https://bugs.gentoo.org/show_bug.cgi?id=410723
(I'm not a Gentoo Linux developer, but a user.)

I forgot to tell that the patch above doesn't affect the default behavior; without --without-mtdev, mtdev support depends on the existence of XI2.2 and mtdev.

If the patch doesn't affect other distros nor Gentoo, I wonder if it won't harm to adopt it, even if it's not perfect.

Thank you, Peter Hutterer, for reading, and for your commitment in X inputs.

Regards.

# BTW I've been running a small project, forking evdev driver to
# enable "space-ctrl" and/or "enter-shift" dual role keys[1]. You
# advised me that it should be in xkb2, not as an evdev driver
# fork. Yep.
# Recently I found one person publish a program[2] with a similar goal
# using X Record extension, so living totally in the userland. But
# it's still rudimentary and personal.

[1] http://gitorious.org/at-home-modifier/pages/Home
[2] https://github.com/r0adrunner/Space2Ctrl (original, in C++) and https://github.com/baskerville/keydouble (based on the former, in C)
Comment 5 Peter Hutterer 2012-04-10 15:32:22 UTC
(In reply to comment #4)
> Good question. I know it doesn't matter for binary distros, but it does for
> Gentoo Linux.
> 
> > mtdev is needed,
> 
> Let us be exact. mtdev is optional, as you said later. But current configure.ac
> almost forces mtdev dependency to be mandatory, not an option.

I don't understand. If you don't have mtdev installed, you don't get MT support. If you have it installed (and the XI 2.2 headers) you do get MT support. There's nothing mandatory about mtdev, it's just required to get the MT parts but ./configure should succeed either way.

> The biggest problem is the dependency is determined solely by the installation
> order, not by users' will. For testing (by developers) or whichever purpose,
> there may already exist mtdev. If you don't want evdev-driver to have mtdev
> support, or want to drop the multitouch feature after some trouble, then you
> have to uninstall mtdev before building evdev-driver. (If you insist it's a
> Gentoo's defect, I can't refute. =P) My patch changes it to an explicit option.
> 
> The above patch is necessary to fix this Gentoo bug:
>   https://bugs.gentoo.org/show_bug.cgi?id=410723
> (I'm not a Gentoo Linux developer, but a user.)

mtdev is a library. we require other libraries to be present before building evdev too, so I don't understand why the automagic argument comes from. surely you'd expect to install a library before building something that requires it?
aside from mtdev, we also require libudev, the server, and a few other things and these are even hard requires.

as for the "drop MT feature after trouble", IMO it's better to fix the bugs that caused it than simply disable it.

 > I forgot to tell that the patch above doesn't affect the default behavior;
> without --without-mtdev, mtdev support depends on the existence of XI2.2 and
> mtdev.
> 
> If the patch doesn't affect other distros nor Gentoo, I wonder if it won't harm
> to adopt it, even if it's not perfect.

it adds an option that will be kicked out for the next release. right now, my plan is to require it for 2.8 to rid the driver of too many ifdefs.
Comment 6 teika kazura 2012-04-14 17:48:38 UTC
Ok. I understand your decision, and I changed the bug status to "wontfix".

Thanks anyway.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.