Use for_each_set_bit to check for set bits in bitmap
as it is more efficient and compact.
Signed-off-by: Anshul Garg <aksgarg1989@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Use for_each_set_bit to check for set bits in bitmap
as it is more efficient than checking individual bits.
Signed-off-by: Anshul Garg <aksgarg1989@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Use for_each_set_bit to check for set bits in bitmap as it is more
efficient than checking individual bits.
Signed-off-by: Anshul Garg <aksgarg1989@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
These reg_default tables are not modified after initialized, so make them
const.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Use the new GPIO descriptor interface to handle the zForce GPIOs.
This simplifies the code and allows transparently handle GPIO polarity, as
specified in device tree data.
Also switch to using gpio_{set|get}_value_cansleep() since none of the
callers is in atomic context and cansleep variant allows more GPIO
controllers to be used with the touchscreen.
Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Despite it's name, sign_extend32() is used for 16 bit values aswell.
Signed-off-by: Martin Kepplinger <martink@posteo.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Get the scaling factor when it reads the sys params. The width value will
multiple the factor and report the value in the TOUCH_MAJOR event.
Signed-off-by: HungNien Chen <hn.chen@weidahitech.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fix this compile error:
drivers/built-in.o: In function `arc_ps2_probe':
/mnt/linux/drivers/input/serio/arc_ps2.c:206: undefined reference to `devm_ioremap_resource'
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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>
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>
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.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Instead of iterating over all bits in a bitmap and test them individually
let's siwtch to for_each_set_bit() which is more compact and is also
faster.
Also use bitmap_weight() when counting number of set bits.
This also fixes INPUT_DO_TOGGLE() implementation as it should have used
*_CNT as the upper boundary, not *_MAX.
Signed-off-by: Anshul Garg <aksgarg1989@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This is a driver for Weida HiTech WDT87xx series touchscreen controller.
Signed-off-by: HungNien Chen <hn.chen@weidahitech.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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>
The controller only receives commands when its present. So for the
correct LED to be lit the LED command has to be sent on the present
event.
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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>
clk_prepare_enable() may fail, so we should better check its return value
and propagate it in the case of error.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The "INPUT MULTITOUCH (MT) PROTOCOL" entry git tree is not there on
git.kernel.org.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Since 39b2bbe3d7 (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.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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>
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>
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>
Use kernel.h macro definition.
Thanks to Julia Lawall for Coccinelle scripting support.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
input_mt_init_slots() will do that for us.
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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.
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Acked-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Acked-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This adds OnKey driver support for DA9063.
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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>
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>
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.
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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.
Fixes: 154b7a489a ("Input: sysrq - allow specifying alternate reset sequence")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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.
Signed-off-by: Shailendra Verma <shailendra.capricorn@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The variable psmouse_smartscroll is bool type so assigning true
instead of 1.
Signed-off-by: Shailendra Verma <shailendra.capricorn@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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>
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:
of:Nstmpe_touchscreenT<NULL>Cst,stmpe-ts
Reported-by: Heiner Kallweit <hkallweit1@gmail.com>
Tested-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
rajeev-dlh.kumar@st.com email-id doesn't exist anymore as I have left the
company.
Signed-off-by: Rajeev Kumar <rajeevkumar.linux@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
As the name suggests, always_unused argument in cyapa_gen3_set_power_mode()
is never used, so there is no reason for setting it to 0.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This makes the intent a tad more clear.
Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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>
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 <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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>
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>
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>
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>
