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>
(cherry picked from commit f352598e45)
None of the inputproto headers seem to be included anywhere.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 6f4634111a)
Conflicts:
configure.ac
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>
(cherry picked from commit b07ab6ea97)
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>
(cherry picked from commit 9bfd9e8a36)
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>
(cherry picked from commit 0a3657d2ee)
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>
(cherry picked from commit dc2191285e)
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>
(cherry picked from commit 255b9f6bbf)
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>
(cherry picked from commit b358f1eb3a)
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>
(cherry picked from commit 33cc112ca1)
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>
(cherry picked from commit 220e2dfb8f)
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>
(cherry picked from commit d9809d7edd)
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>
(cherry picked from commit 7ac0c4456d)
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>
(cherry picked from commit a7fb654a68)
Scrollwheel data is always posted as buttons, so we need to advertise at least
enough buttons to accommodate for 6/7 (horizontal wheel).
Note that this may mean that if you have a device that has scroll wheels and
axes, but no buttons, it may be interpreted as a mouse.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
9620fe776 added generic axes support for relativ values, but values from such
axes didn't get passed on to the server. Fix this.
Note that wheel events are not posted as motion events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
xf86WaitForInput() would call select() with zero timeout to discover if
more input was ready. But we know that's always true at least once,
since we're only ever called from the sigio handler (if silken is
active) or from the main loop (if it's not and we selected readable).
With nonblocking IO we can just spin around until we hit EAGAIN, which
gets us down to n+1 syscalls per event instead of 2n.
Necessary for builds against 1.6, but let's at least get rid of XKB defines.
This reverts commit aa5dfa1d6a.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
abs_labels[] has to be aligned with the defines in linux/input.h, but the
latter does not have continuous range. Pad the holes with
AXIS_LABEL_PROP_ABS_MISC.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
