Use new pkg-config name and variable for retrieving the input
driver installation directory.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using the new driver build actions in X11Libre/actions-build-driver repo,
instead of having lots of duplicated pipeline and script in all the
individual driver repos.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Nothing's compiling against this driver, so it shouldn't install
header files. If these constants are considered a public spec,
then they should go to some appropriate proto package.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Nothing's ever trying to compile against the driver, so no
pkgconfig descriptor needed here.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The module directory has changed to a per ABI folder in the xlibre-xserver.
Now the default value of `xorg-module-dir` will be detected from the `moduledir` variable in xorg-server.pc.
Signed-off-by: b-aaz <b-aazbsd.proton.me>
This pipeline builds the driver against the latest Xserver stable
release as well as current master.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add the following forms for issue creation:
* Bug report
* Feature request
* Code change
* Documentation update
* Organizational task
* add issue type selection page on "New Issue" call
* mention Github Discussions and the mailing list where appropriate
Part-of: X11Libre/misc#156
Signed-off-by: callmetango <callmetango@users.noreply.github.com>
This kernel had been released 1.5 decades ago - probably no need to have
special quirks for such an ancient kernel version anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Invoking xf86PostProximityEvent with no valuators does nothing, so we
have to provide a valid valuator set to the call.
https://bugs.freedesktop.org/show_bug.cgi?id=104562
[whot: slight change from 104562
abs_vals is reset on every frame but old_vals is kept around to remember the
last value of the valuator (and is updated to the current values before
processing the frame). We expect the prox in to have x/y, so let's just
unconditionally use old_vals for proximity events.]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Wacom tablets send a farewell reset to 0 on all axes when the tool goes out of
proximity. Ignore those so we can rely on our various valuator masks always
having the correct coordinates.
Possible false positive if you manage to go out of proximity right above the
zero datum but meh.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When transforming 'only buttons' device into a pseudo-mouse by adding
relative X and Y axes, EVDEV_RELATIVE_EVENTS flag must be set on device,
otherwise it gets classified as a keyboard by X11.
https://bugs.freedesktop.org/show_bug.cgi?id=104630
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Updating abs_vals for touch events since d24431a186
leads to posting Motion events with updated coordinates to the X server,
which in turn resends them to clients.
Don't queue Motion events for touch events, the X server should
synthesize them itself.
Signed-off-by: Alexander Volkov <a.volkov@rusbitech.ru>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Sometimes it may be desirable to remap physical middle button
to something else and use emulation instead. The emulation is
however hardcoded to emulate physical button 2, so the emulated
button gets remapped together with the physical one. This patch
adds the Emulate3Button configuration option to allow for user
selection of the emulated button number and a configuration
like this:
Section "InputClass"
Identifier "Middle button emulation config"
MatchProduct ".... some device ..."
MatchDriver "evdev"
Option "Emulate3Buttons" "on"
Option "Emulate3Button" "9"
EndSection
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
5c5b2c8db8 added forced x/y axes if a device
has any axes of the same mode. This was too broad a brush, some devices have
a relative wheel but absolute x/y axes and would now get misdetected as
purely relative device.
Only force relative axes if a device no rel x/y _and_ no abs x/y.
Reproducible: virtual machine with QEMU USB Tablet will stop working
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Evdev is a 100% stateful protocol. The following represents three
touches. Two touches begin and end at the same time at (500, 500) and
(1000, 1000). The third touch begins after the first two end, and is at
(500, 500).
ABS_MT_SLOT 0 /* Set touch slot */
ABS_MT_TRACKING_ID 0 /* New touch with ID 0 in slot 0 */
ABS_MT_POSITION_X 500 /* Initial X position */
ABS_MT_POSITION_Y 500 /* Initial Y position */
ABS_MT_SLOT 1 /* Set touch slot */
ABS_MT_TRACKING_ID 1 /* New touch with ID 1 in slot 1 */
ABS_MT_POSITION_X 1000 /* Initial X position */
ABS_MT_POSITION_Y 1000 /* Initial Y position */
SYNC /* End of frame */
ABS_MT_SLOT 0 /* Go back to slot 0 */
ABS_MT_TRACKING_ID -1 /* Touch in slot 0 ended */
ABS_MT_SLOT 1 /* Go to slot 1 */
ABS_MT_TRACKING_ID -1 /* Touch in slot 1 ended */
SYNC /* End of frame */
ABS_MT_SLOT 0 /* Go back to slot 0 */
ABS_MT_TRACKING_ID 2 /* New touch in slot 0 with ID 2 */
SYNC /* End of frame */
ABS_MT_TRACKING_ID -1 /* Touch in last slot (0) ended */
SYNC /* End of frame */
Note that touch 2 has the same X and Y position as touch 0. This is
implied because no new value was emitted for slot 0. In fact, Linux will
not emit an event in the same slot with the same event type and code
unless the value has changed. Thus, we can only assume that all the MT
valuators have the same values as they were when they were last sent for
the given slot.
This change adds an array of valuator mask to hold all the last valuator
values that came from evdev for each slot. When a new touch begins, all
the last values are copied into it.
This patch assumes initial axis values of 0 in each slot. Linux and
mtdev do not provide a facility to query the current values of axes in
each slot yet. This may cause spurious incorrect touch valuator values
at the beginning of an X session, but there's nothing we can do about it
right now.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a device has both relative and absolute axes, we'd initialise the
relative axes but label them with the absolute labels.
The current code is broken for mixed mode devices. Most of these devices
operate primarily in relative mode, but have some absolute axes available
for secondary functionality. For now, label the relative axes properly. We
can fix the absolute axes later.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Too much in the server relies on x/y to exist and to be axes 0 and 1. So if
any relative axes exist, initialize REL_X/Y or ABS_X/Y as well.
For servers up to 1.11: a scrollwheel-only device now has relative axes
where it only had buttons before.
For servers 1.12 or later: the device now has x/y in addition to the scroll
axes.
X.Org Bug 44655 <http://bugs.freedesktop.org/show_bug.cgi?id=44655>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
If we don't know the resolution, set it to 0. This is invalid, and tells
the X client that we don't know the resolution, rather than reporting an
incorrect value.
This value was originally from commit
6271494faa, which is the initial commit
from Adam Jackson adding absolute axis support.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Added in 683a55e504 due to a botched up
rebase -i. The contents of udev.c and EvdevIsVirtual are identical, there is
no need for an extra file for this one function.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In 683a55e504, a dependency on libudev was
added, but documented in configure.ac as a dependency on udev (which
also happens to ship a pkg-config file).
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Remove the ABI check hack, just check for the server version directly now
that we have one that definitely has the multitouch APIs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we spot inputproto 2.1.99.3, we assume we have a capable X server. This
should really be a server version check, but the server version hasn't been
bumped yet.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Even if MT support isn't available, include it in the build. The checks in
the code check whether mt_mask is non-NULL but they would all need ifdef
escaping otherwise.
Leave the mtdev part inside the ifdef however, so that we don't need the
mtdev header if we don't build with multitouch.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The kernel exports both ABS_X and ABS_MT_POSITION_X (and a couple others)
for a multi-touch capable device. For such devices, only count the axis once
since we submit ABS_MT_POSITION_X through ABS_X.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The kernel exports a bunch of information as axis that shouldn't be an axis
and we don't treat it as axis in the server. Add this helper instead of
checking for the axis codes manually.
No function change.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
MT axes are the same as traditional axes, so one into the other so we get
x/y coordinates regardless wich axes it comes from.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
After we swap the axes, we only call valuator_mask_set for axes that are
not zero, so we need to unset the axes that became zero when swapped.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We were correctly swapping the valuator values, but we were not
calling valuator_mask_unset() when needed, so the cursor kept jumping
to the edges.
This patch does the swapping before the main "for", so we don't need to
store unswapped_{x,y} and unswapped_isset_{x,y} even when we don't need
to swap.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No real effect on the code, but it helps to have that line in the log when
searching for driver issues.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ABS_MT_SLOT comes before any other events. The following order of events
is common for protocol B devices (and mtdev):
...
EV_SYN
ABS_MT_SLOT → posting here means we miss on the position information
ABS_MT_POSITION_X
ABS_MT_POSITION_Y
ABS_MT_SLOT
ABS_MT_POSITION_X
ABS_MT_POSITION_Y
EV_SYN
Store the stot state as SLOT_EMPTY after posting an event (i.e. EV_SYN and
ABS_MT_SLOT) and then don't post until the next slot/syn event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Without this change, an MT touchpad in relative mode could end a touch
while not resetting the oldMask used to calculate relative values. This
fix allows a Magic Trackpad to behave as a relative mode device again.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
MTDev translates all multitouch devices to the slotted evdev protocol.
This provides a clean and uniform interface and reduces message handling
inside the input module and X.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
This multitouch addition only supports slotted MT evdev protocol
devices. Support must be enabled at configure time using
--enable-multitouch.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Amendments: XI_TouchMotion -> XI_TouchUpdate, rename mtMask to mt_mask
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Use udev to check for the device's sysfs path, if it contains LNXSYSTM it's
a kernel-emulated device. This property can then be used to determine if
there are any real devices connected, allowing the desktop environment to
e.g. turn off the touchpad whenever there's a mouse attached.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Bad conflict resolution in xf86-input-evdev-2.6.0-30-g745fca0
Reported-by: Sebastian Glita <glseba@yahoo.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Automatic smooth scrolling setup for these axes, with REL_WHEEL and REL_DIAL
both mapping into vscrolling. REL_WHEEL is the preferred axis.
Mouse wheel emulation is not yet updated for smooth scrolling.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
We can't use BitIsSet/SetBit from the server (inputstr.h) since they
operate on byte arrays. EvdevSetBit is added in preparation for the
"smooth-scrolling on wheel emulation" patch.
Signed-off-by: Max Schwarz <Max@x-quadraht.de>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
evdev.c: In function 'EvdevInitAxesLabels':
evdev.c:2192:11: warning: variable 'misc_label' set but not used
[-Wunused-but-set-variable]
obsolete with 880ad1e19a
emuWheel.c: In function 'EvdevWheelEmuPreInit':
emuWheel.c:252:10: warning: variable 'val' set but not used
[-Wunused-but-set-variable]
obsolete with b0737bdbd1
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
We require ABI 12.2 in the driver, enforce it through pkg-config.
Technically ABI 12.2 is first available in 1.9.99.902 but 1.10 looks so much
nicer.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
There is currently no mapping between XI devices and physical devices other
than what can be extracted by parsing the Xorg logfile. Add new property
"Device Node" to the driver to export the open device file.
Server 1.11 and later standardises on this property name.
The client is responsible for detecting if the device is on the same host
and converting the data into a more useful format (e.g. sysfs path).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some touchscreens (like the Lumio crystaltouch in single touch mode) send
BTN_LEFT rather than BTN_TOUCH:
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x202e product 0x5 version 0x111
Input device name: "LUMIO Inc LUMIO CrystalTouch ver 1.1C"
Supported events:
Event type 0 (Sync)
Event type 1 (Key)
Event code 272 (LeftBtn)
Event code 273 (RightBtn)
Event code 274 (MiddleBtn)
Event type 2 (Relative)
Event code 9 (Misc)
Event type 3 (Absolute)
Event code 0 (X)
Value 650
Min 0
Max 4095
Event code 1 (Y)
Value 3221
Min 0
Max 4095
Event type 4 (Misc)
Event code 4 (ScanCode)
Testing ... (interrupt to exit)
Event: time 1305882024.934011, type 4 (Misc), code 4 (ScanCode), value 90001
Event: time 1305882024.934017, type 1 (Key), code 272 (LeftBtn), value 1
Event: time 1305882024.934029, type 3 (Absolute), code 0 (X), value 270
Event: time 1305882024.934034, type 3 (Absolute), code 1 (Y), value 1513
Event: time 1305882024.934039, type 2 (Relative), code 9 (Misc), value 1
This causes evdev to handle these device as a mouse rather than a
touchscreen, which naturally doesn't work very well. We already internally
translate BTN_TOUCH as BTN_LEFT, so accept this kind of devices as
touchscreens by checking for devices with BTN_LEFT, absolute X/Y and NO
relative X/Y axes.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On some keyboards, the multimedia function keys are overlaid with the F
keys. This property enables clients to switch the primary mode of these F
keys between function keys and multimedia keys.
Some keyboards provide an Fn key to toggle between the modes. This is
hardware-specific and may or may not work on any given keyboard device.
The current imlementation is only hooked up to apple keyboards.
The kernel provides a tweak to enable/disable.
/sys/module/hid_apple/parameters/fnmode
0 .. keyboard sends Fx keys, Fn disabled
1 .. keyboard sends multimedia keys, Fn toggles to function keys
2 .. keyboard sends function keys, Fn toggles to multimedia keys
If fnmode is on 0, we force it to 2.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Otherwise, an event that causes us to go into proximity with some new
valuator values will retain some old valuator values from when last in
proximity. This change ensures that all values posted while out of
proximity are accounted for.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current code overwrites *all* the stored axis values with whatever
came in from evdev. Evdev is a stateful protocol, so it only sends us
updates to the axis values that have changed. We need to only update
the values that have changed.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since the mode of valuators (no longer?) bears a relation to the device class
actually initialized, this naming was quite misleading.
Signed-off-by: Simon Thum <simon.thum@gmx.de>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A warning from free() can be avoided by casting the constness away
from its argument pointer or by not declaring the pointer as const in
the first place.
Signed-off-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently the XKB options duplicated in EvdevAddKeyClass are never
released. For example, connecting and disconnecting a bluetooth
keyboard repeatedly causes a steadily growing memory leak.
Signed-off-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Reviewed-by: Erkki Seppälä <erkki.seppala@vincit.fi>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
xf86Post* takes an int for the is_absolute parameter. Since the XI protocol
spec requires Relative to be 0 and Absolute to be 1, use those instead to
make the code easier to read.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
New properties:
"Evdev Third Button Emulation" → switch on/off
"Evdev Third Button Emulation Timeout" → timeout until event is delivered
"Evdev Third Button Emulation Button" → phys button to be emulated
"Evdev Third Button Emulation Threshold" → move threshold before emulation
is cancelled
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <tissoire@cena.fr>
The latter provides a standardised message format in the form of
driver name: device name: message
making it easier to grep for driver messages in the log.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
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>
If we swap before scaling, we scale with the wrong coordinate range.
Reported by Matt Helsley.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of x/y and pressure, support any absolute axis that is reported on the
device. Note that there are still locations that special-case X and Y.
Minor modifications by Peter Hutterer.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
As can be seen in e.g. bugs 19819 & 20025, it can be unclear what
exactly caused a given "Device has changed - disabled" error. This
patch adds some more specific messages to give a better clue on what
exactly was seen to have changed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
distcheck has an annoying feature where it checks that all files install
under $prefix. Unfortunately, this conflicts with the desire to install
headers to the SDK directory. Workaround by passing --with-sdkdir during
distcheck.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Remove non toplevel .gitignore and .cvsignore files.
The "make distcheck correction" for $(sdkdir) probably has a better
approach using a "*-hook:" target, or possibly making $sdkdir a
configure time option that could be set with DISTCHECK_CONFIGURE_FLAGS.
Input devices (especially touchscreens) were disabled when switching
virtual console back to X because EvdevCacheCompare() thought the device
was substituted by another while away from X. Actually only the current
position reported by the device changed from what was in the cache. Fixed
by ignoring the current position in the comparison.
Fixes bug #19819.
Signed-off-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With the new InitKeyboardDeviceStruct, we can just pass the RMLVO we
want without setting the defaults first.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
We don't need axis calibration, etc. on keyboards, so let's do it
conditionally on actually having axes.
Reported by Simon Thum.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since we don't support anything but REL/ABS x/y and sometimes pressure this is
bordering on pointlessness, but once the year of the Linux desktop comes
around this will be really handy. Or so.
Also, we don't allow changing axis labels, but should eventually rearrange
them if swapaxis is on.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Otherwise, we add a new property based on a setting in pEvdev, which triggers
the update handler to change the setting in pEvdev based on the property.
Truly pointless.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In linux/input.h each section's (e.g. ABS) FOO_MAX is the maximum FOO
value. Recent kernels define FOO_CNT as the maximum number of FOO there
will ever be. Hence using FOO_MAX to size the bit vectors representing
the capabilities of an evdev device is off by one.
Define FOO_CNT values for use with Linux kernels which lack them. Use
FOO_CNT whenever we need to know the number of bits needed -- usually to
calculate the number of longs needed.
When iterating over the values FOO_MAX still seems appropriate however
the loop test should include FOO_MAX rather than skip it.
Signed-off-by: Matt Helsley <matt.helsley@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
NBITS really convers the number of bits passed as its argument
into a number of longs. This is somewhat atypical of many
function-like-macro names. Rename it to NLONGS.
Signed-off-by: Matt Helsley <matt.helsley@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If it's available report pressure as third valuator.
(Use xf86PostMotionEventP instead of the varargs wrapper.)
Signed-off-by: Matt Helsley <matt.helsley@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Discard all repeated events that come from the device. The server will handle
per-key autorepeat in software.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
For keyboards, scroll events are reported by the kernel as EV_REL class events
of REL_WHEEL type. If, during probing, the device is found to support wheel
events, make sure it is set up as a pointing device, even if it doesn't have
buttons or doesn't report motion along the X and Y axis so that the scroll
events can be mapped to mouse wheel buttons (usually buttons 4 and 5).
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
We handle autorepeat in software due to per-key repeat and whatnot, so
disable the kernel's, which just interferes with ours.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Devices added that use the same min/maj as an already added device are ignored
by the driver. This way users can have an xorg.conf entry on
/dev/input/by-id/blahblah and not get the same device added by HAL.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
New option: SwapAxes (boolean)
New property: EVDEV_PROP_SWAP_AXES.
Actual swapping code written by Donnie Berkholz.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Some devices require run-time axis calibration. We can't change the min/max
ranges once we've initialised the valuator structs though, so in-driver
run-time calibration is required.
If the property is set, the driver scales from the calibrated range to the
values reported to the X server (which then may scale to screen coordinates).
If the property is not set (i.e. zero items) no scaling is performed.
Three test devices provided:
btn0 .... Provides BTN_0, BTN_1, BTN_2 instead of BTN_LEFT, BTN_MIDDLE,
BTN_RIGHT.
abs ..... Provdes x/y absolute axes, jumps between 100/100 and 120/120.
absrel .. Provides relative x/y axes and absolute x/y axes at the same time.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Treat BTN_[0-2] as LMR buttons on devices that do not advertise BTN_LEFT,
BTN_MIDDLE, BTN_RIGHT (e.g. 3Dconnexion SpaceNavigator).
Otherwise, treat BTN_[0+n] as button 5+n. Note: This causes duplicate
mappings for BTN_0 + n and BTN_SIDE + n.
This also fixes a bug where we could end up with negative button numbers after
trying to map BTN_0.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
This got broken in b0737bdbd1, when the
EmuMBPreInit call was removed from EvdevOn. As a result, VT switching away and
back wouldn't restore the wakeup handlers and mouse button presses
disappeared.
Touchscreens are devices that do not have buttons and only advertise
BTN_TOUCH. Add a new flag to note the device type.
If BTN_TOUCH is detected, change it to BTN_LEFT and process it normally.
We now have the matching code in the server to set the console to RAW mode and
don't need to grab the devices anymore.
This is an updated version of e8534d47c8, which
was reverted in 6dc4199155.
If we only have keys > 255 we don't set up a key class rec, so don't post
them. It makes the server unhappy.
Signed-off-by: Julien Cristau <jcristau@debian.org>
Call the PreInit functions for MB Emulation, wheel emu, and draglock during
PreInit, not on DEVICE_INIT. This way, we only parse the options once and
don't overwrite with defaults when coming back from a VT switch.
This allows the reopen logic to kick in later.
DEVICE_CLOSE gets called on regen, so without this we'd keep a stale
file descriptor in pInfo->fd in subsequent sessions.
Debian bug#496101 (http://bugs.debian.org/496101)
Leaving the fd open means we still get keyboard events after VT switching
away. Coming back, some of these events are replayed on the application that
has the current focus.
Reproduceable:
1. open terminal, focus.
2. VT switch away
3. type something, preferably a password
4. VT switch back, trigger a mouse event
5. Observe the X server guessing your password.
Closing the fd on DEVICE_OFF fixes this. Reopen is handled by the reopen
code introduced with
commit 9930477cbe
Author: Peter Hutterer <peter.hutterer@redhat.com>
Date: Tue Aug 26 14:33:40 2008 +0930
Attempt to re-open devices on read errors.
Launchpad Bug 276887
<https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/276887>
This removes a left-over from the early device property code where we could
only have a single handler. Now it's easier to just register the handlers for
each subsystem (emulate wheel, draglock and MB emulation).
Coming back from resume may leave us with a file descriptor that can be opened
but fails on the first read (ENODEV).
In this case, try to open the device until it becomes available or until the
predefined count expires. To be safe, we cache the information from the device
and compare against it when we re-open. This way we ensure that if the
topology changes under us, we don't open a completely different device. If a
device has changed, we disable it.
Adds option "ReopenAttempts" <int>
Even if we don't want EmulateWheel, we can at least init everything to usable
values. This way we only need to toggle "enabled", rather than initialising
the whole lot before usage.
Grabbing event devices stops in-kernel event forwarding, most notably rfkill
and the "Macintosh mouse button emulation" device. Let's not do that.
Option "GrabDevice" forces grabbing the device.
The Emulate3Button needs to be the last filter function, otherwise the timeout
code causes it to hijack button presses for the first 3 buttons.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Keycodes over 255 are silently ignored in the server. The least we can do is
put a warning in the logs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Remove code duplication, let the mapping function hand us the actual button
event to be passed up to the server.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With this fix, on my PowerBook HAL hotplugging correctly detects my USB mouse,
and no longer thinks keyboards have random numbers of mouse buttons. :)
The LONG_BITS and NBITS macro definitions are stolen from xf86-input-synaptics.
Signed-off-by: Michel Dänzer <michel@tungstengraphics.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
After suspend/resume, sometimes the device doesn't come back up on the same
node. Since we do not call PreInit for the device (which would detect this
situation), we continue to try to read a nonexisting file, spamming the log
file with "Read Error".
We don't really do anything with the number other than print it since I'm sure
that half the mice don't report the correct number anyway (especially with the
wheel button mapping). But having a bit more debug info is good.
This ensures that the middle button emulation is re-enabled after VT switch,
otherwise the block handler that deals with the timeouts would not get
re-registered.
Signed-off-by: Keith Packard <keithp@keithp.com>
2008-06-21 18:14:35 -07:00
31 changed files with 5858 additions and 1155 deletions
Please fill out the sections below to help everyone identify and fix the bug. If you have a general idea or question then please use the [discussions](https://github.com/orgs/X11Libre/discussions).
- type:dropdown
id:affected-version
attributes:
label:Select the version
options:
- 2.11.0.1
- Git master branch
- other or don't know
default:1
validations:
required:true
- type:textarea
id:description
attributes:
label:Describe your issue
placeholder:When I did X then Y happened.
validations:
required:true
- type:textarea
id:steps
attributes:
label:Steps to reproduce
placeholder:|
1. Start ...
2. Do this
3. Do that
validations:
required:true
- type:textarea
id:expected
attributes:
label:What did you expect?
placeholder:I expected this to happen.
- type:textarea
id:environment
attributes:
label:Additional Information
description:|
Additional information you want to provide such as logs, system info, environment, screenshots, etc.
placeholder:|
Add any other context about the bug here.
- type:checkboxes
id:checks
attributes:
label:Extra fields
options:
- label:I have checked the existing [issues](https://github.com/X11Libre/xf86-input-evdev/issues)
required:true
- label:I have read the [Contributing Guidelines](https://github.com/X11Libre/xserver/blob/master/CONTRIBUTING.md)
required:true
- label:I'd like to work on this issue
- type:markdown
attributes:
value:|
Thanks for reporting this issue! We will get back to you as soon as possible.
Please fill out the sections below to properly describe the new software feature you are suggesting. If you have a general idea or question then please use the [discussions](https://github.com/orgs/X11Libre/discussions).
- type:textarea
id:description
attributes:
label:"Describe the feature"
placeholder:A thing in X that allows to do Y.
validations:
required:true
- type:textarea
id:rationale
attributes:
label:"It should be done because"
placeholder:Doing Y is needed for Z.
validations:
required:true
- type:textarea
id:alternative
attributes:
label:"What are the alternatives?"
placeholder:We could do A or B instead.
- type:textarea
id:context
attributes:
label:Additional context
description:Additional information you want to provide such as references to related issues or protocols, the implications on existing use cases, etc.
placeholder:|
Add any other context about the feature request here.
- type:checkboxes
id:checks
attributes:
label:Extra fields
options:
- label:I have checked the existing [issues](https://github.com/X11Libre/xf86-input-evdev/issues)
required:true
- label:I have read the [Contributing Guidelines](https://github.com/X11Libre/xserver/blob/master/CONTRIBUTING.md)
required:true
- label:I'd like to work on this issue
- type:markdown
attributes:
value:|
Thanks for your suggestion! Let's see together if it can be done.
Please fill out the sections below to properly describe the code cleanup you are suggesting. If you have a general idea or question then please use the [discussions](https://github.com/orgs/X11Libre/discussions).
- type:textarea
id:description
attributes:
label:"Describe the cleanup"
placeholder:C in X needs to be changed into D.
validations:
required:true
- type:textarea
id:rationale
attributes:
label:"It should be done because"
placeholder:Having D is needed for E.
validations:
required:true
- type:textarea
id:alternative
attributes:
label:"What are the alternatives?"
placeholder:We could do A or B instead.
- type:textarea
id:context
attributes:
label:Additional context
description:Additional information you want to provide such as implications on existing code, how to ensure API/ABI stability, which tests are needed or to be run, related issues, etc.
placeholder:|
Add any other context about the cleanup here.
- type:checkboxes
id:checks
attributes:
label:Extra fields
options:
- label:I have checked the existing [issues](https://github.com/X11Libre/xf86-input-evdev/issues)
required:true
- label:I have read the [Contributing Guidelines](https://github.com/X11Libre/xserver/blob/master/CONTRIBUTING.md)
required:true
- label:I'd like to work on this issue
- type:markdown
attributes:
value:|
Thanks for looking at the source code! Let's see together how it can be improved.
description:Make your mark for better documentation
labels:[documentation, needs-triage]
body:
- type:markdown
attributes:
value:|
Please fill out the sections below to help others understand our software. If you have a general idea or question then please use the [discussions](https://github.com/orgs/X11Libre/discussions).
- type:textarea
id:description
attributes:
label:Describe the update
placeholder:These things need to be better documented.
validations:
required:true
- type:textarea
id:environment
attributes:
label:Additional Information
description:Additional information you want to provide such as tickets related to changes in the software, affected files, screenshots, etc.
placeholder:|
Add any other context about the update here.
- type:checkboxes
id:checks
attributes:
label:Extra fields
options:
- label:I have checked the existing [issues](https://github.com/X11Libre/xf86-input-evdev/issues)
required:true
- label:I have read the [Contributing Guidelines](https://github.com/X11Libre/xserver/blob/master/CONTRIBUTING.md)
required:true
- label:I'd like to work on this issue
- type:markdown
attributes:
value:|
Thanks for requesting this update! We will get back to you as soon as possible.
description:Create a task for project organization
labels:[needs-triage, organization]
body:
- type:markdown
attributes:
value:|
Please fill out the sections below to get organizational things done. If you have a general idea or question then please use the [discussions](https://github.com/orgs/X11Libre/discussions).
- type:textarea
id:description
attributes:
label:Describe the task
placeholder:These things need to be done.
validations:
required:true
- type:textarea
id:rationale
attributes:
label:"It should be done because"
placeholder:Doing Y is needed for Z.
- type:textarea
id:environment
attributes:
label:Additional Information
description:Additional information you want to provide such as the context for bigger tasks, the implicatons on existing workflows, related issues, etc.
placeholder:|
Add any other context about the task here.
- type:checkboxes
id:checks
attributes:
label:Extra fields
options:
- label:I have checked the existing [issues](https://github.com/X11Libre/xf86-input-evdev/issues)
required:true
- label:I have read the [Contributing Guidelines](https://github.com/X11Libre/xserver/blob/master/CONTRIBUTING.md)
required:true
- label:I'd like to work on this issue
- type:markdown
attributes:
value:|
Thanks for adding this task! We will get back to you as soon as possible.
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.
