When using a protocol v2 or v3 hardware, elantech uses the function
elantech_report_semi_mt_data() to report data. This devices are rather
creepy because if num_finger is 3, (x2,y2) is (0,0). Yes, only one valid
touch is reported.
Anyway, userspace (libinput) is now confused by these (0,0) touches,
and detect them as palm, and rejects them.
Commit 3c0213d17a ("Input: elantech - fix semi-mt protocol for v3 HW")
was sufficient enough for xf86-input-synaptics and libinput before it has
palm rejection. Now we need to actually tell libinput that this device is
a semi-mt one and it should not rely on the actual values of the 2 touches.
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
As of e0361b7017 ("Input: wacom_w8001 - split the touch and pen devices
into two devices") the touch events aren't multiplexed over the same device
anymore, the use of ABS_MT_TOOL_TYPE is superfluous. And even before then
it only ever sent MT_TOOL_TYPE_FINGER anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Commit 4ea14a53d8 ("Input: gpio-keys - report
error when disabling unsupported key") tried let user know that they
attempted to disable an unsupported key, unfortunately the check is wrong
as it believes that all codes are invalid. Fix it by ensuring that keys
that we try to disable are subset of keys (or switches) that device
reports.
Fixes: 4ea14a53d8 ("Input: gpio-keys - report error when disabling unsupported key")
Reported-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Tested-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Commit da1f026b53 ("Keyboard: omap-keypad:
use matrix_keypad.h") switched the driver to use matrix keypad
infrastructure, which made array of keycodes to be unsigned short, and
caused the test for negativity never trigger. This leads to the following
static checker warning:
drivers/input/keyboard/omap-keypad.c:158 omap_kp_tasklet()
warn: 'keycodes[]' is never negative.
Given that we did not care about this check for a few years already let's
simply remove it.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Remove write to REG_IRQCLR and REG_IRQWAKEUP in interrupt handler for
IRQENB_HW_PEN as the resume handler should and does clear REG_IRQWAKEUP.
IRQENB_HW_PEN bit is set in irqclr so that all interrupts get cleared
later so let IRQENB_HW_PEN be cleared by that.
Without this patch wakeup events from TSC_ADC do not work because pending
interrupts in TSC_ADC were causing HW_PEN interrupt, needed for wake from
suspend modes, to get disabled immediately by IRQ handler after being
enabled and preventing wake from happening.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
It feels like we should set the tasklet data before enabling it.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Because of the wrong condition we'd never retry firmware update.
Acked-by: Yoichi Yuasa <yuasa@linux-mips.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This patch moves v3 pinnacle code for trackstick detection from
alps_hw_init_v3() to alps_set_protocol() so ALPS_DUALPOINT flag can be
cleared before registering trackstick input device in kernel.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This patch adds detection of trackstick for v7 protocol devices. Code in
this patch is used in official Dell touchpad linux drivers for Dell models:
Dell Latitude E5250/5250, E5450/5450, E5550/5550
Detection code and base reg for alps v3 rushmore and v7 devices is exacly
same.
Also user in bug https://bugzilla.kernel.org/show_bug.cgi?id=94801 reported
that Toshiba Sattellite Z30-A-1DG has only alps v7 touchpad device without
trackstick and kernel reports to userspace also redundant trackstick
device.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Alex Hung <alex.hung@canonical.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Use to_delayed_work() instead of open-coding it.
Signed-off-by: Geliang Tang <geliangtang@163.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The bma150_cfg structure is never modified, so declare it as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Without i8042.nomux=1 the Elantech touch pad is not working at all on
a Fujitsu Lifebook U745. This patch does not seem necessary for all
U745 (maybe because of different BIOS versions?). However, it was
verified that the patch does not break those (see opensuse bug 883192:
https://bugzilla.opensuse.org/show_bug.cgi?id=883192).
Signed-off-by: Aurélien Francillon <aurelien@francillon.net>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
We didn't check input_allocate_device() for failures so it could lead to
a NULL deref.
Fixes: 6b0f8f9c52 ('Input: add eGalaxTouch serial touchscreen driver')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Currently the user can set ff_effects_max to zero with the EV_FF bit (and
the FF_GAIN and/or FF_AUTOCENTER bits) set, in this case the uninitialized
methods ff->set_gain and/or ff->set_autocenter can be dereferenced,
resulting in a kernel oops.
Check in uinput_create_device() and print a helpful message and return
-EINVAL in case the check fails.
Signed-off-by: Elias Vanderstuyft <elias.vds@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Rework the uinput ABS validation to check passed absinfo data immediately,
but do ABS initialization as last step in UI_DEV_CREATE. The behavior
observed by user-space is not changed, as ABS initialization was never
checked for errors.
With this in place, the order of device initialization and abs
configuration is no longer fixed. Userspace can initialize the device and
afterwards set absinfo just fine.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This adds two new ioctls, UINPUT_DEV_SETUP and UI_ABS_SETUP, that replaces
the old device setup method (by write()'ing "struct uinput_user_dev" to the
node). The old method is not easily extendable and requires huge payloads.
Furthermore, overloading write() without properly versioned objects is
error-prone.
Therefore, we introduce two new ioctls to replace the old method. These
ioctls support all features of the old method, plus a "resolution" field
for absinfo. Furthermore, it's properly forward-compatible to new ABS codes
and a growing "struct input_absinfo" structure.
UI_ABS_SETUP also allows user-space to skip unknown axes if not set. There
is no need to copy the whole array temporarily into the kernel, but instead
the caller issues several ioctl where we copy each value manually.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
When sending "SLEEP" command to the controller it ceases scanning
completely and is unable to wake the system up from sleep, so if it is
configured as a wakeup source we should simply configure interrupt for
wakeup and rely on idle logic within the controller to reduce power
consumption while it is not used.
Signed-off-by: James Chen <james.chen@emc.com.tw>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The goodix touchscreen driver uses a "rotated_screen" flag for
systems on which the touchscreen is mounted rotated by 180
degrees with respect to the display. With the addition of
support for the dt properties "touchscreen-inverted-x" and
"touchscreen-inverted-y", a separate "rotated_screen" flag
is not necessary anymore. This patch replaces it by setting
the inverted_x and inverted_y flags instead.
Signed-off-by: Karsten Merker <merker@debian.org>
Reviewed-by: Irina Tirdea <irina.tirdea@intel.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Acked-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Implement support for the following device-tree and ACPI 5.1 DSD
properties in the goodix touchscreen driver:
- touchscreen-inverted-x: X axis is inverted (boolean)
- touchscreen-inverted-y: Y axis is inverted (boolean)
- touchscreen-swapped-x-y: X and Y axis are swapped (boolean)
These are necessary on tablets which have a display in portrait
format while the touchscreen is in landscape format, such as e.g.
the MSI Primo 81.
Signed-off-by: Karsten Merker <merker@debian.org>
Tested-by: Bastien Nocera <hadess@hadess.net>
Tested-by: Irina Tirdea <irina.tirdea@intel.com> (with ACPI DSD properties)
Tested-by: Aleksei Mamlin <mamlinav@gmail.com> (with device-tree properties)
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Implement suspend/resume for goodix driver.
The suspend and resume process uses the gpio pins. If the device ACPI/DT
information does not declare gpio pins, suspend/resume will not be
available for these devices.
This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
driver gt9xx.c for Android (publicly available in Android kernel trees for
various devices).
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Goodix devices can be configured by writing custom data to the device at
init. The configuration data is read with request_firmware from
"goodix_<id>_cfg.bin", where <id> is the product id read from the device
(e.g.: goodix_911_cfg.bin for Goodix GT911, goodix_9271_cfg.bin for
GT9271).
The configuration information has a specific format described in the Goodix
datasheet. It includes X/Y resolution, maximum supported touch points,
interrupt flags, various sensitivity factors and settings for advanced
features (like gesture recognition).
Before writing the firmware, it is necessary to reset the device. If
the device ACPI/DT information does not declare gpio pins (needed for
reset), writing the firmware will not be available for these devices.
This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
driver gt9xx.c for Android (publicly available in Android kernel
trees for various devices).
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Tested-by: Aleksei Mamlin <mamlinav@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
After power on, it is recommended that the driver resets the device.
The reset procedure timing is described in the datasheet and is used
at device init (before writing device configuration) and
for power management. It is a sequence of setting the interrupt
and reset pins high/low at specific timing intervals. This procedure
also includes setting the slave address to the one specified in the
ACPI/device tree.
This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
driver gt9xx.c for Android (publicly available in Android kernel
trees for various devices).
For reset the driver needs to control the interrupt and
reset gpio pins (configured through ACPI/device tree). For devices
that do not have the gpio pins properly declared, the functionality
depending on these pins will not be available, but the device can still
be used with basic functionality.
For both device tree and ACPI, the interrupt gpio pin configuration is
read from the "irq-gpios" property and the reset pin configuration is
read from the "reset-gpios" property. For ACPI 5.1, named properties
can be specified using the _DSD section. This functionality will not be
available for devices that use indexed gpio pins declared in the _CRS
section (we need to provide backward compatibility with devices
that do not support using the interrupt gpio pin as output).
For ACPI, the pins can be specified using ACPI 5.1:
Device (STAC)
{
Name (_HID, "GDIX1001")
...
Method (_CRS, 0, Serialized)
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBus (0x0014, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\I2C0",
0x00, ResourceConsumer, ,
)
GpioInt (Edge, ActiveHigh, Exclusive, PullNone, 0x0000,
"\\I2C0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0
}
GpioIo (Exclusive, PullDown, 0x0000, 0x0000,
IoRestrictionOutputOnly, "\\I2C0", 0x00,
ResourceConsumer, ,
)
{
1
}
})
Return (RBUF)
}
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package (2) {"irq-gpios", Package() {^STAC, 0, 0, 0 }},
Package (2) {"reset-gpios", Package() {^STAC, 1, 0, 0 }},
...
}
}
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Bastien Nocera <hadess@hadess.net>
Tested-by: Bastien Nocera <hadess@hadess.net>
Tested-by: Aleksei Mamlin <mamlinav@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Each of the Goodix devices supported by this driver has a fixed size for
the configuration information registers. The size varies depending on the
device and is specified in the datasheet.
Use the proper configuration length as specified in the datasheet for
each device model, so we do not read more than the actual size of the
configuration registers.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Acked-by: Bastien Nocera <hadess@hadess.net>
Tested-by: Bastien Nocera <hadess@hadess.net>
Tested-by: Aleksei Mamlin <mamlinav@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This makes Logitech PS2++ protocol implementation consistent with
the naming in other protocols. Also mark the stub as "static inline"
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Marcin Sochacki <msochacki+kernel@gmail.com>
Tested-by: Till <till2.schaefer@uni-dortmund.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
PS/2 protocol is slow, and using it with pass-through port (where we
encapsulate PS/2 into PS/2) is slower yet so it takes quite a bit of time
to do full protocol discovery for device attached to a pass-through port.
However, so far we have not see anything but trackpoints or basic PS/2
mice on pass-through ports, so let's limit protocols that we probe there
to Trackpoint, IntelliMouse Explorer, IntelliMouse, and bare PS/2 protocol,
and avoid other extended protocols, such as Synaptics, ALPS, etc.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Marcin Sochacki <msochacki+kernel@gmail.com>
Tested-by: Till <till2.schaefer@uni-dortmund.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
In preparation of limiting protocols that we try on pass-through ports,
let's rework initialization code and factor common code into
psmouse_try_protocol() that accepts protocol type (instead of detec()
function pointer) and can, for most protocols, perform both detection and
initialization.
Note that this removes option of forcing Lifebook protocol on devices that
are not recognized by lifebook_detect() as having the hardware, but I do
not recall anyone using this option.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Marcin Sochacki <msochacki+kernel@gmail.com>
Tested-by: Till <till2.schaefer@uni-dortmund.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
We move protocol descriptions and psmouse_find_by_type() and
pmouse_find_by_name() so that we can use them without forward declarations
in the subsequent patches.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Marcin Sochacki <msochacki+kernel@gmail.com>
Tested-by: Till <till2.schaefer@uni-dortmund.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
When Cypress protocol support is disabled cypress_init() is a stub that
always returns -ENOSYS, so there is not point in testing for
CONFIG_MOUSE_PS2_CYPRESS after we decided that we are dealing with a
Cypress device. Also, we should only be calling cypress_detect() when
set_properties argument is "true", like with other protocols.
There is a slight change in behavior to make follow-up patches more
uniform: when we detect Cypress but its initialization fails, instead of
immediately returning PSMOUSE_PS2 protocol we now continue trying
IntelliMouse [Explorer]. Given that Cypress devices only have issue with
Sentelic probes probing Imtellimouse should be safe.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Marcin Sochacki <msochacki+kernel@gmail.com>
Tested-by: Till <till2.schaefer@uni-dortmund.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The fact that we were calling focaltech_init() even when Focaltech support
is disabled was confusing. Rearrange the code so that if support is
disabled we continue to fall through the rest of protocol probing code
until we get to full reset that Focaltech devices need to work properly.
Also, replace focaltech_init() with a stub now that it is only called when
protocol is enabled.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Marcin Sochacki <msochacki+kernel@gmail.com>
Tested-by: Till <till2.schaefer@uni-dortmund.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The module was using non-standard comment style with comment blocks often
starting at the very beginning of a line instead of being aligned with the
code. Let's switch to standard formatting.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Marcin Sochacki <msochacki+kernel@gmail.com>
Tested-by: Till <till2.schaefer@uni-dortmund.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Instead of a series mostly exclusive "if" statements testing protocol type
of the mouse let's use "switch" statement.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Marcin Sochacki <msochacki+kernel@gmail.com>
Tested-by: Till <till2.schaefer@uni-dortmund.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
On this board, the touchscreen, an ads7843, is not handled directly by
Linux but by a companion FPGA. This FPGA is memory-mapped and the IP
design is very similar to the mk712.
This commit adds the support for this IP.
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
There are two EETI touchscreen drivers in the kernel (eeti_ts and
egalax_ts) but both are for I2C-connected panels. This is for a different,
serial and not multi-touch touchscreen panel. The protocol documentation is
at http://www.eeti.com.tw/pdf/Software%20Programming%20Guide_v2.0.pdf
Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Previously the "vendor" and "product" IDs for the elan_i2c driver simply
reported 0000. This patch modifies the elan_i2c driver to include the
Elan vendor ID and the touchpad's product id under
input/input*/{vendor,product}.
Specifically, this is to allow us to apply a generic Elan gestures config
that will apply to all Elan touchpads on ChromeOS. These configs match to
input devices in various ways, but one major way is by matching on vendor
ID. Adding this patch allows the default Elan touchpad config to be
applied to Elan touchpads in this kernel by matching on devices that have
vendor ID 04f3.
Note that product ID is also available via custom sysfs entry "product_id"
as well.
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Stop reporting KEY_SLEEP for a short key-press and report KEY_POWER instead
This change applies to both DA9063 and DA9062 ONKEY drivers.
A previous application used for testing by the developer required a
KEY_SLEEP and KEY_POWER input_report_key event to distinguish between a
short and long key-press of the power key. This is not the general
convention and the typical solution is for KEY_POWER to be used in both
cases: suspend and S/W power off.
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The Atmel maxtouch DT binding documents that the compatible string for
the device is "atmel,maxtouch" and the I2C core always reports a module
alias of the form i2c:alias where alias is the compatible string model:
$ grep MODALIAS /sys/devices/platform/12e00000.i2c/i2c-8/8-004b/uevent
MODALIAS=i2c:maxtouch
But there isn't maxtouch entry in the I2C device ID table so when the
i2c:maxtouch MODALIAS uevent is reported, kmod is not able to match the
alias with a module to load:
$ modinfo atmel_mxt_ts | grep alias
alias: of:N*T*Catmel,maxtouch
alias: i2c:mXT224
alias: i2c:atmel_mxt_tp
alias: i2c:atmel_mxt_ts
alias: i2c:qt602240_ts
So add the maxtouch entry to the I2C device ID table to allow the module
to be autoloaded when the device is registered via OF.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
On some devices the wake and enable pins of the pixcir touchscreen
controller are connected to gpios and these must be controlled by the
driver for the device to operate properly.
Signed-off-by: Sander Vermin <sander@vermin.nl>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
These devices have a pen device and a touch device through the same serial
protocol, split it up into two separate devices like we do for USB Wacom
tablets too.
Userspace already matches on the device name so we can't drop it
completely. Compose the same basename based on capabilities and append the
tool type, leading to a name like "Wacom Serial Penabled 2FG Touchscreen
Pen".
Note that this drops BTN_TOOL_FINGER, it is not needed once the tools
are split out (and a touch device with BTN_TOOL_FINGER is interpreted
as touchpad by most of userspace).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This is preparation work for splitting it up for two event nodes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
If a device failed at the pen setup and gets a zero reply from the touch
device, we need to return an error. Otherwise we have a device with
nothing but a name and the EV_KEY and EV_ABS bits.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
A small copy and paste error was preventing the haptics device being
disabled. This patch corrects the value written on disable.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
These new helpers simplify implementing multi-driver modules and
properly handle failure to register one driver by unregistering all
previously registered drivers.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The aiptek driver crashes in aiptek_probe() when a specially crafted USB
device without endpoints is detected. This fix adds a check that the device
has proper configuration expected by the driver. Also an error return value
is changed to more matching one in one of the error paths.
Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Apparently people are installing generic Linux distributions not only on
Pixels but also on other Chromebooks. Unfortunately on all of them Atmel
parts assigned names ATML0000 and ATML0001, and do not carry any other
configuration data. So let's create generic instance of platform data that
should cover most of them (we assume that they will not be using T100
objects, since with those Google mapped BTN_LEFT onto a different GPIO, so
slightly different keymap would be needed, but I think we used parts with
T100 on ARM devices where we thankfully have DTS and can describe the
devices better).
Tested-by: Rich K <rgkirch@gmail.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>