When everything goes smoothly, ret is set to 0 which makes the function
to return EIO error.
Fixes: 8e9faa1546 ("HID: cp2112: fix gpio-callback error handling")
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Dell Canvas exports 2 collections for the Pen part. The only
difference between the 2 is that the default one has half the resolution
of the second one.
The Windows driver switches the tablet into the second mode, so we should
behave the same.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Wacom Pro Pen 3D includes a third barrel switch which is intended to
be particularly useful in applications where one frequency uses pan, zoom,
and rotate to navigate around a scene or model. The pen is compatible with
the MobileStudio Pro, 2nd-gen Intuos Pro, and Cintiq Pro. When the third
button is pressed, these devices set both the HID_DG_BARRELSWITCH and
HID_DG_BARRELSWITCH2 usages since their HID descriptors do not include a
usage specific to the button.
Rather than send both BTN_STYLUS and BTN_STYLUS2 when the third button is
pressed, userspace (libinput) has requested that we detect this condition
and report a newly-defined BTN_STYLUS3 event instead. We could define a
quirk specific to devices compatible with the Pro Pen 3D, but the liklihood
of seeing both barrel switch bits set with other pens/devices is low enough
to not worry about (pens mechanically prevent accidental activation of
multiple switches).
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The SHANWAN PS3 clone joypad will start its rumble motors as soon as
it is plugged in via USB. As the additional USB interrupt does nothing on
the original PS3 Sixaxis joypads, and makes a number of other
clone joypads actually start sending data, disable that call for
the SHANWAN so the rumble motors aren't started on plug.
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Several cheap Apollo Lake based laptops / 2-in-1s use an i2c-hid mt
touchpad which is advertised by the DSDT with an ACPI HID of "SYNA3602",
this touchpad can be found on e.g. the Cube Thinker and the EZBook 3 Pro.
On my "T-bao Tbook air" the i2c-hid driver fails to bind to this touchpad:
"i2c_hid i2c-SYNA3602:00: failed to reset device.".
After some debuging this it seems that this touchpad simply never sends
an interrupt after a reset as expected by the i2c hid driver. This commit
adds a quirk for this device, making i2c_hid_command sleep 100ms after
a reset instead of waiting for an irq, fixing i2c-hid failing to bind to
this touchpad.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
On laptops such as Asus GL553VD, setting keyboard backlight levels
does not work. This change enables F3/F4 keys to set backlight levels
(from 0 to 3, total 4 levels) on such laptops.
It is intended only to the following device: 0x0b05 1854:
P: Vendor=0b05 ProdID=1854 Rev=03.02
S: Manufacturer=ITE Tech. Inc.
S: Product=ITE Device(8910)
[jkosina@suse.cz: massage changelog a little bit]
Signed-off-by: Mustafa C Kuscu <mustafakuscu@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Otherwise, with HIDRAW=n, the probe function crashes because of null
dereference of hdev->hidraw.
Cc: stable@vger.kernel.org
Fixes: 42cb6b35b9 ("HID: cp2112: use proper hidraw name with minor number")
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add ID 044f:b605 ThrustMaster, Inc. force feedback Racing Wheel
Signed-off-by: Viktor Chapliev <viktor-tch@yandex.ru>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Several function prototypes for the set/get functions defined by
module_param_call() have a slightly wrong argument types. This fixes
those in an effort to clean up the calls when running under type-enforced
compiler instrumentation for CFI. This is the result of running the
following semantic patch:
@match_module_param_call_function@
declarer name module_param_call;
identifier _name, _set_func, _get_func;
expression _arg, _mode;
@@
module_param_call(_name, _set_func, _get_func, _arg, _mode);
@fix_set_prototype
depends on match_module_param_call_function@
identifier match_module_param_call_function._set_func;
identifier _val, _param;
type _val_type, _param_type;
@@
int _set_func(
-_val_type _val
+const char * _val
,
-_param_type _param
+const struct kernel_param * _param
) { ... }
@fix_get_prototype
depends on match_module_param_call_function@
identifier match_module_param_call_function._get_func;
identifier _val, _param;
type _val_type, _param_type;
@@
int _get_func(
-_val_type _val
+char * _val
,
-_param_type _param
+const struct kernel_param * _param
) { ... }
Two additional by-hand changes are included for places where the above
Coccinelle script didn't notice them:
drivers/platform/x86/thinkpad_acpi.c
fs/lockd/svc.c
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jessica Yu <jeyu@kernel.org>
The pointer value is being assigned a value and this is never read, and later
on it is being assigned a new value. This the first assignment is redundant
and can be removed and hence also the variables report and report_list. Cleans
up the clang warning: Value stored to 'value' during its initialization is
never read
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The WACOM_PEN_FIELD macro is used to determine if a given HID field should be
associated with pen input. This field includes several known collection types
that Wacom pen data is contained in, but the WACOM_HID_WD_PEN application
collection type is notably missing. This can result in fields within this
kind of collection being completely ignored by the `wacom_usage_mapping`
function, preventing the later '*_event' functions from being notified about
changes to their value.
Fixes: c9c095874a ("HID: wacom: generic: Support and use 'Custom HID' mode and usages")
Fixes: ac2423c975 ("HID: wacom: generic: add vendor defined touch")
Cc: stable@vger.kernel.org
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The hid-rmi driver may handle non rmi devices on composite USB devices.
Callbacks need to make sure that the current device is a RMI device before
calling RMI specific functions. Most callbacks already have this check, but
this patch adds checks to the remaining callbacks.
Reported-by: Hendrik Langer <hendrik.langer@gmx.de>
Tested-by: Hendrik Langer <hendrik.langer@gmx.de>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The GamepadBlock game controller adapter needs HID_QUIRK_MULTI_INPUT
to split it up into two input devices. Without this quirk the
adapter is falsely recognized as only one device and mixes up the
inputs of the two connected controllers.
Signed-off-by: Florian Mueller <contact@petrockblock.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add new U1 device Product ID This device is used on HP Elite book x360 series.
[jkosina@suse.cz: update changelog]
Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
- Define T4 device specification value for support T4 device.
- Creeate "t4_contact_data" and "t4_input_report" structure for decoding and
storing T4-specific data
- Create "t4_calc_check_sum()" function for calculating checksum value to send
to the device. T4 needs to send this value when reading or writing device
address value.
- Create "t4_read_write_register()" function for reading and writing device
address value.
- Create "t4_raw_event()" function for decodin XYZ, palm and button data.
- Replace "MAX_TOUCHES" fixed variable to "max_fingers" variable.
- Add T4 devuce product ID. (0x120C)
T4 device is used on HP EliteBook 1000 series and Zbook Stduio
[jkosina@suse.cz: rewrite changelog]
Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Move dev_ctrl, dev_type, sen_line_num_x, sen_line_num_y, pitch_x, pitch_y,
resolution, btn_info from u1_dev structure to "u1_init()", because these
variables are only used in there.
[jkosina@suse.cz: rewrite changelog]
Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Create x_min, y_min and max_fingers variables for set correct XY minimum value
and the number of max finger on each devices.
[jkosina@suse.cz: update shortlog]
Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Create 'static int u1_init()' and factor out U1 device initialization code from
main initialization and introduce per-device 'has_sp' flag.
[jkosina@suse.cz: rewrite changelog]
Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull HID fixes from Jiri Kosina:
- fix for potential out-of-bounds memory access (found by fuzzing,
likely requires specially crafted device to trigger) by Jaejoong Kim
- two new device IDs for elecom driver from Alex Manoussakis
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: hid-elecom: extend to fix descriptor for HUGE trackball
HID: usbhid: fix out-of-bounds bug
Trivial fix to spelling mistake in hid_info message and add line break
to split an overly long line to clean up a checkpatch warning.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-By: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In addition to DEFT, Elecom introduced a larger trackball called HUGE, in
both wired (M-HT1URBK) and wireless (M-HT1DRBK) versions. It has the same
buttons and behavior as the DEFT. This patch adds the two relevant USB IDs
to enable operation of the three Fn buttons on the top of the device.
Cc: Diego Elio Petteno <flameeyes@flameeyes.eu>
Signed-off-by: Alex Manoussakis <amanou@gnu.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The hid descriptor identifies the length and type of subordinate
descriptors for a device. If the received hid descriptor is smaller than
the size of the struct hid_descriptor, it is possible to cause
out-of-bounds.
In addition, if bNumDescriptors of the hid descriptor have an incorrect
value, this can also cause out-of-bounds while approaching hdesc->desc[n].
So check the size of hid descriptor and bNumDescriptors.
BUG: KASAN: slab-out-of-bounds in usbhid_parse+0x9b1/0xa20
Read of size 1 at addr ffff88006c5f8edf by task kworker/1:2/1261
CPU: 1 PID: 1261 Comm: kworker/1:2 Not tainted
4.14.0-rc1-42251-gebb2c2437d80 #169
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:16
dump_stack+0x292/0x395 lib/dump_stack.c:52
print_address_description+0x78/0x280 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351
kasan_report+0x22f/0x340 mm/kasan/report.c:409
__asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
usbhid_parse+0x9b1/0xa20 drivers/hid/usbhid/hid-core.c:1004
hid_add_device+0x16b/0xb30 drivers/hid/hid-core.c:2944
usbhid_probe+0xc28/0x1100 drivers/hid/usbhid/hid-core.c:1369
usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
hub_port_connect drivers/usb/core/hub.c:4903
hub_port_connect_change drivers/usb/core/hub.c:5009
port_event drivers/usb/core/hub.c:5115
hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
worker_thread+0x221/0x1850 kernel/workqueue.c:2253
kthread+0x3a1/0x470 kernel/kthread.c:231
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Cc: stable@vger.kernel.org
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Jaejoong Kim <climbbb.kim@gmail.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
(introduced by 686fef928b ("timer: Prepare to change timer callback
argument type")) to pass the timer pointer explicitly. Adds pointer back to
hid_device for multitouch.
[jkosina@suse.cz: extend changelog a little bit as asked for by Benjamin]
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: linux-input@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This reverts commit 3e70969e44.
This commit causes a few problems for userspace. The most noteworthy are
problems related to the distinguishing of different pens and pointer jumps
when entering proximity. Userspace is written with the expectation that a
pen will provide its tool ID and serial number (if available) in the very
first in-prox report. By sending BTN_TOOL_PEN when the tablet starts
communicating rather than waiting until a tool ID/serial number is
available, userspace ends up treating all pens as being the same and
lacking a serial number. Similarly, userspace assumes that the first
report will contain X/Y data, but by marking the pen as being in-prox
without an X/Y coordinate, userspace ends up warping the pen to the last-
known X/Y location. As of commit 5b40104edf ("HID: wacom: generic: Reset
events back to zero when pen leaves") this means warping to (0,0).
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull HID subsystem fixes from Jiri Kosina:
- buffer management size fix for i2c-hid driver, from Adrian Salido
- tool ID regression fixes for Wacom driver from Jason Gerecke
- a few small assorted fixes and a few device ID additions
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
Revert "HID: multitouch: Support ALPS PTP stick with pid 0x120A"
HID: hidraw: fix power sequence when closing device
HID: wacom: Always increment hdev refcount within wacom_get_hdev_data
HID: wacom: generic: Clear ABS_MISC when tool leaves proximity
HID: wacom: generic: Send MSC_SERIAL and ABS_MISC when leaving prox
HID: i2c-hid: allocate hid buffers for real worst case
HID: rmi: Make sure the HID device is opened on resume
HID: multitouch: Support ALPS PTP stick with pid 0x120A
HID: multitouch: support buttons and trackpoint on Lenovo X1 Tab Gen2
HID: wacom: Correct coordinate system of touchring and pen twist
HID: wacom: Properly report negative values from Intuos Pro 2 Bluetooth
HID: multitouch: Fix system-control buttons not working
HID: add multi-input quirk for IDC6680 touchscreen
HID: wacom: leds: Don't try to control the EKR's read-only LEDs
HID: wacom: bits shifted too much for 9th and 10th buttons
pr_err() messages should terminated with a new-line to avoid
other messages being concatenated onto the end.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some tablets report eraser usage to indicate the eraser tool tip
is touching the surface. But, hidinput_configure_usage didn't
support the usage, which led it falls into default as ABS_MISC.
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Computes and forwards the device timestamp according to the specification.
Many devices use a 16-bit timestamp field, with a resolution of 100us,
therefore rolling around very frequently (every 6.5 seconds). To make sure
there is no ambiguity, the timestamp reported to the input stack reset to
0 whenever the time between 2 received events is greater than
MAX_TIMESTAMP_INTERVAL (1 second).
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add descriptive info to prompt string so that someone can know what
a Retrode is. Drop an unneeded blank line.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Bastien Nocera <hadess@hadess.net>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This reverts commit fcaa4a07d2.
As noted by Masaki [1], 0x120A + trackpoint will not be used in mass
production machines, so remove the ID accordingly.
[1] http://www.spinics.net/lists/linux-input/msg53222.html
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We should not try to bring HID device out of full power state before
calling hid_hw_close(), so that transport driver operates on powered up
device (making this inverse of the opening sequence).
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The wacom_get_hdev_data function is used to find and return a reference to
the "other half" of a Wacom device (i.e., the touch device associated with
a pen, or vice-versa). To ensure these references are properly accounted
for, the function is supposed to automatically increment the refcount before
returning. This was not done, however, for devices which have pen & touch
on different interfaces of the same USB device. This can lead to a WARNING
("refcount_t: underflow; use-after-free") when removing the module or device
as we call kref_put() more times than kref_get(). Triggering an "actual" use-
after-free would be difficult since both devices will disappear nearly-
simultaneously. To silence this warning and prevent the potential error, we
need to increment the refcount for all cases within wacom_get_hdev_data.
Fixes: 41372d5d40 ("HID: wacom: Augment 'oVid' and 'oPid' with heuristics for HID_GENERIC")
Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch adds support for Fn keys on Asus ROG G752 laptop.
The report descriptor is broken so I fixed it.
Tested on an Asus G752VT.
Resent fix white space fixes
Signed-off-by: Maxime Bellengé <maxime.bellenge@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
As a pen leaves, we need to be sure to reset all events back to zero
so that userspace is able to get the complete pen state when it enters
proximity again.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When a pen is first able to to be sensed by the tablet, we would like
to inform userspace that a tool is nearby so that it can attempt to
perform palm rejection. Unfortunately, we don't know any information
about the tool that is nearby, so the best we can do is send a prox
event for a generic BTN_TOOL_PEN. If the pen later comes closer and
enters proximity, we can determine the actual tool type and send
BTN_TOOL_PEN out of prox if necessary.
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The legacy Intuos codepath and tablet behavior (e.g. the 1st-gen Intuos
Pro, Cintiq 27, etc.) would result in a BTN_TOOL_* event not being cleared
to zero until the tool had completely left the sensing range of the
tablet. Before the final "out of prox" packet would be sent, zero or
more "in range" packets could be sent to indicate that a pen was still
detectable but not within a useful distance. These "in range" packets
were used by the driver to keep touch input disabled at greater pen
distances. In addition to keeping the `stylus_in_proximity` flag set,
the driver would leave the current BTN_TOOL_* marked as being in
proximity as well.
The new HID codepath also sets `stylus_in_proximity` based on the "sense"
flag, but does not leave the current BTN_TOOL_* marked as being in prox.
This information is potentially useful to for a future userspace-based
palm rejection, so this patch modifies the driver to continue sending it.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The terminology used to describe the various degrees of pen proximity
within the wacom_wac_pen_report function does not match that used elsewhere
in the generic codepath. Specifically, the names of the variables "prox"
and "range" were inspired by the non-generic codepaths. To make the generic
codepath internally consistent, replace these terms with "range" and "sense"
respectively.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The tool ID information sent in ABS_MISC is expected to be reset to 0
when a tool leaves proximity. Not doing this can cause problems if a
tool is removed and then re-introduced. Kernel event filtering will
prevent the (identical) ABS_MISC event from being sent when the tool
re-enters proxmity. This can cause userspace to not properly set the
tool ID.
Fixes: f85c9dc678 ("HID: wacom: generic: Support tool ID and additional tool types")
Cc: stable # v4.10 <stable@vger.kernel.org>
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The latest generation of pro devices (MobileStudio Pro, 2nd-gen Intuos
Pro, Cintiq Pro) send a serial number of '0' whenever the pen is too far
away for reliable communication. Userspace defines that a serial number
of '0' is invalid, so we need to be careful not to actually forward
this value. Additionally, since EMR ISDv4 devices do not support serial
numbers or tool IDs, we'd like to not send these events if they aren't
necessary.
The existing code achieves these goals by adding a check for a non-zero
serial number within the wacom_wac_pen_report function. The MSC_SERIAL
and ABS_MISC events are only sent if the serial number is non-zero. This
code fails, however when the pen for a pro device leaves proximity. When
the pen leaves prox and the tablet sends a serial of 0, wacom_wac_pen_event
dutifully clears the serial number. When wacom_wac_pen_report is called,
it does not send either the MSC_SERIAL of the exiting tool nor an ABS_MISC
event.
This patch prevents the wacom_wac_pen_event function from clearing an
already-set serial number. This ensures that we have the serial number
handy when exiting proximity, but requires us to manually clear it
afterwards to ensure the driver does not send stale data (e.g. when
switching between AES pens that report a serial nubmer of 0 for the
first few fully in-proximity packets).
Fixes: f85c9dc678 ("HID: wacom: generic: Support tool ID and additional tool types")
Cc: stable # v4.10 <stable@vger.kernel.org>
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The buffer allocation is not currently accounting for an extra byte for
the report id. This can cause an out of bounds access in function
i2c_hid_set_or_send_report() with reportID > 15.
Cc: stable@vger.kernel.org
Signed-off-by: Adrian Salido <salidoa@google.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
So it looks like that suspend/resume has actually always been broken on
hid-rmi. The fact it worked was a rather silly coincidence that was
relying on the HID device to already be opened upon resume. This means
that so long as anything was reading the /dev/input/eventX node for for
an RMI device, it would suspend and resume correctly. As well, if
nothing happened to be keeping the HID device away it would shut off,
then the RMI driver would get confused on resume when it stopped
responding and explode.
So, call hid_hw_open() in rmi_post_resume() so we make sure that the
device is alive before we try talking to it.
This fixes RMI device suspend/resume over HID.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196851
[jkosina@suse.cz: removed useless hunk that was zero-initializing 'ret']
Signed-off-by: Lyude <lyude@redhat.com>
Cc: Andrew Duggan <aduggan@synaptics.com>
Cc: stable@vger.kernel.org
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJZsSBoAAoJEAhfPr2O5OEVDc4QAJZSuVYmyLgvtmPxhyqgCvkz
I0DmWM4ZtK2VT/xJ/AA23z8IiLKi2+pDC0Xx6/aIiA665cyl3oPUdkKIaHW9Z6+A
fV8gSFkmGkluQb9mP/KdHYI2oSeEv2ivCa1kfaApYcoBa904z8uU++z15Iu5p/+m
fjpc2vnc9rax0Vuwmgv7p1CL4j4e/ja0siCSCGbu2ad50KqP4ytnBooNPQOQt89D
L+Av5MeGml/CTUUnAFjWfSmQ72Ht8GhoBBKc6wGoq9x3GTckDDTqy8BAqGt4UQnu
fR0mb71zuSVmTjxRe7tc/74m3ReaeSHzQeHJhjdQslvNmV3RVQgk/6CCsmqNEegr
rbC3glQCM+gp5YywCjRL6DCPsoqvjexLtPQjMZIGYxgSYQUyXGOxilgmj9+73761
6aOl0nqdgN+vlWzaSeDF9EQxRsc+cCq/Po8/xuPE/Pzs6zTQwU+6b+ADLf9jCyDP
LTC49wOj24SoWiTlG1FTct2ogZ3h5wNPWlurBtmyiFJn+43RpsH5IW9wLilCjeiE
6JeCWEIBglCCq/TVCzETKNSaixDL6/lMQ9uRdCpIO4VLyoS6S9pZASNPBmQ1h7h/
oTjYDeWirIthNOccstbBoJQYSX62CqAIW3wq5ME6PAgM+ioiLXLYk0fV3yBKoBNW
Z0SBeTcuPxWmfzuxMtik
=fNM2
-----END PGP SIGNATURE-----
Merge tag 'media/v4.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab:
"Brazil's Independence Day pull request :-)
This is one of the biggest media pull requests, with 625 patches
affecting almost all parts of media (RC, DVB, V4L2, CEC, docs).
This contains:
- A lot of new drivers:
* DVB frontends: mxl5xx, stv0910, stv6111;
* camera flash: as3645a led driver;
* HDMI receiver: adv748X;
* camera sensor: Omnivision 6650 5M driver (ov6650);
* HDMI CEC: ao-cec meson driver;
* V4L2: Qualcom camss driver;
* Remote controller: gpio-ir-tx, pwm-ir-tx and zx-irdec drivers.
- The DDbridge DVB driver got a massive update, with makes it in sync
with modern hardware from that vendor;
- There's an important milestone on this series: the DVB
documentation was written in 2003, but only started to be updated
in 2007. It also used to contain several gaps from the time it was
kept out of tree, mentioning error codes and device nodes that
never existed upstream. On this series, it received a massive
update: all non-deprecated digital TV APIs are now in sync with the
current implementation;
- Some DVB APIs that aren't used by any upstream driver got removed;
- Other parts of the media documentation algo got updated, fixing
some bugs on its PDF output and making it compatible with Sphinx
version 1.6.
As the number of hacks required to build PDF output reduced, I hope
we'll have less troubles as newer versions of our documentation
toolchain are released (famous last words);
- As usual, lots of driver cleanups and improvements"
* tag 'media/v4.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (624 commits)
media: leds: as3645a: add V4L2_FLASH_LED_CLASS dependency
media: get rid of removed DMX_GET_CAPS and DMX_SET_SOURCE leftovers
media: Revert "[media] v4l: async: make v4l2 coexist with devicetree nodes in a dt overlay"
media: staging: atomisp: sh_css_calloc shall return a pointer to the allocated space
media: Revert "[media] lirc_dev: remove superfluous get/put_device() calls"
media: add qcom_camss.rst to v4l-drivers rst file
media: dvb headers: make checkpatch happier
media: dvb uapi: move frontend legacy API to another part of the book
media: pixfmt-srggb12p.rst: better format the table for PDF output
media: docs-rst: media: Don't use \small for V4L2_PIX_FMT_SRGGB10 documentation
media: index.rst: don't write "Contents:" on PDF output
media: pixfmt*.rst: replace a two dots by a comma
media: vidioc-g-fmt.rst: adjust table format
media: vivid.rst: add a blank line to correct ReST format
media: v4l2 uapi book: get rid of driver programming's chapter
media: format.rst: use the right markup for important notes
media: docs-rst: cardlists: change their format to flat-tables
media: em28xx-cardlist.rst: update to reflect last changes
media: v4l2-event.rst: adjust table to fit on PDF output
media: docs: don't show ToC for each part on PDF output
...
This patch adds ALPS PTP sticks with pid/device id 0x120A to the list of
devices supported by hid-multitouch.
Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
On the 2nd generation Lenovo Tablet only clickpad is working; the
trackpoint and three mouse buttons do not work.
hid_multitouch must export all inputs in order to get trackpoint and
buttons to function.
Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The MobileStudio Pro, Cintiq Pro, and 2nd-gen Intuos Pro devices use a
different coordinate system for their touchring and pen twist than prior
devices. Prior devices had zero aligned to the tablet's left and would
increase clockwise. Userspace expects data from the kernel to be in this
old coordinate space, so adjustments are necessary.
While the coordinate system for pen twist is formally defined by the HID
standard, no such definition existed for the touchring at the time these
tablets were introduced. Future tablets are expected to report touchring
data using the same "zero-up clockwise-increasing" coordinate system
defined for twist.
Fixes: 50066a042d ("HID: wacom: generic: Add support for height, tilt, and twist usages")
Fixes: 4922cd26f0 ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
Fixes: 60a2218698 ("HID: wacom: generic: add support for touchring")
Cc: stable@vger.kernel.org # 4.10, 4.11
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The wacom driver's IRQ handler for Bluetooth reports from the 2nd-gen
Intuos Pro does not correctly process negative numbers. Values for
tilt and rotation (which can go negative) are instead interpreted as
unsigned and so jump to very large values when the data should be
negative. This commit properly casts the data to ensure we report
negative numbers when necessary.
Fixes: 4922cd2 ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
Cc: stable@vger.kernel.org # v4.11
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Don't populate array cbuf on the stack, instead make it static.
Makes the object code smaller by over 110 bytes:
Before:
text data bss dec hex filename
15096 3504 128 18728 4928 drivers/hid/hid-lg.o
After:
text data bss dec hex filename
14884 3600 128 18612 48b4 drivers/hid/hid-lg.o
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Make this const as it is only passed as an argument to the function
device_create_file and device_remove_file and the corresponding arguments are
of type const. Done using Coccinelle
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some laptops have system-control buttons (e.g. KEY_SLEEP) on the same
interface as a hid-multitouch touch-pad.
This commit fixes these buttons not working.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Ideacom 6680 touchscreen is found in the Dell Latitude 2100. It
has two USB descriptors, the first of which has two input reports. The
HID_QUIRK_MULTI_INPUT quirk is needed to keep the correct maximum
value for ABS_X/ABS_Y (8191 instead of 65535).
Signed-off-by: Nicholas Bishop <nbishop@neverware.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit a50aac7193 introduces 'led.groups' and adds EKR support
for these groups. However, unlike the other devices with LEDs,
the EKR's LEDs are read-only and we shouldn't attempt to control
them in wacom_led_control().
See bug: https://sourceforge.net/p/linuxwacom/bugs/342/
Fixes: a50aac7193 ("HID: wacom: leds: dynamically allocate LED groups")
Cc: stable <stable@vger.kernel.org> # 4.9
Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Cintiq 12 has 10 expresskey buttons. The bit shift for the last
two buttons were off by 5.
Fixes: c7f0522 ("HID: wacom: Slim down wacom_intuos_pad processing")
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Tested-by: Matthieu Robin <matthieu@macolu.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
- support for media keys on Asus T304UA from João Paulo Rechi Vita
- support for Microsoft Win8 Wireless Radio Controls extensions
from João Paulo Rechi Vita
Conflicts:
drivers/hid/hid-ids.h
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
- Arnd pointed out that driver_lock semaphore is superfluous, as
driver core already provides all the necessary concurency protection.
Removal patch from Binoy Jayan
RC_TYPE is confusing and it's just the protocol. So rename it.
Suggested-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Sean Young <sean@mess.org>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
When an ir-spi is registered, you get this message.
rc rc0: Unspecified device as /devices/platform/soc/3f215080.spi/spi_master/spi32766/spi32766.128/rc/rc0
"Unspecified device" refers to input_name, which makes no sense for IR
TX only devices. So, rename to device_name.
Also make driver_name const char* so that no casts are needed anywhere.
Now ir-spi reports:
rc rc0: IR SPI as /devices/platform/soc/3f215080.spi/spi_master/spi32766/spi32766.128/rc/rc0
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This snd_rawmidi_ops structure is only passed as the third
argument of snd_rawmidi_set_ops. This argument is const, so the
snd_rawmidi_ops structure can be const too.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
platform_device_id are not supposed to change at runtime. All functions
working with platform_device_id provided by <linux/platform_device.h>
work with const platform_device_id. So mark the non-const structs as
const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The power_supply subsystem tends to emit uevent every time
power_supply_changed() is called, so we should call this API only when battery
strength reported by the device is actually different from the previous
readings, otherwise we'll drown the system in uevents.
Fixes: 581c448476 ("HID: input: map digitizer battery usage")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by <linux/usb.h> work with
const usb_device_id. So mark the non-const structs as const.
Fix checkpatch.pl error:
ERROR: space prohibited before open square bracket '['.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by <linux/usb.h> work with
const usb_device_id. So mark the non-const structs as const.
Fix checkpatch.pl error:
ERROR: space prohibited before open square bracket '['.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In the reference HID sensor hub firmware all Named array enums were
0-based. There is no description of the default base of enums in HID
sensor hub specification as logical minimum should have set this base
value.
Every sensor hub implemented enum as 1-based, without explicitly setting
logical minimum to 1, because of the implementation by one of the major
OS vendor. In Linux we used logical minimum to decide the enum base.
Some sensor hub FWs already changed logical minimum from 0 to 1. We hoped
that every other vendor will follow. But that didn't happen and we had to
fix the report header for every sensor hub to change logical minimum to 1
by using .report_fixup() callback. So for every new sensor hub we had to
modify source code by adding this quirk based on the vendor and device id.
This is becoming a maintenance burden.
This patch hardcodes the logical minimum of power and report state
attributes to 1. In this way we can remove the existing quirks and also
we don't have to add more quirks.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The WACOM_HID_WD_TOUCHRINGSTATUS usage is a single bit which tells us
whether the touchring is currently in use or not. Because we need to
reset the axis value to 0 when the finger is removed, we call
'wacom_map_usage' to ensure that the required type/code values are
associated with the usage. The 'wacom_map_usage' also sets up the axis
range and resolution, however, which is not desired in this particular
case.
Although xf86-input-wacom doesn't do really do anything with the ring's
range or resolution, the libinput driver (for Wayland environments)
uses these values to provide proper angle indications to userspace.
Fixes: 60a2218698 ("HID: wacom: generic: add support for touchring")
Cc: stable@vger.kernel.org
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Put the touchpad in native (absolute coordinate mode) and export it to
userspace as a touchpad rather then as a mouse.
Note this requires HID_QUIRK_MULTI_INPUT as the T100CHI keyboard dock
has all functionality on a single HID interface and userspace expects
touchpads to be on a separate input_dev. Without MULTI_INPUT userspace
will ignore the keyboard part of the keyboard/touchpad combo.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by <linux/sysfs.h> work with
const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by <linux/sysfs.h> work with
const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by <linux/sysfs.h> work with
const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by <linux/sysfs.h> work with
const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
0xff310076 application has been defined by 957b8dffa4 ("HID: multitouch:
Support Asus T304UA media keys") as a vendor-specific application with
symbolic constant HID_VD_ASUS_CUSTOM_MEDIA_KEYS, so let's make use of
it.
Fixes: 957b8dffa4 ("HID: multitouch: Support Asus T304UA media keys")
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Asus T304UA convertible sports a magnetic detachable keyboard with
touchpad, which is connected over USB. Most of the keyboard hotkeys are
exposed through the same USB interface as the touchpad, defined in the
report descriptor as follows:
0x06, 0x31, 0xFF, // Usage Page (Vendor Defined 0xFF31)
0x09, 0x76, // Usage (0x76)
0xA1, 0x01, // Collection (Application)
0x05, 0xFF, // Usage Page (Reserved 0xFF)
0x85, 0x5A, // Report ID (90)
0x19, 0x00, // Usage Minimum (0x00)
0x2A, 0xFF, 0x00, // Usage Maximum (0xFF)
0x15, 0x00, // Logical Minimum (0)
0x26, 0xFF, 0x00, // Logical Maximum (255)
0x75, 0x08, // Report Size (8)
0x95, 0x0F, // Report Count (15)
0xB1, 0x02, // Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0x05, 0xFF, // Usage Page (Reserved 0xFF)
0x85, 0x5A, // Report ID (90)
0x19, 0x00, // Usage Minimum (0x00)
0x2A, 0xFF, 0x00, // Usage Maximum (0xFF)
0x15, 0x00, // Logical Minimum (0)
0x26, 0xFF, 0x00, // Logical Maximum (255)
0x75, 0x08, // Report Size (8)
0x95, 0x02, // Report Count (2)
0x81, 0x02, // Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0xC0, // End Collection
This UsagePage is declared as a variable, but we need to treat it as an
array to be able to map each Usage we care about to its corresponding
input key.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some keyboard + touchpad devices have the Microsoft Win8 Wireless Radio
Controls extensions Usage Page define in the touchpad report descriptor,
so we need to support them in this driver.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Manufacturers do not always populate serial number in their devices, so
let's fall back to device ID when forming the battery device name. As a
result, batteries in devices without serial number will be named like
this:
hid-0018:2D1F:510E.0001-battery
(as opposed to hid--battery for the first one, and failing to create
batteries for the subsequent ones).
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We already mapped battery strength reports from the generic device
control page, but we did not update capacity from input reports, nor we
mapped the battery strength report from the digitizer page, so let's
implement this now.
Batteries driven by the input reports will now start in "unknown" state,
and will get updated once we receive first report containing battery
strength from the device.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The semaphore 'driver_lock' is used as a simple mutex, and also unnecessary as
suggested by Arnd. Hence removing it, as the concurrency between the probe and
remove is already handled in the driver core.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Binoy Jayan <binoy.jayan@linaro.org>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The driver has gained a compile-time dependency that we should
express in Kconfig to avoid this link error:
drivers/hid/wacom_sys.o: In function `wacom_parse_and_register':
wacom_sys.c:(.text+0x2eec): undefined reference to `usb_hid_driver'
Fixes: 09dc28acae ("HID: wacom: Improve generic name generation")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Without a quirk or the X Window System, this device disconnects every
60 seconds. This patch also renames the define associated with the
Logitech 0xc007 product ID, which appeared to have a conflicting typo.
Cc: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Kyle Roarty <kroarty@xes-inc.com>
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The 'wacom_update_name' function is responsible for producing names for
the input device nodes based on the hardware device name. Commit f2209d4
added the ability to strip off prefixes like "Wacom Co.,Ltd." where the
prefix was immediately (and redundantly) followed by "Wacom". The
2nd-generation Intuos Pro 2 has such a prefix, but with a small error
(the period and comma are swapped) that prevents the existing code from
matching it. We're loath to extend the number of cases out endlessly and
so instead try to be smarter about name generation.
We observe that the cause of the redundant prefixes is HID combining the
manufacturer and product strings of USB devices together. By using the
original product name (with "Wacom" prefixed, if it does not already
exist in the string) we can bypass the gyrations to find and remove
redundant prefixes. Other devices either don't have a manufacturer string
that needs to be removed (Bluetooth, uhid) or should have their name
generated from scratch (I2C).
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Acked-By: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Although HID itself is transport-agnostic, occasionally a driver may
want to interact with the low-level transport that a device is connected
through. To do this, we need to know what kind of bus is in use. The
first guess may be to look at the 'bus' field of the 'struct hid_device',
but this field may be emulated in some cases (e.g. uhid).
More ideally, we can check which ll_driver a device is using. This
function introduces a 'hid_is_using_ll_driver' function and makes the
'struct hid_ll_driver' of the four most common transports accessible
through hid.h.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Acked-By: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The iHome keypad also requires the same tweak we are doing for other
Ortek devices.
Reported-by: Mairin Duffy <duffy@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Even though the IO for devices with "always poll" quirk is already running,
we still need to set HID_OPENED bit in usbhid->iofl so the interrupt
handler does not ignore the data coming from the device.
Reported-by: Olof Johansson <olof@lixom.net>
Tested-by: Olof Johansson <olof@lixom.net>
Fixes: e399396a6b ("HID: usbhid: remove custom locking from usbhid_open...")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Asus Transformer T100CHI comes with a Bluetooth keyboard dock which
uses the same 0xff31 Asus vendor HUT page as other Asus keyboards.
This commit adds its device-id to hid-asus and fixes an issue in the
descriptor of the 0xff31 Usage, which together fixes the special keys
on this keyboard not working.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The touchpad code is only used with the T100TA touchpad which
measures 75.5 x 41.5 mm, add corresponding resolution info.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When adding the initial support I only looked at the maximum coordinates
but the Y axis is inverted, so I should have checked the minimum
coodinates which never reach 0 due to max_y being wrong, fix this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Instead of having hardcoded (#define-d) values use a struct describing
the various touchpad parameters. This is a preparation patch for
improving the T100TA touchpad support as well as for adding T100CHI
touchpad support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add support for the Asus T100 touchpad in multi-touch mode (rather
then mouse emulation mode). It turns out that the Asus T100 touchpad
is identical to the already supported i2c-hid Asus touchpads, so
adding support for it was easy.
The only significant difference is that the reported x-coordinates
range on the T100 touchpad is somewhat lower then the range on the
already supported touchpads.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Check return value from call to devm_kmemdup() in order to prevent a NULL
pointer dereference.
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Variable mode in method wacom_show_remote_mode() is defined as u8, thus
statement (mode >= 0) is always true and should be removed, simplifying
the logic.
Signed-off-by: Christos Gkekas <chris.gekas@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Now that input core insists on having dev->absinfo when device claims to
generate EV_ABS in its dev->evbit, we should not be blindly setting that
bit.
The code in question might have been needed before input_set_abs_params()
started setting EV_ABS in device's evbit, but not anymore, and is now
breaking devices such as SMART SPNL-6075 Touchscreen.
Fixes: 6ecfe51b40 ("Input: refuse to register absolute devices ...")
Reported-by: Matthias Fend <Matthias.Fend@wolfvision.net>
Tested-by: Matthias Fend <Matthias.Fend@wolfvision.net>
Cc: stable@vger.kernel.org
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull HID updates from Jiri Kosina:
- open/close tracking improvements from Dmitry Torokhov
- battery support improvements in Wacom driver from Jason Gerecke
- Win8 support fixes from Benjamin Tissories and Hans de Geode
- misc fixes to Intel-ISH driver from Arnd Bergmann
- support for quite a few new devices and small assorted fixes here and
there
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (35 commits)
HID: intel-ish-hid: Enable Gemini Lake ish driver
HID: intel-ish-hid: Enable Cannon Lake ish driver
HID: wacom: fix mistake in printk
HID: multitouch: optimize the sticky fingers timer
HID: multitouch: fix rare Win 8 cases when the touch up event gets missing
HID: multitouch: use BIT macro
HID: Add driver for Retrode2 joypad adapter
HID: multitouch: Add support for Google Rose Touchpad
HID: multitouch: Support PTP Stick and Touchpad device
HID: core: don't use negative operands when shift
HID: apple: Use country code to detect ISO keyboards
HID: remove no longer used hid->open field
greybus: hid: remove custom locking from gb_hid_open/close
HID: usbhid: remove custom locking from usbhid_open/close
HID: i2c-hid: remove custom locking from i2c_hid_open/close
HID: serialize hid_hw_open and hid_hw_close
HID: usbhid: do not rely on hid->open when deciding to do IO
HID: hiddev: use hid_hw_power instead of usbhid_get/put_power
HID: hiddev: use hid_hw_open/close instead of usbhid_open/close
HID: asus: Add support for Zen AiO MD-5110 keyboard
...
Here is the big driver core update for 4.13-rc1.
The large majority of this is a lot of cleanup of old fields in the
driver core structures and their remaining usages in random drivers.
All of those fixes have been reviewed by the various subsystem
maintainers. There's also some small firmware updates in here, a new
kobject uevent api interface that makes userspace interaction easier,
and a few other minor things.
All of these have been in linux-next for a long while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCWVpX4A8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymobgCfd0d13IfpZoq1N41wc6z2Z0xD7cwAnRMeH1/p
kEeISGpHPYP9f8PBh9FO
=Hfqt
-----END PGP SIGNATURE-----
Merge tag 'driver-core-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH:
"Here is the big driver core update for 4.13-rc1.
The large majority of this is a lot of cleanup of old fields in the
driver core structures and their remaining usages in random drivers.
All of those fixes have been reviewed by the various subsystem
maintainers. There's also some small firmware updates in here, a new
kobject uevent api interface that makes userspace interaction easier,
and a few other minor things.
All of these have been in linux-next for a long while with no reported
issues"
* tag 'driver-core-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (56 commits)
arm: mach-rpc: ecard: fix build error
zram: convert remaining CLASS_ATTR() to CLASS_ATTR_RO()
driver-core: remove struct bus_type.dev_attrs
powerpc: vio_cmo: use dev_groups and not dev_attrs for bus_type
powerpc: vio: use dev_groups and not dev_attrs for bus_type
USB: usbip: convert to use DRIVER_ATTR_RW
s390: drivers: convert to use DRIVER_ATTR_RO/WO
platform: thinkpad_acpi: convert to use DRIVER_ATTR_RO/RW
pcmcia: ds: convert to use DRIVER_ATTR_RO
wireless: ipw2x00: convert to use DRIVER_ATTR_RW
net: ehea: convert to use DRIVER_ATTR_RO
net: caif: convert to use DRIVER_ATTR_RO
TTY: hvc: convert to use DRIVER_ATTR_RW
PCI: pci-driver: convert to use DRIVER_ATTR_WO
IB: nes: convert to use DRIVER_ATTR_RW
HID: hid-core: convert to use DRIVER_ATTR_RO and drv_groups
arm: ecard: fix dev_groups patch typo
tty: serdev: use dev_groups and not dev_attrs for bus_type
sparc: vio: use dev_groups and not dev_attrs for bus_type
hid: intel-ish-hid: use dev_groups and not dev_attrs for bus_type
...
- introduce the new uuid_t/guid_t types that are going to replace
the somewhat confusing uuid_be/uuid_le types and make the terminology
fit the various specs, as well as the userspace libuuid library.
(me, based on a previous version from Amir)
- consolidated generic uuid/guid helper functions lifted from XFS
and libnvdimm (Amir and me)
- conversions to the new types and helpers (Amir, Andy and me)
-----BEGIN PGP SIGNATURE-----
iQI/BAABCAApFiEEgdbnc3r/njty3Iq9D55TZVIEUYMFAllZfmILHGhjaEBsc3Qu
ZGUACgkQD55TZVIEUYMvyg/9EvWHOOsSdeDykCK3KdH2uIqnxwpl+m7ljccaGJIc
MmaH0KnsP9p/Cuw5hESh2tYlmCYN7pmYziNXpf/LRS65/HpEYbs4oMqo8UQsN0UM
2IXHfXY0HnCoG5OixH8RNbFTkxuGphsTY8meaiDr6aAmqChDQI2yGgQLo3WM2/Qe
R9N1KoBWH/bqY6dHv+urlFwtsREm2fBH+8ovVma3TO73uZCzJGLJBWy3anmZN+08
uYfdbLSyRN0T8rqemVdzsZ2SrpHYkIsYGUZV43F581vp8e/3OKMoMxpWRRd9fEsa
MXmoaHcLJoBsyVSFR9lcx3axKrhAgBPZljASbbA0h49JneWXrzghnKBQZG2SnEdA
ktHQ2sE4Yb5TZSvvWEKMQa3kXhEfIbTwgvbHpcDr5BUZX8WvEw2Zq8e7+Mi4+KJw
QkvFC1S96tRYO2bxdJX638uSesGUhSidb+hJ/edaOCB/GK+sLhUdDTJgwDpUGmyA
xVXTF51ramRS2vhlbzN79x9g33igIoNnG4/PV0FPvpCTSqxkHmPc5mK6Vals1lqt
cW6XfUjSQECq5nmTBtYDTbA/T+8HhBgSQnrrvmferjJzZUFGr/7MXl+Evz2x4CjX
OBQoAMu241w6Vp3zoXqxzv+muZ/NLar52M/zbi9TUjE0GvvRNkHvgCC4NmpIlWYJ
Sxg=
=J/4P
-----END PGP SIGNATURE-----
Merge tag 'uuid-for-4.13' of git://git.infradead.org/users/hch/uuid
Pull uuid subsystem from Christoph Hellwig:
"This is the new uuid subsystem, in which Amir, Andy and I have started
consolidating our uuid/guid helpers and improving the types used for
them. Note that various other subsystems have pulled in this tree, so
I'd like it to go in early.
UUID/GUID summary:
- introduce the new uuid_t/guid_t types that are going to replace the
somewhat confusing uuid_be/uuid_le types and make the terminology
fit the various specs, as well as the userspace libuuid library.
(me, based on a previous version from Amir)
- consolidated generic uuid/guid helper functions lifted from XFS and
libnvdimm (Amir and me)
- conversions to the new types and helpers (Amir, Andy and me)"
* tag 'uuid-for-4.13' of git://git.infradead.org/users/hch/uuid: (34 commits)
ACPI: hns_dsaf_acpi_dsm_guid can be static
mmc: sdhci-pci: make guid intel_dsm_guid static
uuid: Take const on input of uuid_is_null() and guid_is_null()
thermal: int340x_thermal: fix compile after the UUID API switch
thermal: int340x_thermal: Switch to use new generic UUID API
acpi: always include uuid.h
ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()
ACPI / extlog: Switch to use new generic UUID API
ACPI / bus: Switch to use new generic UUID API
ACPI / APEI: Switch to use new generic UUID API
acpi, nfit: Switch to use new generic UUID API
MAINTAINERS: add uuid entry
tmpfs: generate random sb->s_uuid
scsi_debug: switch to uuid_t
nvme: switch to uuid_t
sysctl: switch to use uuid_t
partitions/ldm: switch to use uuid_t
overlayfs: use uuid_t instead of uuid_be
fs: switch ->s_uuid to uuid_t
ima/policy: switch to use uuid_t
...
Added PCI ID for Gemini Lake ISH.
Signed-off-by: Song Hongyan <hongyan.song@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Added PCI ID for Cannon Lake ISH.
Signed-off-by: Song Hongyan <hongyan.song@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
trivial fix to spelling mistake in hid_warn warning message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Instead of unconditionally expiring the timer and calling a long
mt_release_contacts(), we can check if some slots are used when the
timer expires.
We can also remove the timer if we happen to receive all the releases.
The logic behind the MT_IO_FLAGS_PENDING_SLOTS could be implemented by
counting how many slots are active, but using bits feels slightly more
efficient.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Arek Burdach <arek.burdach@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Instead of blindly trusting the hardware to send us release, we should
consider some events can get lost and release them when we judge time has
come.
The Windows 8 spec allows to be confident in the fact that the device
will continuously report events when a finger touches the surface.
This has been tested on the HID recording database I have, and all of
those devices behave properly.
Also, Arek tested it on his Lenovo Yoga 910, which exports such bug in
some situations, when the movements are rather slow.
We use an atomic bit here to guard against concurrent accesses to the mt
slots because both mt_process_mt_event() and mt_expired_timeout() are
called in interrupt context.
Signed-off-by: Arek Burdach <arek.burdach@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Arek Burdach <arek.burdach@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
(1 << X) is wrong. We should use BIT(X)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Arek Burdach <arek.burdach@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This driver does 2 things:
- Apply the MULTI_INPUT quirk to create separate joypad device nodes
for each one of the 4 connectors.
- Rename the input devices so that their names are different, and allow
users to recognise which device corresponds to which physical port,
including the SNES (Mario Paint) Mouse.
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add Google Rose Touchpad USB PID and required quirks.
Signed-off-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Support PTP Stick and Touchpad device. This Touchpad is Precision Touchpad
(PTP), and Stick Pointer data is the same as Mouse; Stick Pointer works as
Mouse.
[jkosina@suse.cz: changelog deuglification]
Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Setting these bits causes libinput to fail to initialize the device;
setting BTN_TOUCH and BTN_TOOL_FINGER causes it to treat the mouse as a
touchpad, and it then refuses to continue when it discovers ABS_X is not
set.
This breaks all known Wayland compositors, as well as Xorg when the
libinput driver is being used.
This reverts commit f4b65b9563.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Cc: Che-Liang Chiou <clchiou@chromium.org>
Cc: Thierry Escande <thierry.escande@collabora.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There are many situations where generic HID driver provides some basic level
of support for certain device, but later this support (usually by implementing
vendor-specific extensions of HID protocol) is extended and the support moved
over to a separate (usually per-vendor) specific driver.
This might bring a rather unpleasant suprise for users, as all of a sudden
there is a new config option they have to enable in order to get any support
for their device whatsoever, although previous kernel versions provided basic
support through the generic driver. Which is rightfully seen as a regression.
Fix this by including the entry for a particular device in
hid_have_special_driver[] iff the specific config option has been specified,
and let generic driver handle the device otherwise.
Also make the behavior of hid_scan_report() (where the same decision is being
taken on a per-report level) consistent.
While at it, reshuffle the hid_have_special_driver[] a bit to restore the
alphabetical ordering (first order by config option, and within those
sections order by VID).
This is considered a short-term solution, before generic way of giving
precedence to special drivers and falling back to generic driver is
figured out.
While at it, fixup a missing entry for GFRM driver; thanks to Hans de Geode for
spotting this (and for discovering a few issues in the conversion).
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The recent C standard in 6.5.7 paragraph 4 defines that operands for
bitwise shift operators should be non-negative, otherwise it's an
undefined behaviour.
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In the quest to get rid of DRIVER_ATTR(), this patch converts the
hid-core code to use DRIVER_ATTR_RO() and also moves to use drv_groups
as creating individual sysfs files is not good (it races with userspace
notifications.)
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: <linux-input@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The dev_attrs field has long been "depreciated" and is finally being
removed, so move the driver to use the "correct" dev_groups field
instead for struct bus_type.
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Wei Yongjun <weiyj.lk@gmail.com>
Cc: Bhumika Goyal <bhumirks@gmail.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: <linux-input@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
At least on newer laptops, Apple uses the same USB ID for both ISO and
ANSI keyboards. However, they have been good about filling in the
bCountryCode field in the HID descriptor on all of their keyboards. A
value of 13 indicates an ISO layout and other values indicate various
country-specific ANSI layouts.
With this patch, users of Apple US keyboards will no longer have to run
`echo 0 > /sys/module/hid_apple/parameters/iso_layout` to get a working
tilde key.
Please test this patch and send feedback if you have a Macbook or an
Apple keyboard.
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Now that HID core enforces serialization of transport driver open/close
calls we can remove custom locking from usbhid driver.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Now that HID core enforces serialization of transport driver open/close
calls we can remove custom locking from i2c-hid driver.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The HID transport drivers either re-implement exactly the same logic
(usbhid, i2c-hid) or forget to implement it (usbhid) which causes issues
when the same device is accessed via multiple interfaces (for example input
device through evdev and also hidraw). Let's muve the locking logic into
HID core to make sure the serialized behavior is always enforced.
Also let's uninline and move hid_hw_start() and hid_hw_stop() into hid-core
as hid_hw_start() is somewhat large and do not believe we get any benefit
from these two being inline.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Instead of checking hid->open (that we plan on having HID core manage) in
hid_start_in(), let's allocate a couple of new flags: HID_IN_POLLING and
HID_OPENED, and use them to decide whether we should be submitting URBs or
not.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Instead of calling into usbhid code directly, let's use the standard
accessors for the transport HID drivers, and stop clobbering their error
codes with -EIO.
This also allows us to remove usbhid_get/put_power(), leaving only
usbhid_power().
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Instead of calling into usbhid code directly, let's use the standard
accessors for the transport HID drivers, and stop clobbering their errors
with -EIO.
This also allows us make usbhid_open and close static.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add support for media keys on the MD-5110 wireless keyboard that comes
with the Asus V221ID and ZN241IC All In One computers.
The keys to support here are WLAN, BRIGHTNESSDOWN and BRIGHTNESSUP.
The USB Vendor ID suggests that it is a TURBOX device, but
the physical branding only mentions ASUS MD-5110.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Acked-by: Benjamin Tissoires <benajmin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Asus AIO keyboard AK1D was added to hid-chicony based on its
USB vendor ID, however images available online suggest that this keyboard
is physically branded as ASUS with no mention of Chicony.
A recent commit also added support for another Asus AIO keyboard into
hid-chicony, this one with USB vendor ID Jess, and a pending review
comment asked me to move it into hid-asus because it is also only
physically branded as ASUS.
I updated the USB ID defines to match the branding and product name,
including noting that the recently added keyboard is labelled as
ASUS MD-5112.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Acked-by: Benjamin Tissoires <benajmin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
bytes. Instead we convert them to use guid_t type. At the same time we
convert current users.
acpi_str_to_uuid() becomes useless after the conversion and it's safe to
get rid of it.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Cc: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Joerg Roedel <jroedel@suse.de>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This mouse is also known under other IDs. It needs the quirk
ALWAYS_POLL or will disconnect in runlevel 1 or 3.
Signed-off-by: Sebastian Parschauer <sparschauer@suse.de>
CC: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull HID fixes from Jiri Kosina:
- corner-case oops fixes for Asus and Wacom drivers from Carlo Caione
and Jason Gerecke
- power management fix (reported on SIS0817 touchscreen) for i2c-hid
devices from Hans de Goede
- device-id-specific fixes and quirks from Hans de Goede, Diego Elio
Pettenò and Che-Liang Chiou
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: asus: Stop underlying hardware on remove
HID: i2c: Call acpi_device_fix_up_power for ACPI-enumerated devices
HID: asus: Add support for T100 keyboard
HID: elecom: extend to fix the descriptor for DEFT trackballs
HID: magicmouse: Set multi-touch keybits for Magic Mouse
HID: wacom: Have wacom_tpc_irq guard against possible NULL dereference
We are missing a call to hid_hw_stop() on the remove hook.
Among other things this is causing an Oops when (re-)starting GNOME /
upowerd / ... after the module has been already rmmod-ed.
Signed-off-by: Carlo Caione <carlo@endlessm.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
To increase build coverage, drivers should generally be allowed to
build on other architectures even if they are only used on one
of them.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When building for 32-bit architectures, we get a harmless warning:
intel-ish-hid/ishtp-hid-client.c: In function 'process_recv':
intel-ish-hid/ishtp-hid-client.c:139:7: error: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'unsigned int' [-Werror=format=]
This changes the format string to print size_t variables using %zu
instead.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The internal accounting uses 'timespec' based time stamps, which is
slightly inefficient and also problematic once we get to the time_t
overflow in 2038.
When communicating to the firmware, we even get an open-coded 64-bit
division that prevents the code from being build-tested on 32-bit
architectures and is inefficient due to the double conversion from
64-bit nanoseconds to seconds+nanoseconds and then microseconds.
This changes the code to use ktime_t instead.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
I was trying to understand this code while working on a warning
fix and the locking made no sense: spin_lock_irqsave() is pointless
when run inside of an interrupt handler or nested inside of another
spin_lock_irq() or spin_lock_irqsave().
Here it turned out that the comment above the function is wrong,
as both recv_ishtp_cl_msg_dma() and recv_ishtp_cl_msg() can in fact
be called from a work queue rather than an ISR, so we do have to
use the irqsave() version once.
This fixes the comments accordingly, removes the misleading 'dev_flags'
variable and modifies the inner spinlock to not use 'irqsave'.
No functional change is intended, this is just for readability and
it slightly simplifies the object code.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
gcc points out an uninialized pointer dereference that could happen
if we ever get to recv_ishtp_cl_msg_dma() or recv_ishtp_cl_msg()
with an empty &dev->read_list:
drivers/hid/intel-ish-hid/ishtp/client.c: In function 'recv_ishtp_cl_msg_dma':
drivers/hid/intel-ish-hid/ishtp/client.c:1049:3: error: 'cl' may be used uninitialized in this function [-Werror=maybe-uninitialized]
The warning only appeared in very few randconfig builds, as the
spinlocks tend to prevent gcc from tracing the variables. I only
saw it in configurations that had neither SMP nor LOCKDEP enabled.
As we can see, we only enter the case if 'complete_rb' is non-NULL,
and then 'cl' is known to point to complete_rb->cl. Adding another
initialization to the same pointer is harmless here and makes it
clear to the compiler that the behavior is well-defined.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
For ACPI devices which do not have a _PSC method, the ACPI subsys cannot
query their initial state at boot, so these devices are assumed to have
been put in D0 by the BIOS, but for touchscreens that is not always true.
This commit adds a call to acpi_device_fix_up_power to explicitly put
devices without a _PSC method into D0 state (for devices with a _PSC
method it is a nop). Note we only need to do this on probe, after a
resume the ACPI subsys knows the device is in D3 and will properly
put it in D0.
This fixes the SIS0817 i2c-hid touchscreen on a Peaq C1010 2-in-1
device failing to probe with a "hid_descr_cmd failed" error.
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Use a better URL for the HUTRR40 Radio HID Usages documentation and use the
HID_GD_WIRELESS_RADIO_CTLS define rather then hardcoding a check for
0x0001000c.
Fixes: 61df56bef9 ("HID: Add mapping for Microsoft Win8 Wireless Radio Controls extensions")
Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The keyboard dock used with the Asus Transformer T100 series, uses
the same vendor-defined 0xff31 usage-page as some other Asus
keyboards. But with a small twist, it has a small descriptor bug which
needs to be fixed up for things to work.
This commit adds the USB-ID for this keyboard to the hid-asus driver
and makes asus_report_fixup fix the descriptor issue, fixing
various special function keys on this keyboard not working.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The ELECOM DEFT trackballs report only five buttons, when the device
actually has 8. Change the descriptor so that the HID driver can see all of
them.
For completeness and future reference, I included a side-by-side diff of
the part of the descriptor that is being edited.
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Yuxuan Shui <yshuiv7@gmail.com>
Signed-off-by: Diego Elio Pettenò <flameeyes@flameeyes.eu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The ITE8595 keyboard uses the HID_GD_RFKILL_BTN usage code
from the Wireless Radio Controls Application Collection Microsoft
has defined for Windows 8 and later.
However it has a quirk, when the rfkill hotkey is pressed it does
generate a report for the collection, but the reported value is
always 0. Luckily it is the only button in this collection / report,
and it sends a report on release only, so receiving a report means the
button was pressed.
This commit adds a hid-ite driver which watches for the Wireless Radio
Controls Application Collection report and then reports a KEY_RFKILL event,
ignoring the value, making the rfkill on this keyboard work.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Microsoft has defined some extra HUT codes for the Generic Desktop Page
for Wireless Radio controls, see:
https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/airplane-mode-radio-managementhttps://web.archive.org/web/20170509144631/https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/airplane-mode-radio-management
I've 3 2-in-1 keyboard docks: Dell Venue Pro 11 keyboard dock,
HP pavilion x2 keyboard dock and a PEAQ C1010 keyboard dock which have
a wireless radio toggle hotkey, which uses the 0x000100c6 HUT code
defined in these extensions.
This commit adds a mapping for this key, this makes the rfkill toggle
hotkey work on the Dell Venue Pro 11 and HP Pavilion X2 keyboards,
the PEAQ C1010 keyboard does generate events for the 0x000100c6 HUT
code when pressed, but the reported value is always 0.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Generic battery handling code is spread between the pen and pad codepaths
since battery usages may appear in reports for either. This makes it
difficult to concisely see the logic involved. Since battery data is
not treated like other data (i.e., we report it through the power_supply
subsystem rather than through the input subsystem), it makes reasonable
sense to split the functionality out into its own functions.
This commit has the generic battery handling duplicate the same pattern
that is used by the pen, pad, and touch interfaces. A "mapping" function
is provided to set up the battery, an "event" function is provided to
update the battery data, and a "report" function is provided to notify
the power_supply subsystem after all the data has been read. We look at
the usage itself rather than its collection to determine if one of the
battery functions should handle it. Additionally, we unconditionally
call the "report" function since there is no particularly good way to
know if a report contained a battery usage; 'wacom_notify_battery()'
will filter out any duplicate updates, however.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
At the moment, our driver relies on 'wacom_battery_get_property()' to
determine the most likely battery state (e.g charging, discharging, or
full) based on the information available. It is not always possible
for the function to properly determine this, however. For instance,
whenever an AES pen leaves proximity the battery state becomes
indeterminite. This commit adds the ability to provide it with explict
state information if desired. Whenever explicit state is not required
(the majority of circumstances), WACOM_POWER_SUPPLY_STATUS_AUTO can
be used in its place.
Three uses of explicit battery status are added: two wireless disconnect
paths and the AES case mentioned above.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When support for the HID_DG_BATTERYSTRENGTH usage was added for AES devices,
it appears that the value was read, but never actually forwarded to the
power_supply subystem for userspace's benefit. Let's correct that.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
AES sensors use the value 0 to indicate "not available" rather than
"completely dead". Such values are often sent for dozens of reports
while the pen is being brought into proximity and can cause userspace
to get the wrong impression about the actual battery state.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The power_supply subsystem expects us to provide it with capacity values
measured in percent. In particular, AES devices (HID_DG_BATTERYSTRENGTH)
use the range 0-255, which needs to be rescaled. The MobileStudio Pro
(WACOM_HID_WD_BATTERY_LEVEL) uses the range 0-100, but there's no guarantee
that future devices will share the same range.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The driver emits multi-touch events for Magic Trackpad as well as Magic
Mouse, but it does not set keybits that are related to multi-touch event
for Magic Mouse; so set these keybits.
The keybits that are not set cause trouble because user programs often
probe these keybits for self-configuration and thus they cannot operate
properly if the keybits are not set.
One of such troubles is that libevdev will not be able to emit correct
touch count, causing gestures library failed to do fling stop.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The following Smatch complaint was generated in response to commit
2a6cdbd ("HID: wacom: Introduce new 'touch_input' device"):
drivers/hid/wacom_wac.c:1586 wacom_tpc_irq()
error: we previously assumed 'wacom->touch_input' could be null (see line 1577)
The 'touch_input' and 'pen_input' variables point to the 'struct input_dev'
used for relaying touch and pen events to userspace, respectively. If a
device does not have a touch interface or pen interface, the associated
input variable is NULL. The 'wacom_tpc_irq()' function is responsible for
forwarding input reports to a more-specific IRQ handler function. An
unknown report could theoretically be mistaken as e.g. a touch report
on a device which does not have a touch interface. This can be prevented
by only calling the pen/touch functions are called when the pen/touch
pointers are valid.
Fixes: 2a6cdbd ("HID: wacom: Introduce new 'touch_input' device")
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Like other switches, the Aten CS-1758 KVM switch needs a quirk to avoid
spewing errors:
[12599018.071059] usb 5-2: input irq status -75 received
[12599018.079053] usb 5-2: input irq status -75 received
Signed-off-by: Vasilis Liaskovitis <vliaskovitis@suse.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
It apears that devices designed around Wacom's G11 chipset (e.g. Lenovo
ThinkPad Yoga 260, Lenovo ThinkPad X1 Yoga, Dell XPS 12 9250, Dell Venue
8 Pro 5855, etc.) suffer from a common issue in their HID descriptors.
The logical maximum is not updated for the "Contact Identifier" usage,
leaving it as just "1" despite these devices being capable of tracking
far more touches.
Commit 60a2218698 began ignoring usages with out-of-range values,
causing problems for devices based on this chipset. Touches after
the first will have an out-of-range Contact Identifier, and ignoring
that usage will cause the kernel to incorrectly slot each finger's
events (along with all the knock-on userspace effects that entails).
This commit checks for these buggy descriptors and updates the maximum
where required. Prior chipsets have used "255" as the maximum (and the
G11, at least, doesn't seem to actually use IDs outside the range of
1..CONTACTMAX) so continue using this value.
Cc: stable@vger.kernel.org
Fixes: 60a2218698 ("HID: wacom: generic: add support for touchring")
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Because HID_DG_TOOLSERIALNUMBER doesn't first cast the value recieved from HID
to an unsigned type, sign-extension rules can cause the value of
wacom_wac->serial[0] to inadvertently wind up with all 32 of its highest bits
set if the highest bit of "value" was set.
This can cause problems for Tablet PC devices which use AES sensors and the
xf86-input-wacom userspace driver. It is not uncommon for AES sensors to send a
serial number of '0' while the pen is entering or leaving proximity. The
xf86-input-wacom driver ignores events with a serial number of '0' since it
cannot match them up to an in-use tool. To ensure the xf86-input-wacom driver
does not ignore the final out-of-proximity event, the kernel does not send
MSC_SERIAL events when the value of wacom_wac->serial[0] is '0'. If the highest
bit of HID_DG_TOOLSERIALNUMBER is set by an in-prox pen which later leaves
proximity and sends a '0' for HID_DG_TOOLSERIALNUMBER, then only the lowest 32
bits of wacom_wac->serial[0] are actually cleared, causing the kernel to send
an MSC_SERIAL event. Since the 'input_event' function takes an 'int' as
argument, only those lowest (now-cleared) 32 bits of wacom_wac->serial[0] are
sent to userspace, causing xf86-input-wacom to ignore the event. If the event
was the final out-of-prox event, then xf86-input-wacom may remain in a state
where it believes the pen is in proximity and refuses to allow other devices
under its control (e.g. the touchscreen) to move the cursor.
It should be noted that EMR devices and devices which use both the
HID_DG_TOOLSERIALNUMBER and WACOM_HID_WD_SERIALHI usages (in that order) would
be immune to this issue. It appears only AES devices are affected.
Fixes: f85c9dc678 ("HID: wacom: generic: Support tool ID and additional tool types")
Cc: stable@vger.kernel.org
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The latest USB keyboards shipped on several ASUS laptop models
(including ROG laptop models such as GL702VMK) have the keyboards
backlight controlled by the keyboard firmware.
The firmware implements at least 3 different commands:
- Init command (to use when the system starts)
- Configuration command (to get keyboard status/information)
- Backlight level control (to change the level of the keyboard light)
With this patch we create the usual 'asus::kbd_backlight' led class
entry to control the keyboard backlight.
[jkosina@suse.cz: remove pointless cancel_work_sync() call while
handling an error in asus_kbd_register_leds(), as spotted by
Benjamin]
Signed-off-by: Carlo Caione <carlo@endlessm.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
These two functions awkwardly break up the otherwise-contiguous chunk of
related Intuos IRQ functions with a 500 line tangent about the operation
of the EKR. Their presence makes it difficult to read/navigate through the
the Intuos code. Since there is no dependency between these functions, it
is possible to simply move them down somewhat. This commit moves them
to be after the final Intuos IRQ function.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commits d793ff8 and 4082da8 introduced two pad usages which do not
actually send pad input events. To make sure we do not post empty
pad packets, pad_input_event_flag is introduced. Turn on the flag
for real pad input events so we can synchronize them properly.
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This device has a different vendor id but responds to initialization.
Signed-off-by: Xiaolei Yu <dreifachstein@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
err is being checked for failure each time it is being updated
so this err check is totally redundant and can be removed
Detected with CoverityScan, CID#1420665 ("Logically dead code")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Make sure we sure register any sensor when sony_input_configured failes.
Somehow this line got lost during resolving of merge conflicts in the
motion sensor patch series and a redudant remove was added as well later
on.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
By default when using bluetooth the DS4 reports data at about 1kHz,
which is quite fast especially on weak devices. We now make the
device use the USB poll interval, which is a fixed 4ms. In addition
we make the value adjustable through sysfs.
The error handling in sony_input_configured is a little tricky. It
is not easy to add other goto's as not all codepaths have logic
for adding this attribute. Luckily we are setting the value for the
attribute to a default value, so we can use that to detect if we need
to remove the file.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Only set bit flags for the portions of the DS4 output report
for which we have data.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
These colors are more the default colors normally used on the DS4.
The previous ones were faint and not so noticeable.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The navigation controller is a DS3 (sixaxis) with fewer physical
axes and buttons. It utilizes the same HID report as the DS3 and
thus reports axes/buttons which aren't physically present.
Currently many non-existing buttons and axes are reported, which
we are now removing.
For the axes/buttons which do exist, we make the axis/button mapping
similar to the DS3.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The DS3 MAC address is reported as a unique identified when
using Bluetooth. For USB there is no unique identifier reported
yet, so use the MAC address.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This way, upower can add a simple udev rule to decide whether or not
it should use the internal unifying support or just the generic kernel
one.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Solar Keyboard uses a different feature to report the battery level.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
CAPACITY LEVEL allows to forward rough information on the battery mileage.
HID++ 2.0 devices will either report percentage or levels, so better
forwarding this information to the user space.
The M325 supports only 2 levels: 'Full' and 'Critical'. With mileage,
it will report either 90% or 5%, which might confuse users. With this
change the battery will either report "Full" or "Critical".
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The power_supply term for the percentage is capacity. Capacity level
can be given when non accurate mileage is provided by the device, so
better stick to the terms used in power_supply.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When ONLINE isn't set, upower should ignore the battery capacity,
so there is no need to overload it with some random values.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When a device reconnects, there is a high chance its power supply has
been changed (for a battery replacement for instance). Just forward
the battery state here.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Or the device just answers a valid feature '0'.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The creation of the power_supply should not be in a HID++ 2.0 specific
function.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Better forwarding the device name, manufacturer and serial to upower.
Note that serial is still empty, it will be filled in a later patch
in this series.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Battery events are reported through HID++, so we need to be sure
the report ID is the HID++ one.
Without this, we might receive keyboard events that looks just like
battery events with wrong data and which will confuse user space.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Looks like all users don't care about a disconnect.
Simplify the various variant_connect() and put the connect state check
at the beginning.
For delayed input devices, make sure we go through all other connect
values (protocol, battery) before bailing out.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
hidpp->name can't be null.
Only HID++ 2.0 and above device supports the query.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Unifying devices are different from others because they can probed
while not connected. So we need to talk to the receiver to get some
extra information like the device name and the serial.
Instead of having conditionals while attempting to read the device name
from HID++ 2.0, have a special init path for them.
Store the retrieved serial in hdev->uniq.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Do not pollute the quirks bits field which is public API
with elements that are queried from the device.
Move the 2 battery capabilities into the new field.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Unless they are connected through unifying, they don't support it,
so remove one error in the logs.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Without a scope defined, UPower assumes that the battery provides
power to the computer it's connected to, like a laptop battery or a UPS.
Tested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Register 0xB5 should be handled specially no matter what function is
used. This allows to retrieve the serial and the Quad ID from
hid-logitech-hidpp directly.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit 3b164a00a9 ("HID: wacom: Cleanup unsupported device_type
for BAMBOO_PT") cleaned up Bamboo devices which our driver falsely
claimed had touch. Bamboo One Medium also does not have touch.
Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit a544c619a5 ("HID: wacom: do not attempt to switch mode
while in probe") introduces delayed work for querying (setting the
mode) on all tablets. Bamboo Touch (056a:00d0) has a ghost
interface which claims to be a pen device. Though this device can
be removed, we have to set the mode on the ghost pen interface
before we remove it. After the aforementioned delay was introduced
the device was being removed before the mode setting could be
executed.
Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
A previous commit (below) adds a check for already probed interfaces to
Wacom's matching heuristic. Unfortunately this causes the Bamboo Pen
(CTL-460) to match itself to its 'ghost' touch interface. After
subsequent changes to the driver this match to the ghost causes the
kernel to crash. This patch avoids calling wacom_add_shared_data()
for the BAMBOO_PEN's ghost touch interface.
Fixes: 41372d5d40 ("HID: wacom: Augment 'oVid' and 'oPid' with heuristics for HID_GENERIC")
Cc: stable <stable@vger.kernel.org> # 4.9
Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The input mapping code incorrectly maps the Airplane Mode button to
KEY_WLAN, which stands for WiFi toggle, but doesn't affect Bluetooth
(and other active radios) which is expected behavior for Airplane
Mode.
The fix replaces KEY_WLAN with the more appropriate KEY_RFKILL.
The declared usage code 0x88 corresponds to Airplane Mode button on
all keyboards handled by hid-asus (I2C netbook keyboards and USB
RoG series keyboards), so the fix doesn't introduce any
inconsistencies across different models.
Signed-off-by: Matjaz Hegedic <matjaz.hegedic@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Keyboards handled by hid-asus declare special key functions
using a vendor-specific page, however, alongside legitimate
key functions, dummy usages with seemingly arbitrary values
are also declared and can lead to keyboards being detected
as pointer devices by some software (such as X.org).
In addition, for the I2C keyboard volume controls are
separately declared in a Consumer Usage page, with the same
dummy usage problem.
The fix in 1989dada7c ("HID: input: ignore System Control
application usages if not System Controls") does not mitigate
the problem described above, therefore dummy usages need to
be ignored in the driver itself.
This fix properly ignores dummy usages and introduces a quirk
for custom handling of the Consumer Usages on the I2C keyboard.
Signed-off-by: Matjaz Hegedic <matjaz.hegedic@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Before commits a1cbda7a65a7a ("HID: asus: drop dependency
on I2C_HID") and 64a403c6555fd ("HID: asus: support Republic
Of Gamers special keys") hid-asus only pertained to a single
I2C keyboard model found in ASUS X205TA, F205TA, & X200HA. The
aforementioned commits expanded this support to other ASUS
laptop keyboard models.
In order to clarify that existing keyboard and touchpad quirks
only apply to the I2C devices, and not ASUS keyboards in
general, I2C HID IDs and their corresponding quirk sets have
been renamed. In addition, the latter commit introduced
special key handling, which also applies to the I2C keyboard,
not just Republic of Gamers series. Therefore, the
rog_map_key_clear() macro is renamed to asus_map_key_clear()
for the sake of generality.
Signed-off-by: Matjaz Hegedic <matjaz.hegedic@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Jiri Kosina