For touchpads, rel_queued may be on (due to abs to rel conversion) but the
delta for x/y is 0/0 on the first touch. Hence, we don't have any valuators
to post. The current results in a num_vals of -15 and a subsequent segfault
when the data is posted to the server.
Start with a last valuator of -1, so that we know if we have at least one to
post.
X.Org Bug 32480 <http://bugs.freedesktop.org/show_bug.cgi?id=32480>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Touchpads send garbage data between BTN_TOOL_FINGER and BTN_TOUCH. This
leads to cursor movement towards invalid positions (bottom left corner,
usually).
Add a new flag "use_proximity" as a delimiter for BTN_TOUCH handling. If
unset, the actual proximity bits are ignored, no proximity events are sent
and BTN_TOUCH is used for the tool handling.
Example event stream for synaptics:
Event: time 1292893041.002731, -------------- Report Sync ------------
Event: time 1292893041.015807, type 1 (Key), code 330 (Touch), value 0
Event: time 1292893041.015812, type 3 (Absolute), code 0 (X), value 4283
Event: time 1292893041.015813, type 3 (Absolute), code 1 (Y), value 4860
Event: time 1292893041.015815, type 3 (Absolute), code 24 (Pressure), value 23
Event: time 1292893041.015817, type 3 (Absolute), code 28 (Tool Width), value 5
Event: time 1292893041.027537, -------------- Report Sync ------------
Event: time 1292893041.038854, type 3 (Absolute), code 0 (X), value 1
Event: time 1292893041.038857, type 3 (Absolute), code 1 (Y), value 5855
Event: time 1292893041.038859, type 3 (Absolute), code 24 (Pressure), value 1
Event: time 1292893041.038861, type 3 (Absolute), code 28 (Tool Width), value 5
Event: time 1292893041.038864, -------------- Report Sync ------------
Event: time 1292893041.062432, type 3 (Absolute), code 24 (Pressure), value 0
Event: time 1292893041.062435, type 3 (Absolute), code 28 (Tool Width), value 0
Event: time 1292893041.062437, type 1 (Key), code 325 (ToolFinger), value 0
Event: time 1292893041.062438, -------------- Report Sync ------------
Reported-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chris Bagwell <chris@cnpbagwell.com>
Synaptics devices send garbage between BTN_TOUCH and BTN_TOOL_FINGER. By
switching to use this as proximity data now, the pointer is reset to the
garbage data position (usually around 1/5855).
This reverts commit 899218e181.
Reported-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chris Bagwell <chris@cnpbagwell.com>
Since 59056e656c (Remove the reopen timer logic) from last year,
EvdevCacheCompare() is only used for caching ioctl values and not for
comparing, so remove the unused compare logic and rename the function
to EvdevCache().
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The server's behaviour is to stop adding new devices when a BadAlloc occurs
on any device (on the assumption that new devices won't magically have more
memory). Change EvdevOpenDevice() to return an error code of BadValue when
it fails (and thus to the server) to prevent other devices being ignored
because of one misconfigured one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Instead of two lists that need to be kept in sync, just store the bits in an
array and run through them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <tissoire@cena.fr>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Mainly to avoid confusing between pEvdev->prox and pEvdev->proximity and to
better express what these fields are actually holding.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <tissoire@cena.fr>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
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>
It depends on util-macros 1.8
The existing statement can now be removed from the configuration file.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Use MAN_SUBST now supplied in XORG_MANPAGE_SECTIONS
The value of MAN_SUBST is the same for all X.Org packages.
Use AC_PROG_SED now supplied by XORG_DEFAULT_OPTIONS
The existing statement can now be removed from the configuration file.
Use Automake $() for variables in Makefile.am
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
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>
It sets the SED env variable with an appropriate sed program path
It still works on some platform when not explicity called.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
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 sdk_HEADERS is sufficient as the "sdk" prefix
matches the "dir" suffix in the "sdkdir" variable.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Fix some m4 quoting
Fix some autoconf warnings
remove AC_PROG_CC as it overrides AC_PROG_C_C99 from XORG_DEFAULT_OPTIONS
Regroup statements per section
Add comments
Upgrade X.Org macros to 1.4 for INSTALL file copying
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
The check should be in PKG_CHECK_MODULES permanently.
The XORG_DRIVER_CHECK_EXT will add inputproto to PKG_CHECK_MODULES
only if the extension is available. By definition, this extension
is always available and the evdev driver cannot function without it.
This is evidenced by the absence of XINPUT conditional code.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Autoconf says:
"This macro is obsolescent, as current systems have conforming
header files. New programs need not use this macro".
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Unrelated to the previous patches, the new value simply reflects
the reality that the minimum level for autoconf to configure
all x.org modules is 2.60 dated June 2006.
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.60.tar.gz
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
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>
BTN_TOOL_* is treated as tool, just like before. BTN_TOUCH on the other hand
may need to be treated as a button left press. This again requires a button
class.
Tested on an HP Touchsmart and a Wacom tablet.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where an initial calibration is provided through the Calibration option
to the driver, it wasn't being exposed in the 'Evdev Axis Calibration'
property. Remedy that...
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the SwapAxes option is set, the X and Y axes in calibration should
be labelled as the user perceives them -- not as the kernel sends them.
Currently, we apply the X-axis calibration to the X-axis of the input,
and then do the axis swapping so we've actually applied the X-axis
calibration to what the user sees as the Y-axis.
This patch changes the order of the operations, so that the axes are
swapped before the calibration is applied.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add missing INSTALL file. Use standard GNU file on building tarball
README may have been updated
Remove AUTHORS file as it is empty and no content available yet.
Remove NEWS file as it is empty and no content available yet.
The git generated ChangeLog replaces the hand written one.
Update configure.ac to xorg-macros level 1.3.
Use XORG_DEFAULT_OPTIONS which replaces four XORG_* macros
Update Makefile.am to add ChangeLog target if missing
Remove ChangeLog from EXTRA_DIST or *CLEAN variables
This is a pre-req for the INSTALL_CMD
Using common defaults will reduce errors and maintenance.
Only the very small or inexistent custom section need periodic maintenance
when the structure of the component changes. Do not edit defaults.
We should process all the deltas reported by a relative motion device,
otherwise some devices such as A4Tech X-750F or similar may trigger a
situation when the `v` array contains random values (it isn't
initialized anywhere) and later we process them and in effect the mouse
cursor "jumps" on the screen.
I'm not sure why, but we also must be sure that the `first` and `last`
variables reflect the axis map, otherwise the mouse cursor "jumps" on
the screen when clicking mouse buttons in some rare cases reported by
Bartek Iwaniec on Bugzilla. That's why a simple initialization of the
`v` array with zeros isn't sufficient.
X.Org Bug 24737 <http://bugs.freedesktop.org/show_bug.cgi?id=24737>
Signed-off-by: Bartosz Brachaczek <b.brachaczek@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When checking whether we are dealing with the same device as before
when we try to reopen it evdev should not require exact match of
entire keymap. Users should be allowed to adjust keymaps to better
match their hardware even after X starts. However we don't expect
changes in [BTN_MISC, KEY_OK) range since these codes are reserved for
mice, joysticks, tablets and so forth, so we will limit the check to
this range.
The same goes for absinfo - limits can change and it should not result
in device being disabled.
Also check the length of the data returned by ioctl and don't try to
compare more than we were given.
[peter: moved the key comparison below the led+abs comparison]
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Parsing of the values was wrong. Given an input of 1 2 3 4, button 1 sets
the lock for button 2 and button 3 sets the lock for button 4.
This also means we need to return BadMatch if the property isn't a multiple
of 2.
Red Hat Bug 524428 <https://bugzilla.redhat.com/show_bug.cgi?id=524428>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This logic was needed in older kernels that sometimes gave error messages
after coming back from resume (2.6.27 release kernels). I haven't seen any
log files that needed this reopen timer in a long time, suggesting that need
for it is gone.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Xen Virtual Pointer device exports both absolute and relative axes from
the kernel device. Which coordinates are used is a run-time decision and
depends on the host-specific configuration.
0a3657d2ee broke these devices, and they are
now unusable out-of-the-box as there is no configuration to cover them.
This patch converts the IgnoreAbsoluteAxes and the IgnoreRelativeAxes
configuration options into a trinary state.
1. If unset, configure the device as normal by trying to guess the right
axis setup.
2. If set to true, ignore the specific axis type completely (except for
wheel events).
3. If set to false, explicitly 'unignore' the axis type, alwas configuring
it if it is present on the device. This setting introduces seemingly
buggy behaviour (see Bug 21832)
1. and 2. replicate the current driver behaviour.
The result of 3. is that is that if a device has absolute axes and the
options set to false, both axes will be initialized (absolute last to get
clipping right). This requires axis labelling priorty to switch from
relative first to absolute first.
Relative events are forwarded into the server through the absolute axes,
the server scales this into the device absolute range and everyone is happy.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Originally based on a patch from Daniel Stone, this commit allows for
the calibration factors to be set either from Xorg.conf or via HAL.
Previously the only way was via the properties interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a read error occurs, remove the block and wakeup handlers for middle
mouse button emulation. Otherwise, they'll still be around after the device
has been reopened and overwritten with the new ones created by EvdevOn. Once
this happened, future removal of the device can lead to a server crash.
X.Org Bug 23048 <http://bugs.freedesktop.org/show_bug.cgi?id=23048>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The X server cannot deal with devices that have both relative and absolute
axes. Evdev tries to guess wich axes to ignore given the device type and
disables absolute axes for mice and relative axes for tablets, touchscreens
and touchpad. This guess is sometimes wrong and causes exitus felis
domesticae parvulae.
Two new configuration options are provided to explicitly allow ignoring an
axis. Mouse wheel axes are exempt and will work even if relative axes are
ignored. No property, this option must be set in the configuration.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Regression:
If a user has multiple buttons mapped to the same button number, the
number of buttons counted is set to a wrong value. e.g. a button
mapping of 1 1 1 for a mouse with three buttons would only initialize 1
button to the X server.
In the future, the user cannot change this button mapping as the server
only knows about one button.
The user-supplied button map (option ButtonMapping) shouldn't matter when
counting the buttons. Only the driver-internal mapping (BTN_0 -> button 1,
etc.) matters.
X.Org Bug 23405 <http://bugs.freedesktop.org/show_bug.cgi?id=23405>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If wheel emulation is on and the emulation button is 0, then any x/y motion
of the device is converted into wheel events. The devices becomes a
scrolling-only device.
Signed-off-by: Dima Kogan <dkogan@cds.caltech.edu>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Wheel emulation works for both horizontal and vertical axes. Thus, if a
device doesn't move in perfect straight line, scroll events build up on the
respective other axis.
In some clients, scroll wheel events have specific meanings other than
scrolling (e.g. mplayer). In these clients, erroneous scrolling events come
at a high cost.
Thus, if a scroll wheel event is generated for one axis, reset the inertia
of the other axis to 0, avoiding the buildup of these erroneous scrolling
events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
