The evdev driver wasn't using the select mask arguments, so this
change just involves adjusting the argument lists.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Use input_lock/input_unlock calls instead of SIGIO functions
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This broke in d24431a186 Restore wheel emulation for absolute devices,
last hunk when the valuator update was moved to before any early exit
condition. But that new update only applies to valuator maps < 2, i.e. x/y
only. Other valuators are now ignored and remain on 0 forever.
Restore the valuator update.
https://bugs.freedesktop.org/show_bug.cgi?id=95315
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We go up to BTN_JOYSTICK, hence group can have a value of up to including 15.
The actual btn_labels only has 6 elements though.
Found by coverity.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The idea was that of a direction lock: as we move vertically we should not
build up any horizontal scroll motion even if we move slightly diagonally.
The effect was though that the axis would be reset completely as soon as an
event from the other axis occured. With the default threshold of 10, if one in
ten events was a REL_X, we'd never get a wheel event.
Drop this code, it's not needed. By default wheel emulation doesn't do
horizontal scrolling, if a config snippet sets XAxisMapping the user wants
horizontal scrolling. And since we just add the value anyway, as long as the
user does a roughly vertical motion we won't get over the threshold anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=93617
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Wheel emulation relies on oldVals, which stopped updating in 3dcf6f123c.
Since wheel emulation may filter the abs event, store the event before we do
anything with it. If we really want the abs_event, abs_queued will be set to
1, otherwise the value will be ignored.
And now that we know abs_value is always valied, we can copy its value into
old_vals, so that wheel emulation can calculate the delta correctly.
https://bugs.freedesktop.org/show_bug.cgi?id=93617
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
First, it's not actually inertia, it's simply the scroll distance, yay for the
misnomer.
And it needs to be set for any device that is more fine-grained than a
mouse, especially absolute devices. For example the VirtualBox device has an
abs max of 32767, so a simple motion may have a delta of to 2000 units and
that results in 200 scroll events. That's a bit excessive.
Related to: https://bugs.freedesktop.org/show_bug.cgi?id=93617
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Logitech G600 has one device with all axes north of ABS_MISC. The current
code assigns ABS_MISC as first axis to map to axis 0, i.e. x. On button press,
one node sends the BTN_LEFT but the other node sends an ABS_MISC with a 1 0
value. ABS_MISC is mapped to axis 0, this moves the pointer to (0, y) on
every button click.
Avoid this by simply mapping any axis other than x/y to at least axis 3, and
make sure we only override the MT 0/1 axes when we actually have MT axes.
https://bugs.freedesktop.org/show_bug.cgi?id=92856
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
It can be used to scale the resolution of a mouse to that of a 1000 DPI
mouse. This can be useful to make high resolution mice less sensitive
without turning off acceleration. The target of 1000 DPI is used as the
same default is used in libinput. If the option is not set no scaling
will be done.
https://bugs.freedesktop.org/show_bug.cgi?id=88134
Signed-off-by: Thomas Hindoe Paaboel Andersen <phomes@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Just use the server defaults instead. This has very little effect, on most
systems there was some sort of default configuration applied anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When in EVDEV_RELATIVE_MODE, after converting the absolute valuators, the
code unsets pEvdev->abs_queued. This is wrong if there are some absolute
valuators which are not positions, such as a pressure valuators, because
events on these valuators would be lost.
This patch fixes the problem by doing the absolute->relative translation
early. This way, abs_queued is not set and then unset when receiving
absolute valuators representing positions. Other absolute events now set abs_queued
and will be processed.
Signed-off-by: Éric Brunet <Eric.Brunet@lps.ens.fr>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When not in EVDEV_RELATIVE_MODE, absolute position is stored in old_vals. This serves
no purpose except that old_vals is ready when the device is switched to
EVDEV_RELATIVE_MODE. It is however better to make the copy between old_vals
and abs_vals at the time of the switch rather than all the time.
Signed-off-by: Éric Brunet <Eric.Brunet@lps.ens.fr>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When not in_proximity, we don't really trust data, even though a valuator
sent just before a in_proximity event might actually be important. The
present code for EVDEV_RELATIVE_MODE throws away all data if not
in_proximity, which is a little bit too much. This patch allows for
relative values to be calculated and old_vals to be updated even if not
in_proximity, but will prevent evdev to sending (presumably) wrong
information to the X server. But at least, old_vals will be correctly
filled when the device comes into proximity again.
Signed-off-by: Éric Brunet <Eric.Brunet@lps.ens.fr>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that relative events have their own valuator mask, use it instead of
delta
Signed-off-by: Éric Brunet <Eric.Brunet@lps.ens.fr>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The functions EvdevPostProximityEvents, EvdevPostRelativeMotionEvents,
EvdevPostAbsoluteMotionEvents and EvdevPostQueuedEvents are only called
by EvdevProcessSyncEvent. These functions take as arguments an array of
valuators which is set by EvdevProcessSyncEvent to contain ... nothing.
This patch changes the prototype of the four functions, their definitions
and the way they are called to remove the useless array of valuators.
Signed-off-by: Éric Brunet <Eric.Brunet@lps.ens.fr>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In the current code, if only IgnoreRelativeAxes is set, the code would go on
and force absolute axes to initialize even if the relative axes were
successfully initialized.
Evdev gives precedence to relative axes anyway, initializing absolute axes if
the relative axes failed. Thus, if we explicitely want relative axes but leave
the abs axes as-is, proceed as normal.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Xen Virtual Pointer device has ABS_X, ABS_Y and REL_WHEEL. If smooth
scrolling is detected, the current code would first initialize relative axes
for scrolling and immediately overwrite those axes when the abs valuators are
written out.
This patch fixes the default case only, in the case of a device setting the
two Ignore*Axis options both to "off", the axes are still overwritten. The
wheels will work, other axes only if the same number of abs axes exists. And
it keeps the current memory leak too, but it's marked with a FIXME now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previous approach only had the slot state for the current slot. If we
changed slots, that means we lost the information if the slot was ever
initialized. If the ABS_MT_TRACKING_ID was never received, the slot would
still update and try to send events (which the server refused with a warning).
Avoid this by having a per-slot state and a dirty bit that tells us if the
current slot updated at all. If we don't get the tracking ID, leave the slot
empty and refuse any further events from that touch.
This quashes the various "unable to find touch point 0" warnings caused if a
touchpoint starts before the device is enabled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Walter Harms <wharms@bfs.de>
EvdevAddDevice/EvdevRemoveDevice keep a reference to the device to detect
duplicate devices based on the dev_t.
EvdevAddDevices was called during PreInit, EvdevRemoveDevice was called during
DEVICE_CLOSE. That makes it imbalanced if the device succeeds PreInit but the
server skips everything else because MAX_DEVICES is exceeded. So for all
devices after MAX_DEVICES, we'd add a reference but never remove it,
eventually reading/writing past evdev_devices.
The server keeps the list of devices for us anyway, so remove the copy of all
the pointers and instead run through the device list the server gives us.
X.Org Bug 78309 <http://bugs.freedesktop.org/show_bug.cgi?id=78309>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This was the original behavior introduced in
f77410e1f9 and stayed that way until smooth
scrolling erroneously added it as vertical axis in
b450efdf95. Revert to horizontal scrolling to
restore the previous behaviour - which unbreaks scrolling on Microsoft mice.
This effectively reverts 54a3120e33 too.
X.Org Bug 73105 <http://bugs.freedesktop.org/show_bug.cgi?id=73105>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
wheel emulation, for some reasons beyond time, got the value from
pEvdev->vals, then set the value back into pEvdev->vals. Alas, that value is
always 0, hence oldValue is zero and the delta is nil.
If we're not in relative (touchpad) mode, store the current value in
old_vals, so they're retrievable for the next event.
X.Org Bug 68415 <http://bugs.freedesktop.org/show_bug.cgi?id=68415>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A new property "Evdev Scrolling Distance" is created that holds three values
(vertical, horizontal and dial).
Signed-off-by: Peter De Wachter <pdewacht@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This patch creates three new xorg.conf options, VertScrollDelta,
HorizScrollDelta and DialDelta, which adjust the sensitivity of
smooth scrolling. These options take a positive integer, default
value is 1.
Signed-off-by: Peter De Wachter <pdewacht@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Removes the need to ioctl manually and check bits, with all the dangers that
come with that. libevdev is much better prepared for invalid values, OOB
checks, etc.
Plus, we get almost free SYN_DROPPED handling as well which we didn't have
before.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This comment is now in the wrong place. It was moved when abs support for
wheel emulation was added but is now only confusing. Remove it altogether,
the code is quite obvious what it does.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a device has ABS_MT_SLOT, mtdev merely reads the events and returns them
to the caller as-is. For this we don't need mtdev, we can just handle those
events ourselves.
This patch switches to the mtdev plumbing layer that takes events and
converts them instead of reading them off the fd.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When writing LED values to the device, append a SYN_REPORT to the list to
ensure other clients are updated immediately. Otherwise, the LED events
will be queued and not sent to other clients until the next input event
arrives.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
As of xkeyboard-config 1.9, the evdev model is hidden (c887d2876)
The server switched to pc105 with version 1.8 (1df4bd601).
The evdev model resolves to pc104 anyway, so this commit has no real effect
other than to switch from a catch-all rule to explicit.
Use pc104 so this is easy to find for those investigating the code and
wondering why. pc104 is the 'correct' geometry for the us layout, which is
the default after all. Switching to pc105 would show keys missing if no
model is set (e.g. on uk/de layouts) but it would be the wrong layout for
the default.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
The kernel should give us ABS_X/Y for backwards compat but some devices
don't. For now, ignore these devices as evdev is not suited to handle this
yet and will crash if a device is set up without axes (i.e.
pEvdev->vals == NULL) and later receives an event from an MT axis.
X.Org Bug 64029 <http://bugs.freedesktop.org/show_bug.cgi?id=64029>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
evdev tries to assign the right XI 1.x type-name based on various device
capabilities. In some cases, that fails. e.g. the Mionix Naos 5000 mouse
looks like a keyboard. And we assign a keyboard type in that case since
there are plenty of keyboards that also advertise some axes or others.
Add a new option TypeName to allow for system-wide configuration of such
devices in a quirks file.
This can also be used to address #55867
X.Org Bug 62831 <http://bugs.freedesktop.org/show_bug.cgi?id=62831>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
FALSE == Success, so if we fail during EvdevOpenMTDev, the caller thinks
that everything worked fine, proceeds to set up the fd, etc.
This may later cause a crash, when a device comes back later as different
device and posts axis events where we didn't configure axes in the first
place.
Note: Unclear why there was no udev event received for the device being
removed and coming back as different device though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes regression introduced in 2f67509b53.
If evdev is used for touchpads, the abs axis movement is converted to a rel
movement. Without the two relative axes initialized, the events are
discarded.
Axes 0 and 1 are always x/y anyway unless specifically configured otherwise.
X.Org Bug 59784 <http://bugs.freedesktop.org/show_bug.cgi?id=59784>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This will enable a device to have relative scrolling axes in addition to
absolute axes (required by the QEMU tablet).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We expect at least BTN_TOUCH for anything with MT axes, but devices that
don't have that need a button class regardless. Some gamepads define
MT axes but no buttons, causing a bug in the server when they post a
TouchBegin.
[ 97436.293] (EE) BUG: triggered 'if (!b || !v)'
[ 97436.293] (EE) BUG: exevents.c:929 in UpdateDeviceState()
So, ignore it, if it is a joystick (e. g. if it have BTN_JOYSTICK defined).
Otherwise, fake a button.
This patch basically merges two patches written by Peter Hutterer
<peter.hutterer@who-t.net>.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This isn't actually needed at all.
xf86nameCompare() will skip over underscores and is case-independent. So
xf86SetStrOption("foo_bar") will return an Option "FooBar" and vice versa.
The server won't return a zero-length string either, it'll return
NULL and spit a warning to the log.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If stat fails while checking if the device is virtual, just say "no, it's
not virtual" and continue. If the device really went away, it'll be removed
through other means.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes /usr/bin/Xorg: symbol lookup error:
/usr/lib64/xorg/modules/input/evdev_drv.so: undefined symbol: udev_new
This doesn't appear in the default configuration as Xorg links against
libudev and the symbol is defined when evdev is loaded. It can be reproduced
with a HAL-enabled server.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
This is signal handler code and we cannot clean up properly while in the
signal handler. So reduce the code to removing the signal handler and let
the device be cleaned up later.
If hotplugging is on, the server will remove it when the config backend says
so and if it is off, the server will remove it on shutdown.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
mtdev uses a chunk of memory per device (~41kB), mainly for for its
internal event buffers. The average box these days can easily have 10
devices, but only few of those are multitouch. So check if we have
ABS_MT_POSITION axes and only create an mtdev instance if we do.
If a device has multitouch axes but not x/y, we will ignore events from this
device now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
==16557== 388,240 (3,520 direct, 384,720 indirect) bytes in 10 blocks are definitely lost in loss record 1,669 of 1,671
==16557== at 0x4A06F18: calloc (vg_replace_malloc.c:566)
==16557== by 0xC3EAD4D: mtdev_new (core.c:345)
==16557== by 0xC3EAE6B: mtdev_new_open (core.c:383)
==16557== by 0xC1E0452: EvdevOpenDevice (evdev.c:2365)
==16557== by 0xC1E068C: EvdevPreInit (evdev.c:2431)
==16557== by 0x4B8304: xf86NewInputDevice (xf86Xinput.c:846)
==16557== by 0x4B8857: NewInputDeviceRequest (xf86Xinput.c:989)
==16557== by 0x4CCB4C: device_added (udev.c:211)
==16557== by 0x4CCFA6: config_udev_init (udev.c:342)
==16557== by 0x4CBE81: config_init (config.c:48)
==16557== by 0x4A8A9A: InitInput (xf86Init.c:918)
==16557== by 0x4921EE: main (main.c:258)
After PreInit, the fd and mtdev pointer are still valid. We check for the
fd, but unconditionally allocated another mtdev struct for each device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Add a new EvdevCloseDevice() function to unify this.
We used to leak data
- PreInit allocates mtdev, but nothing except one error path released it.
- each DEVICE_ON re-allocates mtdev but it is never released
Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Fixes:
evdev.c: In function 'EvdevInitButtonMapping':
evdev.c:1659:25: warning: initialization discards 'const' qualifier from
pointer target type [enabled by default]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
The axis label property array currently only has enough elements for the
non-multitouch axes. This change allocates enough space for all axes,
which prevents an array overrun write. This may manifest as stack
corruption on some platforms.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Protocol B devices report the number of touches by giving a maximum and
minimum slot value. The current code ignores the minimum value, which is
usually 0, and underreports the number of touches by 1.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some keyboards export scroll axes and any absolute axis possible in 11
dimensions. All these axes are mute, except possibly for the scroll wheels.
So if a device has a scroll axis, and we're configuring it as mouse, force
the x/y axes into existence. This stops the logspam complaining about not
enough axes on pointer movement after a xrandr change.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
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.
