Thoses definitions have been included in the kernel and in the X server.
However, the evdev driver has not been updated accordingly.
Without these definitions, the multitouch axes are not correctly labelled.
Signed-off-by: Benjamin Tissoires <tissoire@cena.fr>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When one of the tools comes into proximity, queue up a proximity event and
send it accordingly.
Includes special handling for tablets that do not send axes with tools
(#29645)
Some tablets send axis values, then EV_SYN, and in the next event the
BTN_TOOL_PEN/BTN_TOUCH, etc. For these tablets, the cursor doesn't move as
coordinates while not in proximity are ignored.
Buffer coordinates received while out-of-proximity and if we get a proximity
event without other coordinates, re-use the last ones received.
X.Org Bug 29645 <http://bugs.freedesktop.org/show_bug.cgi?id=29645>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chris Bagwell <chris@cnpbagwell.com>
Reviewed-by: Benjamin Tissoires <tissoire@cena.fr>
evdev doesn't care about the actual tool used, only that it is used as an
indicator for proximity. Rename the field accordingly to make the code more
obvious to read.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chris Bagwell <chris@cnpbagwell.com>
If first_v was not zero, the values passed to xf86PostMotionEventP were
wrong.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <tissoire@cena.fr>
We only use them as values, no need for the addresses.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <tissoire@cena.fr>
Factor out access to the next queue element in a static function to be
reused for button and key presses.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <tissoire@cena.fr>
Removed from the server with
commit 6130170e7e9b64c611ee942ec3455dd1a185193d
Author: Adam Jackson <ajax@redhat.com>
Date: Sat Sep 18 06:41:35 2010 -0400
xfree86: Remove unused refcounting from input drivers
And given that it was unused, we don't need to ifdef it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now BTN_MOUSE, BTN_MISC and BTN_DIGI button ranges are all mapped to the
same lower numbers including first three, corresponding to the LMR mouse
buttons. Like this:
1 BTN_LEFT BTN_0 BTN_TOUCH
2 BTN_MIDDLE BTN_1 BTN_STYLUS
3 BTN_RIGHT BTN_2 BTN_STYLUS2
8 BTN_SIDE BTN_3
9 BTN_EXTRA BTN_4
10 BTN_FORWARD BTN_5
11 BTN_BACK BTN_6
12 BTN_TASK BTN_7
13 BTN_8
14 BTN_9
This streamlines the button mapping under the assumption that these ranges
don't generally appear in a single device simultaneously. If they do appear,
they will simply report overlapping button numbers.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These three buttons are mapped into buttons 1/2/3, respectively.
Overlapping range with BTN_LEFT/MIDDLE/RIGHT, assuming that these
ranges don't generally appear in a single device simultaneously.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Current implementation assumes that X & Y axes have the same min and max
values. If they don't, you'll end up with funny behaviour if SwapAxes is
turned on.
Signed-off-by: Tim Yamin <plasm@roo.me.uk>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Improve dumb tablet detection by checking if BTN_STYLUS or BTN_STYLUS2
(first or second pen barrel button) is present when BTN_TOOL_PEN is not
found.
This enables detection of tablets without explicit tool proximity reporting.
These include at least four UC-Logic tablet models: WP4030U, WP5540U,
WP8060U and PF1209, on which many Genius and Trust models are based.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fix incorrect usage of BTN_DIGI instead of BTN_TOOL_PEN in comments.
Fix forgotten pEvdev->digi reference.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Devices that don't have a tool but BTN_TOUCH simply have the tool always on.
Devices that have a tool other than BTN_TOUCH set this tool before BTN_TOUCH
is emitted anyway.
X.Org Bug 29428 <http://bugs.freedesktop.org/show_bug.cgi?id=29428>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
PreInit can now return different error codes. Return BadAlloc for alloc
failures and BadMatch if the device was already configured or the cache
comparison/probe failed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The server doesn't provide these defines anymore, define them here for
future use. To be purged whenever we drop support for the current server.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
XI86_KEYBOARD_CAPABLE was write-only, both in the driver and the server.
XI86_POINTER_CAPABLE was write-only in the server and can be emulated with
has_abs_axes and has_rel_axes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The AUTO feature was the default, MB emulation was on until a middle mouse
button was pressed. MB emulation however results in a delay of the first
press, causing minor annoyances to the users and being generally confusing
when the behaviour before a button press is different to after a button
pres.
Disable the feature by default instead. There's not a lot of two-button mice
around anymore though and the inability to detect two-button mice makes for
non-deterministic detection of when the emulation should be on.
Middle button emulation can be enabled with a configuration snippet:
Section "InputClass"
Identifier "middle button emulation"
MatchIsPointer "on"
Option "Emulate3Buttons" "on"
EndSection
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Evdev is Linux-only, and we've had the above calls for quite a while now.
Plus, now that the server has removed them they generate _a lot_ of warnings
otherwise.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
What we're getting back from xf86SetStrOption is a strdup'd string, not
const, especially given that we free it a few lines down.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Just have one exit path instead of different ones. Guards are in place to
avoid freeing/deleting something that shouldn't be.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
The reason for this rather weird approach is to ungrab immediately after
getting a successful grab. Evdev shouldn't be hogging the device if nothing
is done with it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
For earlier kernels, use the previous hardcoded resolution in place.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Include it in evdev.h instead.
xorg-server.h is required to define the right datatype sizes on 64 bit,
hence ensure that evdev.h is the first included in each file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Gaetan Nadon <memsize@videotron.ca>
Called function "ioctl" whose return value should be checked (checked 10
out of 11 times)
Signed-off-by: Oliver McFadden <oliver.mcfadden@nokia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The generated config.h does not need to include xorg-server.h
for the content it provides.
Add #include <xorg-server.h> in .[hc] files as needed.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
This allows the backend to propery initialize the feedback from options,
as it works with most other drivers. This is the hacky equivalent of
fixing the initialization of pointer acceleration, which would require
changes to most drivers however.
Signed-off-by: Simon Thum <simon.thum@gmx.de>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Touchpads that have physical buttons have either LMR or BTN_TOOL_FINGER.
Other buttons in the range evdev recognises shouldn't be taken into account
here - they skew the detection towards touchpads and away from touchscreens.
Fedora Bug 571639
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Simon Thum <simon.thum@gmx.de>
Because touchscreens only use one button (see EvdevProcessKeyEvent())
EvdevMBEmuFilterEvent() never calls EvdevMBEmuEnable(..., FALSE) to
disable emulation. This results in touchscreen devices incurring a delay
of Emulate3Timeout (typically 50 ms.)
Default to MBEMU_DISABLED for touchscreen devices (unless overwritten by
Xorg.conf.)
Signed-off-by: Oliver McFadden <oliver.mcfadden@nokia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Compiler warning flags should be explicitly set in the makefile
rather than being merged with other packages compiler flags.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Implement XSetDeviceMode request handler for evdev.
Devices with absolute axes can be switched in relative
mode or absolute mode. Devices with relative axes
can be switched only in relative mode. Other devices
return BadMatch, cause they have no valuators and
don't report motion events.
New option "Mode" force devices with absolute axes
to work in relative or absolute mode.
Need xinputproto.
Signed-off-by: Andrej Gelenberg <andrej.gelenberg@udo.edu>
