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>
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 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>
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>
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>
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>
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.
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.
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.
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>
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.
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>
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.
