CONFIG_INPUT may itself be a loadable module, but the sirf power key
driver is listed as 'bool', which makes it possible to select
a broken configuration with the driver built-in but the subsystem
not loaded. In this configuration, we get a link error:
drivers/input/built-in.o: In function `sirfsoc_pwrc_isr':
drivers/input/misc/sirfsoc-onkey.c:63: undefined reference to `input_event'
drivers/input/built-in.o: In function `sirfsoc_pwrc_isr':
include/linux/input.h:414: undefined reference to `input_event'
drivers/input/built-in.o: In function `sirfsoc_pwrc_probe':
drivers/input/misc/sirfsoc-onkey.c:132: undefined reference to `devm_input_allocate_device'
drivers/input/misc/sirfsoc-onkey.c:139: undefined reference to `input_set_capability'
drivers/input/misc/sirfsoc-onkey.c:161: undefined reference to `input_register_device'
drivers/input/built-in.o: In function `sirfsoc_pwrc_report_event':
drivers/input/misc/sirfsoc-onkey.c:48: undefined reference to `input_event'
drivers/input/built-in.o: In function `sirfsoc_pwrc_report_event':
include/linux/input.h:414: undefined reference to `input_event'
drivers/input/built-in.o:(.debug_addr+0x24): undefined reference to `input_event'
drivers/input/built-in.o:(.debug_addr+0xbc): undefined reference to `devm_input_allocate_device'
drivers/input/built-in.o:(.debug_addr+0x104): undefined reference to `input_set_capability'
drivers/input/built-in.o:(.debug_addr+0x128): undefined reference to `input_register_device'
This marks the driver as 'tristate' so it becomes possible to have
it in a loadable module, mainly to help with randconfig builds.
We also have to add a missing semicolon here, which ended up not
being needed in built-in mode because the following MODULE_DEVICE_TABLE
is an empty macro followed by another semicolon then.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
There are two definitions of xpad_identify_controller(), one is used
when CONFIG_JOYSTICK_XPAD_LEDS is set, but the other one is empty
and never used, and we get a gcc warning about it:
drivers/input/joystick/xpad.c:1210:13: warning: 'xpad_identify_controller' defined but not used [-Wunused-function]
This removes the second definition.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: cae705baa4 ("Input: xpad - re-send LED command on present event")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Add support to disable buttons from DT via status property if given button
is not supported on given platforms. This will help re-using existing dtsi
files across multiple platforms.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Allow specifying name if input device via device tree property. This helps
userspace code to get name and perform proper event to key mapping in some
cases (for example, on Android).
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Bring in update to xpad driver improves support of Xbox One and wireless
controllers and fixes handling of concurrent requests to force feedback
and LEDs.
Apparently the Covert Forces ID is not Covert Forces pad exclusive, but
rather denotes a new firmware version that can be found on all new
controllers and can be also updated on old hardware using Windows 10.
see: https://github.com/paroj/xpad/issues/19
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Both T100 and T9 handle range and orientation in a similar fashion.
Reduce duplication between the two implementations.
Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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>
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>
When lighting up the segment identifying wireless controller, Instead of
sending command directly to the controller, let's do it via LED API (usinf
led_set_brightness) so that LED object state is in sync with controller
state and we'll light up the correct segment on resume as well.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The irq_out urb is dead after suspend/ resume on my x360 wr pad. (also
reproduced by Zachary Lund [0]) Work around this by implementing
suspend, resume, and reset_resume callbacks and properly shutting down
URBs on suspend and restarting them on resume.
[0]: https://github.com/paroj/xpad/issues/6
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
There's apparently a serial number woven into both input and output
packets; neglecting to specify a valid serial number causes the controller
to ignore the rumble packets.
The scale of the rumble was also apparently halved in the packets.
The initialization packet had to be changed to allow force feedback to
work.
see https://github.com/paroj/xpad/issues/7 for details.
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Track the status of the irq_out URB to prevent submission iof new requests
while current one is active. Failure to do so results in the "URB submitted
while active" warning/stack trace.
Store pending brightness and FF effect in the driver structure and replace
it with the latest requests until the device is ready to process next
request. Alternate serving LED vs FF requests to make sure one does not
starve another. See [1] for discussion. Inspired by patch of Sarah Bessmer
[2].
[1]: http://www.spinics.net/lists/linux-input/msg40708.html
[2]: http://www.spinics.net/lists/linux-input/msg31450.html
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.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>
Arnd Bergmann
Dmitry Torokhov
Laxman Dewangan
Pavel Rojtberg
Nick Dyer
Benjamin Tissoires
Peter Hutterer
Dave Gerlach
Dan Carpenter
Pali Rohár
Pierre-Loup A. Griffais
Geliang Tang
Julia Lawall