Input: elan_i2c - change the hover event from MT to ST
The firmware only reports hover condition while the very first contact is
approaching the surface; the hover is not reported for the subsequent
contacts. Therefore we should not be using ABS_MT_DISTANCE to report hover
but rather its single-touch counterpart ABS_DISTANCE.
Signed-off-by: Duson Lin <dusonlin@emc.com.tw> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Dmitry Torokhov [Mon, 29 Jun 2015 18:56:27 +0000 (11:56 -0700)]
Input: wdt87xx_i2c - fix format warning
This fixes the following warning:
drivers/input/touchscreen/wdt87xx_i2c.c: In function 'wdt87xx_validate_firmware':
>> drivers/input/touchscreen/wdt87xx_i2c.c:472:4: warning: format '%zd' expects argument of type 'signed size_t', but argument 4 has type 'size_t' [-Wformat=]
size, fw->size);
Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Dmitry Torokhov [Mon, 1 Jun 2015 17:35:16 +0000 (10:35 -0700)]
Input: improve parsing OF parameters for touchscreens
When applying touchscreen parameters specified in device tree let's make
sure we keep whatever setup was done by the driver and not reset the
missing values to zero.
Reported-by: Pavel Machek <pavel@ucw.cz> Tested-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Dmitry Torokhov [Mon, 1 Jun 2015 17:41:11 +0000 (10:41 -0700)]
Input: edt-ft5x06 - mark as direct input device
edt-ft5x06 is a touchscreen and thus a direct input device; let's amrk it
as such. This also allows us to drop some initialization code as
input_init_mt_slots() will do that for us.
Hans de Goede [Wed, 24 Jun 2015 21:25:54 +0000 (14:25 -0700)]
Input: axp20x-pek - fix reporting button state as inverted
Currently we are reporting the button state as inverted on all boards with
an axp209 pmic, tested on a ba10-tvbox, bananapi, bananapro, cubietruck and
utoo-p66 tablet.
The axp209 datasheet clearly states that the power button must be connected
between the PWRON key and ground. Which means that on a press we will get
a falling edge (dbf) irq not a rising one, and likewise on release we will
get a rising edge (dbr) irq, not a falling one.
This commit swaps the check for the 2 irqs fixing the inverted reporting of
the power button state.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Carlo Caione <carlo@caione.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: xpad - set the LEDs properly on XBox Wireless controllers
Based on Patch by Pierre-Loup A. Griffais <pgriffais@valvesoftware.com>:
Add the logic to set the LEDs on XBox Wireless controllers. Command
sequence found by sniffing the Windows data stream when plugging the
device in.
Updated based on comments on linux-input:
unify codepaths in xpad_send_led_command for wired/ wireless controller.
Also document command values for clarification.
All values tested on Xbox 360 Wireless Controller.
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Frodo Lai [Tue, 16 Jun 2015 22:03:53 +0000 (15:03 -0700)]
Input: pixcir_i2c_ts - fix receive error
The i2c_master_recv() uses readsize to receive data from i2c but compares
to size of rdbuf which is always 27. This would cause problem when the
max_fingers is not 5. Change the comparison value to readsize instead.
Fixes: 36874c7e219 ("Input: pixcir_i2c_ts - support up to 5 fingers and
hardware tracking IDs:)
Cc: stable@vger.kernel.org Signed-off-by: Frodo Lai <frodo_lai@bcmcom.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Uwe Kleine-König [Wed, 17 Jun 2015 00:02:13 +0000 (17:02 -0700)]
Input: improve usage of gpiod API
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for
output. Simplify drivers accordingly.
Note that in the case of the drv260x driver error checking is more
strict now because -ENOSYS is reported to the caller now. But this
should only be returned if GPIOLIB is disabled which shouldn't happen as
the driver depends on GPIOLIB.
Samuel Thibault [Sat, 6 Jun 2015 18:44:39 +0000 (11:44 -0700)]
tty/vt/keyboard: define LED triggers for VT keyboard lock states
In addition to defining triggers for VT LED states, let's define triggers
for VT keyboard lock states, such as "kbd-shiftlock", "kbd-altgrlock", etc.
This permits to fix #7063 from userland by using a modifier to implement
proper CapsLock behavior and have the keyboard caps lock led show that
modifier state.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Tested-by: Pavel Machek <pavel@ucw.cz> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Samuel Thibault [Tue, 17 Mar 2015 04:19:44 +0000 (21:19 -0700)]
tty/vt/keyboard: define LED triggers for VT LED states
Now that input core allows controlling keyboards LEDs via standard LED
subsystem triggers let's switch VT keyboard code to make use of this
feature. We will define the following standard triggers: "kbd-scrollock",
"kbd-numlock", "kbd-capslock", and "kbd-kanalock" which are default
triggers for respective LEDs on keyboards.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Tested-by: Pavel Machek <pavel@ucw.cz> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Samuel Thibault [Tue, 17 Mar 2015 04:19:56 +0000 (21:19 -0700)]
Input: export LEDs as class devices in sysfs
This change creates a new input handler called "leds" that exports LEDs on input
devices as standard LED class devices in sysfs and allows controlling their
state via sysfs or via any of the standard LED triggers. This allows to
re-purpose and reassign LDEs on the keyboards to represent states other
than the standard keyboard states (CapsLock, NumLock, etc).
The old API of controlling input LEDs by writing into /dev/input/eventX
devices is still present and will take precedence over accessing via LEDs
subsystem (i.e. it may override state set by a trigger). If input device is
"grabbed" then requests coming through LED subsystem will be ignored.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Tested-by: Pavel Machek <pavel@ucw.cz> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Irina Tirdea [Tue, 9 Jun 2015 18:04:40 +0000 (11:04 -0700)]
Input: goodix - export id and version read from device
Goodix touchscreens export through their registers a Product ID and
Firmware Version. The Product ID is an ASCII encoding of the product name
(e.g.: "911").
Export to sysfs (through the input subsystem) the product id and firmware
version read from the device rather than using constant values.
Irina Tirdea [Tue, 9 Jun 2015 18:03:15 +0000 (11:03 -0700)]
Input: goodix - fix variable length array warning
Fix sparse warning:
drivers/input/touchscreen/goodix.c:182:26: warning: Variable length array is used.
Replace the variable length array with fixed length.
Some Goodix devices have maximum 5 touch points, while others have 10 touch
points. Using the maximum length (80 bytes) for all devices will lead to
wasting 40 bytes on stack when using devices with maximum 5 touch points.
However, that is preferable to using kmalloc which will use even more
resources.
Charlie Mooney [Mon, 8 Jun 2015 23:48:23 +0000 (16:48 -0700)]
Input: elan_i2c - add product IDs FW names
Previously the elan_i2c touchpad driver would simply request the firmware
"/lib/firmware/elan_i2c.bin", which does not work well if there are
multiple such devices in the system.
Let's append the "product ID" (by using the same function as the sysfs
interface for consistency) to the filename. This results in filenames of
the form "/lib/firmware/elan_i2c_72.0.bin", allowing you to support
multiple elan_i2c touchpads on the same device by simply naming each
device's FW with its corresponding product ID. This way when you trigger a
fw update the driver will load the correct binary.
Signed-off-by: Charlie Mooney <charliemooney@chromium.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Duson Lin [Mon, 8 Jun 2015 23:39:35 +0000 (16:39 -0700)]
Input: elan_i2c - add support for multi IC type and iap format
In order to support multiple IC types for i2c/smbus protocol, add get ic
type command and use this data when checking firmware page count and
signature address.
Signed-off-by: Duson Lin <dusonlin@emc.com.tw> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Hans de Goede [Fri, 5 Jun 2015 05:31:43 +0000 (22:31 -0700)]
Input: alps - do not reduce trackpoint speed by half
On some v7 devices (e.g. Lenovo-E550) the deltas reported are typically
only in the 0-1 range dividing this by 2 results in a range of 0-0.
And even for v7 devices where this does not lead to making the trackstick
entirely unusable, it makes it twice as slow as before we added v7 support
and were using the ps/2 mouse emulation of the dual point setup.
If some kind of generic slowdown is actually necessary for some devices,
then that belongs in userspace, not in the kernel.
Cc: stable@vger.kernel.org Reported-and-tested-by: Rico Moorman <rico.moorman@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Dmitry Tunin [Sun, 31 May 2015 18:26:49 +0000 (11:26 -0700)]
Input: focaltech - report finger width to userspace
Focaltech touchpads report finger width in packet[5] of absolute packet.
Range for width in raw format is 0x10 - 0x70. Second half-byte is always 0.
0xff is reported, when a large contact area is detected.
This can be handled in userspace.
Arnd Bergmann [Tue, 26 May 2015 21:45:29 +0000 (14:45 -0700)]
tty: remove platform_sysrq_reset_seq
The platform_sysrq_reset_seq code was intended as a way for an embedded
platform to provide its own sysrq sequence at compile time. After over two
years, nobody has started using it in an upstream kernel, and the platforms
that were interested in it have moved on to devicetree, which can be used
to configure the sequence without requiring kernel changes. The method is
also incompatible with the way that most architectures build support for
multiple platforms into a single kernel.
Now the code is producing warnings when built with gcc-5.1:
drivers/tty/sysrq.c: In function 'sysrq_init':
drivers/tty/sysrq.c:959:33: warning: array subscript is above array bounds [-Warray-bounds]
key = platform_sysrq_reset_seq[i];
We could fix this, but it seems unlikely that it will ever be used, so
let's just remove the code instead. We still have the option to pass the
sequence either in DT, using the kernel command line, or using the
/sys/module/sysrq/parameters/reset_seq file.
Shailendra Verma [Tue, 26 May 2015 21:08:37 +0000 (14:08 -0700)]
Input: synaptics_i2c - use proper boolean values
The variable no_decel is bool type so assigning "true" instead of "1".
Also, synaptics_i2c_get_input() has bool return type, so let's use "false"
there.
Dmitry Torokhov [Fri, 22 May 2015 20:44:33 +0000 (13:44 -0700)]
Input: stmpe-ts - enforce device tree only mode
The STMPE MFD is only used with device tree configured systems (and STMPE
MFD core depends on OF), so force the configuration to come from device
tree only.
Tested-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Marek Vasut <marex@denx.de> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Dmitry Torokhov [Fri, 22 May 2015 20:09:11 +0000 (13:09 -0700)]
Input: stmpe-ts - fix automatic module loading
When STMPE is instantiated via device tree individual MFD cells rae formed
with OF modaliases, not platform modaliases, and so we need to add OF
device table to the driver if we want it to load automatically:
Khem Raj [Fri, 22 May 2015 16:56:29 +0000 (09:56 -0700)]
Input: sentelic - use "static inline" instead of "inline"
gcc-5 defaults to gnu11 which used c99 inline semantics in c99 'inline' is
not externally visible unlike gnu89, therefore we use 'static inline' which
has same semantics between gnu89 and c99
Marek Vasut [Fri, 8 May 2015 05:25:49 +0000 (22:25 -0700)]
Input: smtpe-ts - wait 50mS until polling for pen-up
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.
Marek Vasut [Fri, 8 May 2015 05:24:58 +0000 (22:24 -0700)]
Input: smtpe-ts - use msecs_to_jiffies() instead of HZ
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.
Laurent Pinchart [Thu, 21 May 2015 23:07:37 +0000 (16:07 -0700)]
Input: adxl34x - add OF match support
The I2C subsystem can match devices without explicit OF support based on
the part of their compatible property after the comma. However, this
mechanism uses the first compatible value only. For adxl34x OF device
nodes the compatible property will contain the more specific
"adi,adxl345" or "adi,adxl346" value first. This prevents the device
node from being matched with the adxl34x driver.
Fix this by adding an OF match table with an "adi,adxl345" compatible
entry. There's no need to add the "adi,adxl346" entry as the ADXL346 is
backward-compatible with the ADXL345 with differences handled by runtime
detection of the device model.
Laurent Pinchart [Thu, 21 May 2015 23:06:49 +0000 (16:06 -0700)]
DT: i2c: Deprecate adi,adxl34x compatible string
DT nodes should use the more specific adi,adxl345 and adi,adxl346
compatible values instead. As the ADXL346 is backward-compatible with
the ADXL345, ADXL346 nodes must list both adi,adxl346 and adi,adxl345,
in that order.
Thomas Hellstrom [Wed, 20 May 2015 21:50:30 +0000 (14:50 -0700)]
Input: joydev - don't classify the vmmouse as a joystick
Joydev is currently thinking some absolute mice are joystick, and that
messes up games in VMware guests, as the cursor typically gets stuck in
the top left corner.
Try to detect the event signature of a VMmouse input device and back off
for such devices. We're still incorrectly detecting, for example, the
VMware absolute USB mouse as a joystick, but adding an event signature
matching also that device would be considerably more risky, so defer that
to a later merge window.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Hans de Goede [Wed, 20 May 2015 21:37:41 +0000 (14:37 -0700)]
Input: alps - fix finger jumps on lifting 2 fingers on v7 touchpad
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
Hans de Goede [Wed, 20 May 2015 21:43:09 +0000 (14:43 -0700)]
Input: alps - use the generic process_bitmap function for v5 touchpads
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 <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Hans de Goede [Wed, 20 May 2015 21:42:15 +0000 (14:42 -0700)]
Input: alps - do not use input-mt finger tracking for semi-mt devices
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 <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Hans de Goede [Wed, 20 May 2015 21:41:10 +0000 (14:41 -0700)]
Input: alps - use more accurate coordinates for first touch in semi-mt mode
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 <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Hans de Goede [Wed, 20 May 2015 21:40:06 +0000 (14:40 -0700)]
Input: alps - decode the position packet first
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 <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Hans de Goede [Wed, 20 May 2015 21:39:21 +0000 (14:39 -0700)]
Input: alps - only set fields that are actually present
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 <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Hans de Goede [Wed, 20 May 2015 21:38:33 +0000 (14:38 -0700)]
Input: alps - change alps_decode_rushmore to do all decoding itself
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 <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fabio Estevam [Fri, 15 May 2015 22:55:52 +0000 (15:55 -0700)]
Input: wm831x-on - pass the IRQF_ONESHOT flag
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.
Fabio Estevam [Fri, 15 May 2015 22:55:42 +0000 (15:55 -0700)]
Input: twl6040-vibra - pass the IRQF_ONESHOT flag
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.
Fabio Estevam [Fri, 15 May 2015 22:55:34 +0000 (15:55 -0700)]
Input: retu-pwrbutton - pass the IRQF_ONESHOT flag
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.
Fabio Estevam [Fri, 15 May 2015 22:55:23 +0000 (15:55 -0700)]
Input: twl4030-pwrbutton - pass the IRQF_ONESHOT flag
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.
Input: max7359_keypad - do not set MAX7359_CFG_INTERRUPT flag
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 <dushistov@mail.ru> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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.
Marek Vasut [Fri, 8 May 2015 05:25:49 +0000 (22:25 -0700)]
Input: smtpe-ts - wait 50mS until polling for pen-up
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.
Marek Vasut [Fri, 8 May 2015 05:24:58 +0000 (22:24 -0700)]
Input: smtpe-ts - use msecs_to_jiffies() instead of HZ
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.
Paul Cercueil [Wed, 6 May 2015 23:52:13 +0000 (16:52 -0700)]
Input: goodix - check the 'buffer status' bit before reading data
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.
Guido Martínez [Wed, 6 May 2015 23:35:21 +0000 (16:35 -0700)]
Input: adp5589-keys - fix event count mask
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.
Guido Martínez [Wed, 6 May 2015 23:33:40 +0000 (16:33 -0700)]
Input: adp5589-keys - fix pull mask setting
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).
Dudley Du [Mon, 20 Apr 2015 17:00:05 +0000 (10:00 -0700)]
Input: cyapa - fix setting suspend scan rate
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.
Duson Lin [Mon, 20 Apr 2015 17:19:24 +0000 (10:19 -0700)]
Input: elan_i2c - fix calculating number of x and y traces.
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 <dusonlin@emc.com.tw> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: elants_i2c - zero-extend hardware ID in firmware name
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<charliemooney@chromium.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: atmel_mxt_ts - add support for Google Pixel 2
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 <javier.martinez@collabora.co.uk> Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Thomas Hellstrom [Tue, 14 Apr 2015 17:06:38 +0000 (10:06 -0700)]
Input: add vmmouse driver
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 <thellstrom@vmware.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Hans de Goede [Sun, 12 Apr 2015 22:42:35 +0000 (15:42 -0700)]
Input: alps - non interleaved V2 dualpoint has separate stick button bits
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 <jmdebruin@xmsnet.nl> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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: stable@vger.kernel.org # 4.0 Reported-by: Hans de Bruin <jmdebruin@xmsnet.nl> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: atkbd - document "no new force-release quirks" policy
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.
Masaki Ota [Sat, 28 Mar 2015 04:30:46 +0000 (21:30 -0700)]
Input: ALPS - V7 devices can report 5-finger taps
Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
projects / mirror_ubuntu-kernels.git / log