| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
On v7 touchpads sometimes when 2 fingers are moved down on the touchpad
until they "fall of" the touchpad, the second touch will report 0 for y
(max y really since the y axis is inverted) and max x as coordinates,
rather then reporting 0, 0 as is expected for a non touching finger.
This commit detects this and treats these touches as non touching.
See the evemu-recording here:
https://bugzilla.redhat.com/attachment.cgi?id=1025058
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1221200
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Now that the generic process_bitmap function has been improved to offer
accurate coordinates for the first touch we can use it for v5 (dolphin)
touchpads too.
Besides being a nice code cleanup this also fixes the saw tooth pattern
in the coordinates for the second touch the dolphin specific version had.
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Rename alps_set_abs_params_mt to alps_set_abs_params_semi_mt,
to make it clear that it is only (to be) used for semi-mt devices.
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
With the recent process_bitmap() changes all semi-mt devices always report
the first finger down in slot 0, so stop using input-mt finger tracking
for these.
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
All alps semi-mt touchpads give us the following data when 2 (or more)
fingers are touching: 1 more or less accurate touch for the first finger
down, and a bitmap with columns and rows in which 1 or more fingers are
seen resulting in a crude (low res) bounding box.
So far for v3, rushmore and v4 touchpads we've been reporting the
coordinates of 2 opposite corners of the box when 2 fingers are touching.
Ignoring the much better resolution data given in the normal position
packet.
This commit actually uses this data for the first touch, figures out which
corner of the bounding box is closest to the first touch, and reports the
coordinates of the opposite corner for the second touch, resulting in
much better data for the first touch and for the single touch
pointer-emulation events.
This approach is similar to the one in alps_process_bitmap_dolphin, that
function takes the single accurate touch info, calculates the distance to
the center of the bounding box, and then puts the 2nd touch mirrored to
the center. The downside of that approach is that if both touches move
slowly in the same direction, the bounding box will stay the same for a
while (as it is low res) and the second touch will thus been seen moving
in the opposite direction until the bounding box actually changes, and
then the second touch snaps to its new position resulting in a saw tooth
pattern in the coordinates for the second touch, hence this new approach.
This commit fixes 2 finger scrolling being choppy / jumpy on these
touchpads.
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
We should decode the position packet before the packet with the bitmap
data. This way we can use the more accurate position info in
process_bitmap() to get better results.
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Pinnacle / Rushmore packets contain either position info, or bitmap info,
never both. So far we've in essence been storing garbage in the position /
bitmap fields of the fields struct when decoding a bitmap / pos packet.
We've been relying on the following sequence to get away with this:
1) Decode bitmap packet
2) Process bitmap packet
3) Decode position packet
4) Use position / button info
This patch allows us to change this sequence, which will allow using the
position info when processing the bitmap for more accurate results.
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Change alps_decode_rushmore to do all decoding itself, rather then relying
on alps_decode_pinnacle and then overriding some fields + or-ing in some
bits.
This is a preparation patch for modifying the decode functions to properly
differentiate between position and bitmap packets.
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Signed-off-by: Shailendra Verma <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Signed-off-by: Shailendra Verma <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Since commit 1c6c69525b40eb76de8adf039409722015927dc3 ("genirq: Reject
bogus threaded irq requests") threaded IRQs without a primary handler
need to be requested with IRQF_ONESHOT, otherwise the request will fail.
So pass the IRQF_ONESHOT flag in this case.
The semantic patch that makes this change is available
in scripts/coccinelle/misc/irqf_oneshot.cocci.
Signed-off-by: Fabio Estevam <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Since commit 1c6c69525b40eb76de8adf039409722015927dc3 ("genirq: Reject
bogus threaded irq requests") threaded IRQs without a primary handler
need to be requested with IRQF_ONESHOT, otherwise the request will fail.
So pass the IRQF_ONESHOT flag in this case.
The semantic patch that makes this change is available
in scripts/coccinelle/misc/irqf_oneshot.cocci.
Signed-off-by: Fabio Estevam <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Since commit 1c6c69525b40eb76de8adf039409722015927dc3 ("genirq: Reject
bogus threaded irq requests") threaded IRQs without a primary handler
need to be requested with IRQF_ONESHOT, otherwise the request will fail.
So pass the IRQF_ONESHOT flag in this case.
The semantic patch that makes this change is available
in scripts/coccinelle/misc/irqf_oneshot.cocci.
Signed-off-by: Fabio Estevam <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Since commit 1c6c69525b40eb76de8adf039409722015927dc3 ("genirq: Reject
bogus threaded irq requests") threaded IRQs without a primary handler
need to be requested with IRQF_ONESHOT, otherwise the request will fail.
So pass the IRQF_ONESHOT flag in this case.
The semantic patch that makes this change is available
in scripts/coccinelle/misc/irqf_oneshot.cocci.
Signed-off-by: Fabio Estevam <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
max7359_build_keycode() does the same thing as matrix_keypad_build_keymap(),
but the latter can also handle DT bindings.
Tested on beagleboard-xm.
Signed-off-by: Evgeniy A. Dushistov <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
In datasheet of max7359 there is the following description of this flag:
0 - INT cleared when FIFO empty,
1 - INT cleared after host read. In this mode, I2C should read
FIFO until interrupt condition removed, or further INT may be lost.
So, if we set this flag, we have to read FIFO until it becomes empty. But
in interrupt we read FIFO just once. This lead to "keyboard" hang until
reboot, if we press several keys, because of interrupt handler read just
one "press" from FIFO and clear interrupt.
Signed-off-by: Evgeniy A. Dushistov <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Use kvfree() instead of open-coding it.
Signed-off-by: Pekka Enberg <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
When the v3 hardware sees more than one finger, it uses the semi-mt
protocol to report the touches. However, it currently works when
num_fingers is 0, 1 or 2, but when it is 3 and above, it sends only 1
finger as if num_fingers was 1.
This confuses userspace which knows how to deal with extra fingers
when all the slots are used, but not when some are missing.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=90101
Cc: [email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Remove duplicated include for acpi.h.
Signed-off-by: Wei Yongjun <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Remove duplicated include for delay.h.
Signed-off-by: Wei Yongjun <[email protected]>
Reviewed-by: Heiko Stuebner <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
We have been testing wrong variable when trying to make sure that input
allocation succeeded.
Reported by Coverity (CID 1295918).
Acked-by: Sébastien Szymanski <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Add the TI drv2665 piezo haptic driver. This haptics IC requires the data
to be streamed to the FIFO for continuous output.
Datasheet can be found at:
http://www.ti.com/product/drv2665
Signed-off-by: Dan Murphy <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Fix spelling of magnitude
s/manginude/magnitude
Signed-off-by: Dan Murphy <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Fix the Kconfig for the drv2667 as there was a copy/paste error.
Signed-off-by: Dan Murphy <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Wait a little bit longer, 50mS instead of 20mS, until the driver starts
polling for pen-up. The problematic behavior before this patch is applied
is as follows. The behavior was observed on the STMPE610QTR controller.
Upon a physical pen-down event, the touchscreen reports one set of x-y-p
coordinates and a pen-down event. After that, the pen-up polling is
triggered and since the controller is not ready yet, the polling mistakenly
detects a pen-up event while the physical state is still such that the pen
is down on the touch surface.
The pen-up handling flushes the controller FIFO, so after that, all the
samples in the controller are discarded. The controller becomes ready
shortly after this bogus pen-up handling and does generate again a pen-down
interrupt. This time, the controller contains x-y-p samples which all read
as zero. Since pressure value is zero, this set of samples is effectively
ignored by userland.
In the end, the driver just bounces between pen-down and bogus pen-up
handling, generating no useful results. Fix this by giving the controller a
bit more time before polling it for pen-up.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Viresh Kumar <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Use msecs_to_jiffies(20) instead of plain (HZ / 50), as the former is much
more explicit about it's behavior. We want to schedule the task 20 mS from
now, so make it explicit in the code.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Viresh Kumar <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
The MSB of the first byte read via I2C at the coordinates address
indicates whether the data is valid or ready (called "buffer status" in
the datasheets) when an interrupt is raised. Previously, this bit was
ignored, which resulted in a lot of incorrect detections of "finger
removed" events.
Signed-off-by: Paul Cercueil <[email protected]>
Acked-by: Bastien Nocera <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
The event mask was specified as 0xF (4 bits) when in reality is 0x1F (5
bits) in order to be capable of representing all FIFO length values from
0 to 16.
This caused a problem: when the keypad reported 16 pending events the
driver took it as 0, and did nothing. This in turn caused the keypad to
re-issue the interrupt over and over again.
Signed-off-by: Guido Martínez <[email protected]>
Acked-by: Michael Hennerich <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
The pull mask is created by looping each row (column) and building an
8-bit integer with the configuration. It is written byte-by-byte, when
we reach the end of the rows (columns) or we're at the 3rd line (which
finishes the first byte, since each pin is 2bits on the mask).
However, this only works if we have at most 8 pins (2 bytes), which is
not the case for the ADP5589. So, write the byte at each boundary (every
4 rows/columns).
Signed-off-by: Guido Martínez <[email protected]>
Acked-by: Michael Hennerich <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Prepare second round of updates for 4.1 merge window.
|
|
My Pengutronix address is not valid anymore, redirect people to the
Pengutronix kernel team.
Reported-by: Harald Geyer <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Acked-by: Robert Schwebel <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
The suspend scan rate value should not exceed 1000, unfortunately when
implementing the limit we used max_t instead of min_t, causing the value to
be at least 1000.
Signed-off-by: Dudley Du <[email protected]>
Reviewed-by: Benson Leung <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
According to Elan's firmware engineers we should not be subtracting 1 form
the raw number of x and y traces so that the pitch size is correct. For
example, if the touchpad x resolution is 2800 and x trace number is 20,
the pitch size of x should be 2800/20 = 140, not 2800/19 = 147.36.
Signed-off-by: Duson Lin <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
When hover is detected report ABS_MT_DISTANCE as 1; for active contacts
the distance is reported as 0.
Signed-off-by: Duson Lin <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Let's zero-extend hardware id number when forming firmware file name,
to avoid kernel requesting firmware like "elants_i2c_ 0.bin", which
is quite unexpected.
Acked-by: Charlie Mooney<[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Non interleaved dualpoint v2 devices have separate pointstick button bits,
document this.
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
This change allows atmel_mxt_ts to bind to ACPI-enumerated devices in
Google Pixel 2 (2015).
While newer version of ACPI standard allow use of device-tree-like
properties in device descriptions, the version of ACPI implemented in
Google BIOS does not support them, and we have to resort to DMI data to
specify exact characteristics of the devices (touchpad vs. touchscreen,
GPIO to button mapping, etc).
Pixel 1 continues to use i2c devices and platform data created by
chromeos-laptop driver, since ACPI does not enumerate them.
Reviewed-by: Javier Martinez Canillas <[email protected]>
Tested-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
This adds rumble support for Xbox One controller by sending continuous
rumble command. Trigger button rumbling is not yet implemented.
Signed-off-by: Ming-ting Yao Wei <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Replace old pr_* with dev_* debugging macros
Signed-off-by: Oliver Neukum <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
VMMouse enables low-latency mouse-cursor-movements for VMWare and QEMU
guests. By removing the guest cursor and using the host as a guest cursor
the cursor movement appears instant although in reality there is some lag.
To be able to do this, the host's view of the cursor position must exactly
match the guest's view and an absolute pointer device is needed. Enter the
VMMouse. While the VMMouse driver has historically been an Xorg user-space
driver, implementing it as a kernel imput driver enables rootless Xorg and
new compositing display servers for VMware guests.
Signed-off-by: Thomas Hellstrom <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Get pressure format flag from firmware to check if we need to normalize
pressure data before reporting it.
Signed-off-by: Duson Lin <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Prepare first round of input updates for 4.1 merge window.
|
|
Non interleaved V2 dualpoint touchpad / stick combos have separate stick
button bits in the touchpad packets, if we do not check these then the
trackpoint buttons will not work when using the touchpad, and when pressed
when the user starts using the touchpad will report a release event even
though the button is still pressed.
This commit fixes this by checking the separate bits, note that we simply
combine the buttons, since the hardware does the same when using the touchpad
buttons with the trackpoint, so we do not have enough information to properly
separate them.
Reported-by: Hans de Bruin <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
When the left touchpad button gets pressed, and then the trackpoint is
moved, and then the button is released, the following happens:
1) touchpad packet is received, touchpad evdev node reports BTN_LEFT 1
2) pointing stick packet is received, the hw will report a BTN_LEFT 1 in
this packet because when the trackstick is active it communicates the
combined touchpad + pointing stick buttons in the trackstick packet,
since alps_report_bare_ps2_packet passes NULL (*) for the dev2 parameter
to alps_report_buttons the combining is not detected and the
pointing stick evdev node will also report BTN_LEFT 1
3) on release of the button a pointing stick packet with BTN_LEFT 0 is
received and the pointing stick evdev node will report BTN_LEFT 0
Note how because of the passing as NULL for dev2 the touchpad evdev node
will never send BTN_LEFT 0 in this scenario leading to a stuck mouse button.
This is a regression in 4.0 introduced by commit 04aae283ba6a8
("Input: ALPS - do not mix trackstick and external PS/2 mouse data")
This commit fixes this by passing in the touchpad evdev as dev2 parameter
when calling alps_report_buttons for the pointingstick on alps v2 devices,
so that alps_report_buttons correctly detect that we're already reporting
the button as pressed via the touchpad evdev node, and will also send the
release event there.
Cc: [email protected] # 4.0
Reported-by: Hans de Bruin <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Acked-by: Pali Rohár <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
To save people some time let's document that we do not want new quirks for
"force-release" keys in the kernel and that they should patch userspace
(udev) instead.
Suggested-by: Pali Rohár <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Signed-off-by: Fengguang Wu <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Signed-off-by: Masaki Ota <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
This change adds support for SS4 touchpad devices as ALPS_PROTO_V8
protocol. They are real multi-touch devices and can be found in TOSHIBA
Tecra C50.
Signed-off-by: Masaki Ota <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|