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>
(cherry picked from commit 1b0df04abe)
Relative devices can't be calibrated anyway so why bother.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 2ca24a16f0)
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>
(cherry picked from commit 7b285a802b)
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>
(cherry picked from commit f187badb71)
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>
(cherry picked from commit c1f16a4f59)
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>
(cherry picked from commit a0f7f34dc5)
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>
(cherry picked from commit 11669d8279)
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>
The previous checks for BTN_TOOL_FINGER and BTN_TOUCH reported false
positives for touchpads for most popular tablets.
As a result, their events were converted to relative events.
Add a new flag EVDEV_TABLET pending presence of BTN_TOOL_PEN and ignore the
touchpad special casing to report the events as-is.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The wheel emulation code needs this API. When the timer expires, the event
must be posted immediately, not enqueued onto the internal event queue.
Otherwise, the emulated middle button press is enqueued only and no event is
sent until the next physical event (and its EV_SYN) arrives.
Since the timer is triggered outside of the SIGIO and SIGIO is blocked
during this period anyway, we could also just enqueue the event and flush by
simulating an EV_SYN. It's easier this way though.
X.Org Bug 23269 <http://bugs.freedesktop.org/show_bug.cgi?id=23269>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Oliver McFadden <oliver.mcfadden@nokia.com>
Button and key events aren't posted from EvdevPost*Event, they are simply
enqueued onto the evdev-internal event queue until the next EV_SYN arrives.
Rename those interfaces from EvdevPost* to EvdevQueue* and leave only those
that actually post to the server with a matching "*Post*" name.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Oliver McFadden <oliver.mcfadden@nokia.com>
This patch fixes a regression introduced with 1f641d75e.
Wheel axis events are posted as button clicks, a device may have no relative
axes but it does need to post these button clicks.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The relevant comment from evdev.c:
We don't allow relative and absolute axes on the same device. The
reason is that some devices (MS Optical Desktop 2000) register both
rel and abs axes for x/y.
The abs axes register min/max; this min/max then also applies to the
relative device (the mouse) and caps it at 0..255 for both axes.
So, unless you have a small screen, you won't be enjoying it much;
consequently, absolute axes are generally ignored.
However, currenly only a device with absolute axes can be registered
as a touch{pad,screen}. Thus, given such a device, absolute axes are
used and relative axes are ignored.
The code for initializing abs/rel axes has been abstracted out into
3 functions, so that initialization in EvdevInit(device) is as easy
as:
if (pEvdev->flags & (EVDEV_TOUCHPAD | EVDEV_TOUCHSCREEN))
EvdevInitTouchDevice(device, pEvdev);
else if (pEvdev->flags & EVDEV_RELATIVE_EVENTS)
EvdevInitRelClass(device, pEvdev);
else if (pEvdev->flags & EVDEV_ABSOLUTE_EVENTS)
EvdevInitAbsClass(device, pEvdev);
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is similar to commit 1f641d75ed.
It provides the same functionality of queuing the (in this case
emulated) events and waiting until an EV_SYN synchronization event is
received before posting them to the server.
This preserves the order of events (both real and emulated) and ensures
that MotionNotify events will always be posted first. It also unifies
the event posting into a few small functions which improves
maintainability.
From this point on, you should never use the xf86Post...Event()
functions in new code, but rather the EvdevPost...Event() versions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of just posting the button/key press/release events to the
server as soon as they arrive, add them to an internal queue and post
them once we receive an EV_SYN synchronization event.
The motion events are always sent first, followed by the queued events.
There will be one motion event and possibly many queued button/key
events posted every EV_SYN event.
Note that the size of the event queue (EVDEV_MAXQUEUE) is arbitrary and
you may change it. If we receive more events than the queue can handle,
those events are dropped and a warning message printed.
Tested on my Lenovo T400 using evdev for all input devices; keyboard,
touchpad, and trackpoint.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Event unsigned_compare: Comparing unsigned less than zero is never true. "pEvdev->emulateWheel.timeout < 0UL"
342 if (pEvdev->emulateWheel.timeout < 0)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Griffin Powermate only has a single axis (REL_DIAL). This axis is
posted as horizontal scroll wheel, so we need to ensure the scroll wheel
setup (including ensuring that enough buttons are available) is triggered
accordingly.
X.Org Bug 21457 <http://bugs.freedesktop.org/show_bug.cgi?id=21457>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
88eedea281 added axis labelling to the
valuator initialization. This requires the axis mapping to be established
before the absolute axis labels are initialized.
88eedea did this for relative axes, but missed out on the absolute ones. As
a result, all abs. labels were initialized to "None".
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some devices have relative axes that don't count (scroll wheels). In this
case, don't claim we've initialized relative axes, continue with the
absolute axes instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The atoms array is filled with each axis atom in mapping order (i.e. after
the driver mapping has been applied). 'axis' OTOH is from 0 to ABS_MAX.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current implementation initializes itself to support relative
motion events, or absolute motion events, or neither. But the
event-handling code attempts to process all events, no matter what the
initialization was. This patch reproduces the flag tests found during
init, to skip events that the driver doesn't support.
Signed-off-by: Derek Upham <sand@blarg.net>
Signed-off-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These buttons were previously mapped to 0, i.e. inactive. This patch
slightly improves things in that the buttons are now mapped to 8+.
Devices that have both BTN_3 and BTN_SIDE (or a similar pair in that
sequence) have both mapped to the same button number though.
Devices that have BTN_LEFT, BTN_0, BTN_3 and BTN_SIDE have the last three
mapped to 8 (and their followers have double-mappings too). We'll fix that
once we actually see devices affected by this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This takes into account driver-configured button mappings, i.e. if device
with one button has this button mapped to 25 through the ButtonMapping
option, the X server will think the device has result 25 buttons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some buttons are mapped to higher button numbers. For example, BTN_0 is
posted as button 8 if BTN_LEFT is present. On top of that, the
driver-specific button mapping may map the button to something else again.
We need to take these mappings into account when counting the number of
buttons on the device.
Example: A device with BTN_LEFT and BTN_0 and a mapping from 1 -> 7 and 8 ->
2.
BTN_LEFT is mapped to 1. 1 is mapped to 7. num_buttons is 7.
BTN_0 is mapped to 8. 8 is mapped to 2. num_buttons remains 7.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Button labels would smash memory if the device had less than 4 buttons and
did not advertise a wheel event. In this case the hard-coded wheel button
labels would write past the atoms[] boundary.
Potential memory smash if a device had a BTN_LEFT and BTN_0, since the
latter would map to 8, regardless of the the number of actual buttons
(same with BTN_MIDDLE and BTN_1 or BTN_RIGHT and BTN_2).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
DisableDevice has changed API in xi2, xf86DisableDevice hasn't. So let's use
this one so we can have one version for master and xi2.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A minor copy and paste error was introduced in 71e9a69e leaving an "if"
where an "else if" should be. Without this, any device configured as
XI_TOUCHPAD or XI_TABLET will end up having the type_name reset to
either XI_TOUCHSCREEN or XI_MOUSE.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Messages of type X_NONE are just passed down to the log files, everything else
gets the (EE) or (II) prefixed. Since this mallocs, we can't use it in the
signal handler.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This shouldn't really be part of the driver source, it's better to just have
it as a separate repository. Code has moved to
git://people.freedesktop.org/~whot/testdevices.git
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Remember whether ABS_X or ABS_Y were reported before the SYN event and only
update the old_vals[0, 1] if we got data for them.
Touchpads that reported pressure data before x/y would otherwise update
old_x/y with bogus values, leading to jumps when the first x/y coordinates
were actually reported.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Touchpads have pressure or touch and also BTN_TOOL_FINGER.
Touchscreens have either pressure or touch, but no finger.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Letting the server deal with key repeats is fine if we have server 1.6. For
earlier servers, we need to pass on the repeat events (except for modifier
keys).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Marty Jack <martyj19@comcast.net>
* Permission to use, copy, modify, distribute, and sell this software
* and its documentation for any purpose is hereby granted without
* fee, provided that the above copyright notice appear in all copies
* and that both that copyright notice and this permission notice
* appear in supporting documentation, and that the name of Red Hat
* not be used in advertising or publicity pertaining to distribution
* of the software without specific, written prior permission. Red
* Hat makes no representations about the suitability of this software
* for any purpose. It is provided "as is" without express or implied
* warranty.
*
* THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
* NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
* OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
* NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*
* Authors:
* Peter Hutterer (peter.hutterer@redhat.com)
*/
#ifndef _EVDEV_TEST_H
#define _EVDEV_TEST_H
#include<linux/uinput.h>
structtest_device{
char*name;/* device name */
/**
* Called to setup the device. Call ioctls to set your EVBITs, KEYBITs,
* etc. here. Return 0 on success or non-zero to exit.
*/
int(*setup)(structuinput_user_dev*dev,intfd);
/**
* Called during each run of the main loop. Generate events by calling
* move(), click(), etc.
* Return 0 on success, or non-zero to stop the main loop.
*/
int(*run)(intfd);
};
externvoidmove(intfd,intx,inty);
externvoidabsmove(intfd,intx,inty);
externvoidclick(intfd,intbtn,intdown);
#endif
Reference in New Issue
Block a user
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.
