Age | Commit message (Collapse) | Author |
|
First let's move the source and header files to a seperate source directory.
The structure of the new directory layout will be similar to xf86-input-evdev.
|
|
|
|
Instead of locking indefinitely, dragging is realeased after a
timeout. By default I've set it to 5 seconds to minimize changes to
previous configurations. For me a value of 450ms works best.
New Parameter: LockedDragTimeout
|
|
To observe the behavior: move with 1 finger. During movement add a 2nd
finger. If the touchpad supports it then the driver switches
seamlessly to scroll mode. Worked on the Macbook touchpad, but failed
on some Dell touchpad.
|
|
resolution of input devices. The included patch uses this to set the
defaults for various parameters. As a result, synaptics, alps and
appletouch pads all work approximately identically without requiring
model-specific configuration. The defaults should be almost identical to
the current defaults on synaptics pads. We've shipped this code in the
current Ubuntu release (7.04) without any known user issues. This is
against current git.
|
|
device for exclusive use.
|
|
the number of packets per second the touchpad generates.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A new parameter, EmulateTwoFingerMinZ, makes the driver emulate
2-finger scrolling (and tapping) when the finger pressure is big
enough. This is no real multi-finger detection (the ALPS hardware
can't do that), but seems to work quite well in practice.
From Ingmar Ellenberger.
|
|
|
|
|
|
Initial patch from VMiklos <vmiklos@frugalware.org>. Somewhat
modified by me.
|
|
This patch adds a new parameter - "SingleTapTimeout" - to control the
"2A -> SINGLETAP" transition.
This gives greater control of tap behavior. For exmple, it is possible
to disable tap-and-drag by setting the parameter to 0.
|
|
|
|
to behave as if the invalid value had been set from synclient.
|
|
|
|
Patch from Stefan Bethge <stefan@lanpartei.de>, somewhat modified by
me.
|
|
|
|
Stéphane Rosi <steph@via.ecp.fr>, somewhat modified by me.
|
|
the finger left the lower right corner if the scrolling was started
from within that corner. The problem was that in that case both
horizontal and vertical scrolling was enabled at the same time until
the finger left the corner. When the finger left the corner, one of the
scrolling directions was supposed to stop, but buggy handling of
coasting made both scrolling directions stop.
Reported by Arie Huijzer <aries.huijzer@gmail.com>.
|
|
segment. Suggested by Stefan Kombrink <katakombi@gmail.com> for use in
ksynaptics.
|
|
from Karl Tomlinson <k.tomlinson@auckland.ac.nz>, who writes:
There are two issues that are resolved here:
1 The call to xf86ReplaceStrOption in DeviceOn, when the device
file can no longer be opened seems unnecessary and causes
problems. If Protocol is auto-dev then Device is reset anyway
(through SetDeviceAndProtocol). If Protocol is something else
then the device file will never be found even after it is
recreated because Device is never set again.
2 The first xf86OpenSerial in DeviceOn may successfully open a
different mouse (or other event file) that has the same name as
the Device found through the first invocation of auto-dev. It
seems reasonable that if auto-dev is used to find the device
file the first time, then it can be used to find it again after
the device has been closed (and possibly changed name).
|
|
work correctly on 64 bit machines.
|
|
1. From inside X ran "rmmod psmouse"
2. Switched to the console
3. Switched back to X
4. Ran "modprobe psmouse"
5. Switched to the console.
6. Switched back to X.
After this sequence, the device name was set to an event device but the
protocol was psaux. The problem was that when the auto-redetection
failed in step 3, the protocol was set to psaux but the device name was
not cleared. In step 6, opening the old event device succeeded again,
so SetDeviceAndProtocol() was not called, and the protocol remained set
to psaux.
|
|
UpDownScrollRepeat, LeftRightScrollRepeat and ScrollButtonRepeat to
control the auto-repeat behavior of the scroll buttons.
From Sam Barnett-Cormack <sdb@geekworld.co.uk> with some small changes
by me.
|
|
fails, try to auto-detect the correct event device again. This can fix
problems which occurs after a suspend/resume cycle or after
rmmod/insmod-ing the psmouse kernel driver.
|
|
disable scrolling
whenever tapping is disabled. It doesn't make any sense to disable
tapping but not scrolling as a response to keyboard activity.
|
|
|
|
finger pressure is below finger_high. Some touchpads (for example, the
one found on HP Pavilion 2028) reports an unreliable finger count when
the finger pressure is very low.
Reported by Cleber Goncalves <cl3b34@yahoo.com.br>.
|
|
|
|
manual scrolling into account. This eliminates a small delay before the
first generated coasting scroll event.
|
|
continue scrolling with the same speed in the same direction when the
finger leaves the touchpad.
|
|
|
|
|
|
7c06552920a09c89f986102ec60869d3dbcb0274) in edge motion
speed calculations that made the speed approximately twice as big as
intended. Updated suggested parameter settings accordingly.
|
|
setting VertScrollDelta, HorizScrollDelta or CircScrollDelta to 0 while
the touchpad was scrolling.
|
|
touchpad. Will be needed to implement coasting.
|
|
7c06552920a09c89f986102ec60869d3dbcb0274.
|
|
calculations. This fix will slow down the pointer movements, so to
regain the same speed as before, the MinSpeed, MaxSpeed and AccelFactor
parameters should be multiplied by 1.5.
|
|
more logical.
|
|
smoothly switching from "horizontal" to "horizontal circular" when the
finger enters the lower left or lower right corners during horizontal
scrolling. See also change eeb40cac2b2dfa411618f2ecbffedc85166e675f.
|
|
pointer motion. The derivative estimate is now based on linear
regression from the last four x/y values instead of the last three.
This means that white noise is amplified by a factor of sqrt(.2)
instead of sqrt(.5), ie the factor of improvement is 1.58. Similar
improvements have been observed in data from a real synaptics
touchpad.
Also, the computations are performed in floating point math to avoid
round off errors for very slow finger movements.
|
|
on the MinSpeed, MaxSpeed and AccelFactor parameters, and it doesn't
depend on the packet rate from the touchpad hardware.
The EdgeMotionMinSpeed and EdgeMotionMaxSpeed parameters may have to be
modified to get the same speed as before this change.
|
|
|