This reverts commit 064445364b.
The Lenovo *50 series, including the X1 Carbon 3rd always require multiple
kernel patches to enable the touchpad buttons. This patch in synaptics only
addresses the re-routing of the top buttons.
The final iteration of the kernel patches also route the trackpoint buttons
through the trackpoint device, rendering this patch unnecessary. These patches
are queued for 4.0.
See kernel patch series up to commit cdd9dc195916ef5644cfac079094c3c1d1616e4c
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date: Sun Mar 8 22:35:41 2015 -0700
Input: synaptics - re-route tracksticks buttons on the Lenovo 2015 series
Currently in Dmitry's for-linus branch.
Distributions running older kernels or the kernel stable series which has
partial backports of the above patch series are encouraged to leave the
0644453 commit in and undo this revert.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This device has the trackpoint buttons wired up to the touchpad to send BTN_0,
BTN_1 and BTN_2 for left, right, middle. This conflicts with previous
touchpads that used those event codes for dedicated scroll buttons.
Add an option HasTrackpointButtons that can be set via a xorg.conf.d
snippets. This option is not intended as a user-set option, rather
we expect distributions to ship some conglomerate of udev/hal rules with
xorg.conf snippets that take effect.
If the option is set, we look at the three affected buttons at the beginning
of HandleState and send button events immediately for them. The HW state is
reset to neutral and other processing continues. This saves us from having to
synchronize these buttons with software buttons (also present on this device),
tapping, etc.
Since the buttons are physically different and (mentally) associated with the
trackpoint device we also don't need to worry about having finger motion event
correctly synced up with the button presses - it's acceptable to send the
presses before the motion events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Per-device logging functions don't interfere with other drivers if they also
use libevdev, so use those instead the global log handler if available. If not
available, drop libevdev logging, I don't want to maintain the ifdef mess and
the logging doesn't give us _that_ much benefit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All kernel touchpad devices now support slots, there isn't really a need to
support protocol A devices in synaptics. If such devices exist, we just treat
them as non-multitouch devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This suite was never really maintained anyway, and it is quite hard to do so
anyway. The driver is linked to the server's API too tightly to easily do
independent testing. We need to re-implement stubs for the API the driver
uses, have to track API changes, etc. Not worth the effort.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This has a potential bug that would need to be fixed in mtdev first:
if we get a SYN_DROPPED and we miss out on events, the current code emulates a
normal EV_SYN, feeds that to mtdev and hopes that that fills the mtdev output
queue.
If mtdev doesn't generate events on that EV_SYN, we're stuck in limbo and may
get weird results. The loop will continue and sync the device, but there's the
off chance we get odd events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This drops conditional compilation of multitouch support, smooth scrolling
support and old ABIs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Since a missing mtdev disables all of multitouch on eventcomm, we might as
well always require it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
This reverts commit 39afe69ad7.
1. For such a small module, the build time improvement is most likely
negligible. At least, I'd like to see some timings proving it's
worthiness before seeing the patch go back in.
2. This kind of change would need a thorough review. The need to
operate the build from a single toplevel Makefile is a significant
change. The two most noticeable issues for me are that collapsing all
the Makefiles could easily cause namespacing issues with the
variables, and operating on files outside the current directory can
introduce subtle bugs. I feel that the non-recursive style is
generally less robust than the standard recursive make scheme.
3. It's unlike all the other X.org modules. This isn't a showstopper
for me, but the recursive style is well understood here and you've
beaten all the modules into a consistent format that makes build bugs
unique to specific modules less likely.
Acked-by: Dan Nicholson <dbn.lists@gmail.com>
To give a concrete example for #3 above, the 175 man pages are much
easier maintained using a very similar makefile in the man directory
of all X.Org module.
The cost of maintaining a single makefile is much higher. Every target
in the makefile has to be reviewed and tested when changes are made.
Not everyone has the all the skills to handle widely different targets
such as man pages, DocBook/XML, librairies, C code, distribution hooks,
and so on.
Acked-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
This reverts commit 6eb829e07e.
Althought this feature is desirable, it introduces a dormant bug.
The value of sdkdir during distcheck points to an empty xserver sdkdir
where xserver-properties.h is expected by the tools.
Specifying XORG_CFLAGS for the tools worked around the issue by supplying
the real path to the xserver sdk. tools must not depend on xserver.
In any case it would be a brittle workaround.
--with-xorg-conf-dir='$${sysconfdir}/xorg':
althought this value will work, it brings some confusion as it is
unrelated to the where the configuration files are normally placed,
relative to $prefix which is /usr/share/X11 and not /etc.
This feature can be reintroduced later with the proper solution.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
With this change it is possible to complete "make distcheck" safely on the
module, as it no longer tries to write to system directories.
Since synaptics also installs a configuration file, xorg-conf-dir also
needs to be overridden during distcheck.
Signed-off-by: Diego Elio Pettenò <flameeyes@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This allows building object files following the same subdirectory structure
as it was used before with the recursive build system, while keeping the
build non-recursive.
Signed-off-by: Diego Elio Pettenò <flameeyes@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With this change, the whole of the build is done non-recursively in the
top-level Makefile.am. This reduces the amount of overhead due to recursing
into directories only to build one file.
Signed-off-by: Diego Elio Pettenò <flameeyes@gmail.com>
Signed-off-by: Christoph Brill <egore911@egore911.de>
Just to give a bit of an idea of what the problem is when configure fails
later on.
Signed-off-by: Diego Elio Pettenò <flameeyes@gmail.com>
Signed-off-by: Christoph Brill <egore911@egore911.de>
Also adds a bunch of fake symbols so we can link. Note that any of these
symbols will return false, 0 or whatever the zero value for the symbol is.
Care must be taken when writing test that this doesn't screw up the test.
Tests are always built but only run on make check.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
