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>
Add support for the special keys found on the internal keyboard of the
Asus Republic of Gamers (ROG) laptop models GL553VD, GL553VE, GL753VD
and GL753VE.
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There is nothing transport-specific in this driver, and we will now be
adding support for some Asus USB devices too.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
They are part of HUTRR34 for multi-touch digitizers:
0x0E Device configuration CA 16.7
0x23 Device settings CL 16.7
Signed-off-by: Xiaolei Yu <dreifachstein@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There is a new clone of the XIN MO arcade controller which has same issue with
out of range like the original. This fix will solve the issue where 2
directions on the joystick are not recognized by the new THT 2P arcade
controller with device ID 0x75e1. In details the new device ID is added the
hid-id list and the hid-xinmo source code.
Signed-off-by: Peter Stein <peter@stuntstein.dk>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull HID fixes from Jiri Kosina:
- regression fixes for Wacom devices, from Aaron Armstrong Skomra and
Ping Cheng
- memory leak in hid-sony driver from Roderick Colenbrander
- new device IDs support from Oscar Campos and Daniel Drake
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: wacom: generic: Wacom mouse is only provided for opaque tablets
HID: corsair: Add driver Scimitar Pro RGB gaming mouse 1b1c:1b3e support to hid-corsair
HID: corsair: support for K65-K70 Rapidfire and Scimitar Pro RGB
HID: wacom: don't manually release resources for the EKR
HID: wacom: Correct Intuos Pro 2 resolution
HID: sony: Fix input device leak when connecting a DS4 twice using USB/BT
HID: chicony: Add support for another ASUS Zen AiO keyboard
GPIOLIB_IRQCHIP is not visible to user, so we can't depend on it.
Depend on GPIOLIB but select GPIOLIB_IRQCHIP.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We need to store the minor number each drivers. In case of hidraw, the
minor number is stored stores in struct hidraw. But hiddev's minor is
located in struct hid_device.
The hid-core driver announces a kernel message which driver is loaded when
HID device connected, but hiddev's minor number is always zero. To proper
display hiddev's minor number, we need to store the minor number asked from
usb core and do some refactoring work (move from hiddev.c to hiddev.h) to
access hiddev in hid-core.
[jkosina@suse.cz: rebase on top of newer codebase]
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jaejoong Kim <climbbb.kim@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The cp2112 driver is working on hidraw not hiddev. So we need to use proper
hidraw name with hidraw's minor number.
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jaejoong Kim <climbbb.kim@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Game controllers can be connected twice through USB and BT. Only
one connection is allowed. Currently we perform a check for duplicate
controllers halfway through device initialization. To prevent
'transient' devices, we should do this check as early as we can.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch adds a separate evdev node for the DS3 its motion
sensors. We only expose the accelerometers as the gyroscope
is extremely difficult to manage and behavior varies a lot
between hardware revisions.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch adds printing when we failed to activate DS3 / Nagivation
controllers and checks the return value for these failures earlier
in sony_input_configured. This paves the way for other configuration
logic for these devices, which we don't want to call if for example
the activation failed.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The axis and button mapping for the DS3 is strange. This is mostly
due to the device reporting many axes as for every digital button
it also has an analog button. Due to amount of analog values it
is even leaking well into the MT axes range.
We felt it is best to remove the many analog buttons and just report
digital and comply to the Linux gamepad spec. The analog buttons are
rarely used on the official platform, let alone on Linux.
This patch does remove motion sensor support (added back in another
patch).
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Currently the DS4 touchpad device is neither classified as a direct
input device nor as a pointer device. It makes most sense to mark
it as a pointer device.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The DualShock 4 dongle isn't connected to a real DualShock 4 at
time of driver loading. When a DualShock 4 is plugged in, we
need to obtain calibration data (the dongle would have zeros).
This patch adds calibration logic, which we schedule on a hotplug
from sony_raw_event. In addition this patch adds dongle state
handling.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The driver currently uses sony_schedule_work to submit output
reports for the different devices for LEDs or rumble.
This patch adds a new parameter to sony_schedule_work to allow
scheduling for other types of work. The next patch in this series
will utilize this functionality. Considering the driver structure
and all error handling it felt best to reuse sony_schedule_work
and sony_cancel_work. The idea was inspired by the wacom driver
which does something similar.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch adds a new quirk, which allows us to differentiate
between the DualShock 4 USB and the dongle. So far they have
been treated the same, but handling of calibration data differs
as the dongle behaves like Bluetooth, for other requests it
behaves like USB.
In addition this patches changes usb/dongle/bt handling in
sony_raw_event, which makes the code cleaner to read. In addition
another patch in this series will add more dongle logic, so this
change paves the road for that.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The DS4 in BT mode sends initial input reports through report 1, which
is described in the HID report descriptors. When activated after sending
a certain feature report, the device uses report 17.
Currently the hid-sony driver fixes up the BT HID report descriptors,
so the HID layer can manage input reports for report 17.
We think it is best to eliminate this fixup and do the handling ourselves,
which is what this patch does. The main motivation is that there are
various users of DS4 through hidraw, including various cross-platform
applications/games, which have their own HID parsing across Linux/Win/OSX.
Due to the fixup the descriptors differ, which is causing pain for many
developers including major game publishers (who reached out privately).
Without the fixup, the Windows titles also have a fighting chance for
working on Wine, which provides HID support now. Overall it felt
best because of these reasons to remove the fixup.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The DS4 motion sensors require calibration for accurate operation.
This patch adds calibration for both the accelerometer and the
gyroscope. Calibration requires reading device specific scaling
factors and offsets. For precision reasons we store these values
as a numerator and denominator and apply the values when processing
the data.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The DS4 motion sensors are currently mapped by the hid-core driver
to non-existing axes in between ABS_MISC and ABS_MT_SLOT, because
the device already exhausted ABS_X-ABS_RZ. For a part the mapping
by hid-core is accomplished by a fixup in hid-sony as the motion
axes actually use vendor specific usage pages.
This patch makes the DS4 use a separate input device for the motion
sensors and reports acceleration data through ABS_X-ABS_Z and
gyroscope data through ABS_RX-ABS_RZ. In addition it extends the
event spec to allow gyroscope data through ABS_RX-ABS_RZ when
INPUT_PROP_ACCELEROMETER is set. This change was suggested by
Peter Hutterer during a discussion on linux-input.
[jkosina@suse.cz: rebase onto slightly newer codebase]
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Accutouch 2216 is reporting BTN_LEFT/BTN_MOUSE rather than BTM_TOUCH
in it's capabilities, which is what user space expects a touchscreen
device to report. This is causing udev to consider the device to be a
"VMware's USB mouse" rather than as a touchscreen, which results in a
mouse cursor being displayed in Weston.
This patch adds a special driver for the device to correct the
capabilities reported.
Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
It looks like a bunch of devices do not like to be polled
for their reports at init time. When you look into the details,
it seems that for those that are requiring the quirk
HID_QUIRK_NO_INIT_REPORTS, the driver fails to retrieve part
of the features/inputs while others (more generic) work.
IMO, it should be acceptable to remove the need for the quirk
in the general case. On the small amount of cases where
we actually need to read the current values, the driver
in charge (hid-mt or wacom) already retrieves the features
manually.
There are 2 cases where we might need to retrieve the reports at
init:
1. hiddev devices with specific use-space tool
2. a device that would require the driver to fetch a specific
feature/input at plug
For case 2, I have seen this a few time on hid-multitouch. It
is solved in hid-multitouch directly by fetching the feature.
I hope it won't be too common and this can be solved on a per-case
basis (crossing fingers).
For case 1, we moved the implementation of HID_QUIRK_NO_INIT_REPORTS
in hiddev. When somebody starts calling ioctls that needs an initial
update, the hiddev device will fetch the initial state of the reports
to mimic the current behavior. This adds a small amount of time during
the first HIDIOCGUSAGE(S), but it should be acceptable in
most cases. To keep the currently known broken devices, we have to
keep around HID_QUIRK_NO_INIT_REPORTS, but the scope will only be
for hiddev.
Note that I don't think hidraw would be affected and I checked that
the FF drivers that need to interact with the report fields are all
using output reports, which are not initialized by
usbhid_init_reports().
NO_INIT_INPUT_REPORTS is then replaced by HID_QUIRK_NO_INIT_REPORTS:
there is no point keeping it for just one device.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch fixes an issue in drivers/hid/hid-input.c where values
outside of the logical range are not clamped when "null state" bit of
the input control is not set.
This was discussed on the lists [1] and this change stems from the fact
due to the ambiguity of the HID specification it might be appropriate to
follow Microsoft's own interpretation of the specification. As noted in
Microsoft's documentation [2] in the section titled "Required HID usages
for digitizers" it is noted that values reported outside the logical
range "will be considered as invalid data and the value will be changed
to the nearest boundary value (logical min/max)."
This patch fixes an issue where the (1292:4745) Innomedia INNEX
GENESIS/ATARI reports out of range values for its X and Y axis of the
DPad which, due to the null state bit being unset, are forwarded to
userspace as is. Now these values will get clamped to the logical range
before being forwarded to userspace. This device was also used to test
this patch.
This patch expands on commit 3f3752705d ("HID: reject input outside
logical range only if null state is set").
[1]: http://lkml.kernel.org/r/20170307131036.GA853@gaia.local
[2]: https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85).asp
Signed-off-by: Tomasz Kramkowski <tk@the-tk.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit f85c9dc ("Support tool ID and additional tool types") introduced mouse
and lens cursor tools to generic codepath, which covers both display (direct)
and opaque tablets (indirect devices). However, mouse and lens cursor tools are
only provided for opaque tablets. This patch ignores mouse and lens cursor tools
if the device is a display tablet.
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This mouse sold by Corsair as Scimitar PRO RGB defines two consecutive
Logical Minimum items in its Application (Consumer.0001) report making
it non parseable. This patch fixes the report descriptor overriding
byte 77 in rdesc from 0x16 (Logical Minimum with 16 bits value) to 0x26
(Logical Maximum with 16 bits value).
Signed-off-by: Oscar Campos <oscar.campos@member.fsf.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit 5b779fc introduces the manual release of resources in wacom_remove() as
an addition to the driver's use of devm. The EKR resources can only be
released through wacom_remote_destroy_one() so we skip the manual release for
it.
Fixes: 5b779fc ("HID: wacom: release the resources before leaving despite devm")
Signed-off-by: Aaron Armstrong Skomra <skomra@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The features struct for the second gen Intuos Pro uses the wrong constant for
the resolution. This fix is for commit 4922cd2.
Fixes: 4922cd2 ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
Signed-off-by: Aaron Armstrong Skomra <skomra@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Quoting from Jonathan Clarke in previous thread(2017/01/24):
"This division by 2 was added along with the touch width/height fields 6 years
ago so that those fields 'match the visual scale of the touch' for a specific
device (3M PCT)" "The scaling is also discarding information about touch size
(1 bit for each of width/height) which is useful for any application that wants
to know about it."
Jonathan mentioned just what I thought in a new project recently. It dosen't
make sense to discard 1 bit width/height in general case according to the spec
in multi-touch-protocol.txt so I would like to make a slight change here.
A quirk MT_QUIRK_TOUCH_SIZE_SCALING was added to service devices like 3M PCT
with a special visual scale and the division by 2 only take effect with devices
like that.
[jkosina@suse.cz: reformat changelog]
Signed-off-by: HungNien Chen <hn.chen@weidahitech.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When a user connects a DS4 twice using USB and BT, we reject the
second device connection after the setup work. We then perform
a cleanup, but during cleanup we are not removing the touchpad
device. This leads to leakage of an input device, which we would
never remove. It can likely result into a kernel oops as well
when the touchpad evdev node is accessed and the underlaying HID
device has been removed from the system.
[jkosina@suse.cz: added stable annotation]
Fixes: ac797b95f5 ("HID: sony: Make the DS4 touchpad a separate device")
Cc: stable@vger.kernel.org
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add support for media keys on the keyboard that comes with the
Asus V221ID and ZN241IC All In One computers.
The keys to support here are WLAN, BRIGHTNESSDOWN and BRIGHTNESSUP.
This device is not visibly branded as Chicony, and the USB Vendor ID
suggests that it is a JESS device. However this seems like the right place
to put it: the usage codes are identical to the currently supported
devices, and this driver already supports the ASUS AIO keyboard AK1D.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Use a more common logging style and remove the unnecessary
OOM messages as there is default dump_stack when OOM.
Miscellanea:
o Hoist an assignment in an if
o Realign arguments
o Realign a deeply indented if descendent above a printk
Signed-off-by: Joe Perches <joe@perches.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
For mouse devices we can currently change the polling interval
via usbhid.mousepoll. Implement the same thing for joysticks, so
users can reduce input latency this way.
This has been tested with a Logitech RumblePad 2 with jspoll=2,
resulting in a polling rate of 500Hz (verified with evhz).
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
According to error handling in this function, it is likely that some
resources should be freed before returning.
Replace 'return ret', with 'goto err'.
While at it, remove some spaces at the beginning of the lines to be more
consistent.
Fixes: ead0687fe304a ("HID: i2c-hid: support regulator power on/off")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Wacom Cintiq Pro has a softkey to turn touch on/off. Since it is
a softkey, hardware/firmware still reports touch events no matter
what state the softkey is. We need to ignore touch events when
the key is in off mode.
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Wacom Cintiq Pro added a touch key to switch the tablet between
display and opaque mode. This patch informs the change by removing
the old devices and creating new ones with proper properties.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Tested-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch add support to the 3 touch keys on Wacom Cintiq Pro. These touch
keys are in the middle of the other two keys on the top edge of the tablet.
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The (1292:4745) Innomedia INNEX GENESIS/ATARI adapter needs
HID_QUIRK_MULTI_INPUT to split the device up into two controllers
instead of inputs from both being merged into one.
Signed-off-by: Tomasz Kramkowski <tk@the-tk.com>
Acked-By: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch fixes an issue in drivers/hid/hid-input.c where USB HID
control null state flag is not checked upon rejecting inputs outside
logical minimum-maximum range. The check should be made according to USB
HID specification 1.11, section 6.2.2.5, p.31. The fix will resolve
issues with some game controllers, such as:
https://bugzilla.kernel.org/show_bug.cgi?id=68621
[tk@the-tk.com: shortened and fixed spelling in commit message]
Signed-off-by: Valtteri Heikkilä <rnd@nic.fi>
Signed-off-by: Tomasz Kramkowski <tk@the-tk.com>
Acked-By: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
On some boards, we need to enable a regulator before using the HID, and
it's also nice to save power in suspend by disabling it. Support an
optional "vdd-supply" and a companion initialization delay.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: linux-input@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The LED subsystem provides the LED_CORE_SUSPENDRESUME flag to handle
automatically turning off and restoring the state of device LEDs during
suspend/resume. Use this flag instead of saving and restoring the state
locally.
Signed-off-by: Frank Praznik <frank.praznik@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
These adapters allow pre-USB Sun keyboards to be connected to USB-only
machines, but include the wrong maximum keycode in their report descriptor,
making most of the keys present on Sun keyboards but not 101-key PC
keyboards nonfunctional.
This patch implements a quirk that overrides the maximum keycode in the
report descriptor.
Signed-off-by: Jonathan Tomer <jktomer@google.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Fix up affected files that include this signal functionality via sched.h.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Fix typos and add the following to the scripts/spelling.txt:
comsume||consume
comsumer||consumer
comsuming||consuming
I see some variable names with this pattern, but this commit is only
touching comment blocks to avoid unexpected impact.
Link: http://lkml.kernel.org/r/1481573103-11329-19-git-send-email-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull HID fix from Jiri Kosina:
"Regression fix for HID_RMI-driven synaptics touchpads in
!CONFIG_HID_RMI cases"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: rmi: fallback to generic/multitouch if hid-rmi is not built
Commit 279967a65b ("HID: rmi: Handle all Synaptics touchpads using hid-rmi")
unconditionally switches over handling of all Synaptics touchpads to hid-rmi
(to make use of extended features of the HW); in case CONFIG_HID_RMI is
disabled though this renders the touchpad unusable, as the
HID_DEVICE(HID_BUS_ANY, HID_GROUP_RMI, HID_ANY_ID, HID_ANY_ID)
match doesn't exist and generic/multitouch doesn't bind to it either (due
to hid group mismatch).
Fix this by switching over to hid-rmi only if it has been actually built.
Fixes: 279967a65b ("HID: rmi: Handle all Synaptics touchpads using hid-rmi")
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew Duggan <aduggan@synaptics.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Declare device_type structure as const as it is only stored in the
type field of a device structure. This field is of type const, so add
const to the declaration of device_type structure.
File size before: drivers/hid/intel-ish-hid/ishtp/bus.o
text data bss dec hex filename
4260 336 16 4612 1204 hid/intel-ish-hid/ishtp/bus.o
File size after: drivers/hid/intel-ish-hid/ishtp/bus.o
text data bss dec hex filename
4324 272 16 4612 1204 hid/intel-ish-hid/ishtp/bus.o
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The prox/range bits included in the Bluetooth reports from the Intuos Pro
were being ignored, leading to two issues. Firstly, the pen would never
announce a BTN_TOOL_PEN event with value 0, leaving userspace to believe
the pen was always active. Secondly, the driver would continue to send
events for data while the packet's "prox" bit was clear. This can lead
to sudden incorrect pointer jumps if the pen is slowly moved away from
the tablet surface.
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>
For ISH resume, there are two paths, they need different way to handle: one
where ISH is not powered off, in that case a simple resume message is enough,
in other case we need a reset sequence.
We can use ISH FW status to distinguish those two cases and handle them
properly.
Signed-off-by: Even Xu <even.xu@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The LG Melfas touchscreen has a bad firmware where it declares the Contact ID
field as constant while it shouldn't. This messes up the autodetection and the
reporting of the events by hid-multitouch given that hid-input ignores constant
fields.
The autodetection is simply worked around by manually adding the device to
hid_have_special_driver[].
The processing of the events requires either a report fixup, or some specific
case handling. Given that the report fixup would require to basically rewrite
all the report descriptor, I went for the programatic way of fixing that after
the report descriptors are loaded.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1416181
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Non-generic devices have numbered_buttons set for both pen and
touch interfaces by default. The actual number of buttons on the
interface is normally manually decided later, which is different
from what those HID generic devices are processed, where number
of buttons are directly retrieved from HID descriptors.
This patch adds the missed HID_GENERIC check and moves the statement
to wacom_setup_pad_input_capabilities since it's not a quirk anymore.
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In case of a zero-length report, the gpio direction_input callback would
currently return success instead of an errno.
Fixes: 1ffb3c40ff ("HID: cp2112: make transfer buffers DMA capable")
Cc: stable <stable@vger.kernel.org> # 4.9
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
A recent commit fixing DMA-buffers on stack added a shared transfer
buffer protected by a spinlock. This is broken as the USB HID request
callbacks can sleep. Fix this up by replacing the spinlock with a mutex.
Fixes: 1ffb3c40ff ("HID: cp2112: make transfer buffers DMA capable")
Cc: stable <stable@vger.kernel.org> # 4.9
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The driver type can be assigned immediately when an RC device
requests to the framework to allocate the device.
This is an 'enum rc_driver_type' data type and specifies whether
the device is a raw receiver or scancode receiver. The type will
be given as parameter to the rc_allocate_device device.
Change accordingly all the drivers calling rc_allocate_device()
so that the device type is specified during the rc device
allocation. Whenever the device type is not specified, it will be
set as RC_DRIVER_SCANCODE which was the default '0' value.
Suggested-by: Sean Young <sean@mess.org>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
unknown and other are for IR protocols for which we have no decoder,
so the raw IR drivers have no chance of generating them. cec is not
an IR protocol.
Signed-off-by: Sean Young <sean@mess.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
With NOGET quirk Logitech F510 is now fully workable in dinput mode including
rumble effects (according to fftest).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117091
[jkosina@suse.cz: fix patch format]
Signed-off-by: Ardinartsev Nikita <ardinar23@gmail.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Quirking the following AMI USB device with ALWAYS_POLL fixes an AMI
virtual keyboard and mouse from not responding and timing out when
it is attached to a ppc64el Power 8 system and when we have some
rapid open/closes on the mouse device.
usb 1-3: new high-speed USB device number 2 using xhci_hcd
usb 1-3: New USB device found, idVendor=046b, idProduct=ff01
usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-3: Product: Virtual Hub
usb 1-3: Manufacturer: American Megatrends Inc.
usb 1-3: SerialNumber: serial
usb 1-3.3: new high-speed USB device number 3 using xhci_hcd
usb 1-3.3: New USB device found, idVendor=046b, idProduct=ff31
usb 1-3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-3.3: Product: Virtual HardDisk Device
usb 1-3.3: Manufacturer: American Megatrends Inc.
usb 1-3.4: new low-speed USB device number 4 using xhci_hcd
usb 1-3.4: New USB device found, idVendor=046b, idProduct=ff10
usb 1-3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-3.4: Product: Virtual Keyboard and Mouse
usb 1-3.4: Manufacturer: American Megatrends Inc.
With the quirk I have not been able to trigger the issue with
half an hour of saturation soak testing.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit 025bcc1 performed cleanup work on the 'wacom_pl_irq' function, making
it follow the standards used in the rest of the codebase. The change
unintiontionally allowed the function to send input events from reports
that are not marked as being in prox. This can cause problems as the
report values for X, Y, etc. are not guaranteed to be correct. In
particular, occasionally the tablet will send a report with these values
set to zero. If such a report is received it can caus an unexpected jump
in the XY position.
This patch surrounds more of the processing code with a proximity check,
preventing these zeroed reports from overwriting the current state. To
be safe, only the tool type and ABS_MISC events should be reported when
the pen is marked as being out of prox.
Fixes: 025bcc1540 ("HID: wacom: Simplify 'wacom_pl_irq'")
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add support for the LEDs around the mode switch to the generic code path in
support of the second generation Intuos Pro.
Signed-off-by: Aaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The second generation Intuos Pro is the first device in the generic codepath
which has a touchswitch. We utilize a flag in wacom_shared in order to report
this switch event received from the pad on the touch input.
Signed-off-by: Aaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add vendor defined touch to support the second generation Intuos Pro.
Previously all generic Wacom devices used true HID to report their touch.
Signed-off-by: Aaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add support for the touchring to the generic code path in support of the second
generation Intuos Pro.
We also add checks for usage->type to ensure that we handle the usage before we
report it, or change the inrange_state based on it.
Signed-off-by: Aaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Input_event_flag duplicates the information we track in
wacom_wac->hid_data.inrange_state for the pad.
Signed-off-by: Aaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In addition to its USB interface, the second-generation Intuos Pro
includes a Bluetooth radio that offers two pairing interfaces: classic
and low-energy. The classic interface functions just like the earlier
Bluetooth-enabled Intuos4 and Graphire4 tablets, appearing as a HID device
that our driver can work with. The low-energy interface is intented to
be used by userspace applications that make use of its paper-to-digital
capabilities.
Despite the USB interface using Wacom's new vendor-defined HID usages,
the Bluetooth interface provides us with useless black-box "blob"
report descriptors like past devices. We thus have to explicitly add
support for the PIDs and reports used.
These devices pack a /lot/ of information into a single Bluetooth
input report. Each report contains up to seven snapshots of the pen
state, four snapshots of the touch state (of five touches each), pad
state, and battery data. Thankfully this isn't too hard for the driver
to report -- it just takes a fair amount of code to extract!
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Centralize our definition of report IDs by moving those for device commands
into wacom_wac.h alongside those for input reports.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There no reason a Bluetooth device with the appropriate HID descriptor couldn't
be used through the HID_GENERIC codepath in the future. Ensure that the driver
attempts to bind to these devices.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Intuos Pro seems to not like when we set the features right after
being powered up. Instead of waiting during probe, we can schedule the
switch mode and LED control in a deferred worker so that we don't have the
5 secs of delay from USB when the device is not accessible.
The USB timeout delays were really a pain because if you happen to unplug
the tablet while it is still waiting, you are just adding 5 second timeouts
to the USB stack. Which means that a new plug of the same tablet will also
gets delayed, and will also attempt to access the hardware while in
.probe(). So the tablet doesn't appear in the dmesg, the user unplug/replug
it to make it appearing... and so on so forth.
Really, this is for the best :)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When the LED class gets removed, it actually tries to reset the LED.
However, the device being disconnected, the set_report fails.
Previously, the attempt to cut lose this last event was through unsetting
the HID drvdata, but it was not working properly. Simply reset the LED
groups to NULL makes a more efficient solution.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In the general case, the resources are properly released by devm without
needing to do anything. However, when unplugging the wireless receiver,
the kernel segfaults from time to time while calling devres_release_all().
I think in that case the resources attempt to access hid_get_drvdata(hdev)
which has been set to null while leaving wacom_remove().
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Removes trailing whitespace in hid-core.c and usbhid/hid-quirks.c
Signed-off-by: Dennis Chen <barracks510@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Nearly identical to the previous set of patches related to Microsoft
Surface Keyboards.
Removes Surface Pro 3 generation TypeCover support from hid-microsoft
so proper multitouch data can be reported from the touchpad.
Signed-off-by: Dennis Chen <barracks510@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit 345857b ("HID: wacom: generic: Add support for sensor offsets") included
a change to the operation and location of the call to 'wacom_add_shared_data'
in 'wacom_parse_and_register'. The modifications included moving it higher up
so that it would occur before the call to 'wacom_retrieve_hid_descriptor'. This
was done to prevent a crash that would have occured when the report containing
tablet offsets was fed into the driver with 'wacom_hid_report_raw_event'
(specifically: the various 'wacom_wac_*_report' functions were written with the
assumption that they would only be called once tablet setup had completed;
'wacom_wac_pen_report' in particular dereferences 'shared' which wasn't yet
allocated).
Moving the call to 'wacom_add_shared_data' effectively prevented the crash but
also broke the sibiling detection code which assumes that the HID descriptor
has been read and the various device_type flags set.
To fix this situation, we restore the original 'wacom_add_shared_data'
operation and location and instead implement an alternative change that can
also prevent the crash. Specifically, we notice that the report functions
mentioned above expect to be called only for input reports. By adding a check,
we can prevent feature reports (such as the offset report) from
causing trouble.
Fixes: 345857bb49 ("HID: wacom: generic: Add support for sensor offsets")
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Tested-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Make sure to check for short control transfers in order to avoid parsing
uninitialised buffer data and leaking it to user space.
Note that the backlight and macro-mode buffer constraints are kept as
loose as possible in order to avoid any regressions should the current
buffer sizes be larger than necessary.
Fixes: 6f78193ee9 ("HID: corsair: Add Corsair Vengeance K90 driver")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Not all platforms support DMA to the stack, and specifically since v4.9
this is no longer supported on x86 with VMAP_STACK either.
Note that the macro-mode buffer was larger than necessary.
Fixes: 6f78193ee9 ("HID: corsair: Add Corsair Vengeance K90 driver")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
With the addition of HID and F12 support in the synaptics-rmi4 driver
touchpads which had been using the hid-multitouch driver can now
be support by the synaptics-rmi4 via hid-rmi. The advantage is that
additional data can be reported from the RMI registers which is not
available in the Microsoft Precision Touchpad collection.
Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Synaptics RMI4 driver provides support for RMI4 devices. Instead of
duplicating the RMI4 processing code, make hid-rmi a transport driver
and register it with the Synaptics RMI4 core.
Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Mayflash DolphinBar and GameCube adapters have been tested and confirmed to
work using the hid-mf driver.
Signed-off-by: Marcel Hasler <mahasler@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Mayflash GameCube adapter has received a firmware update which, among other
things, changes the device's PID. It also fixes enumeration, therefore the
updated firmware no longer requires HID_QUIRK_MULTI_INPUT.
Signed-off-by: Marcel Hasler <mahasler@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Nearly identical to the patch "multitouch: enable the Surface 4 Type Cover Pro
(JP) to report multitouch data"
We can now remove the support of the Surface 4 Type Cover Pro (not JP versions)
from hid-microsoft so it can properly report multi touch from the touchpad.
Signed-off-by: Daniel Keller <daniel.keller@gcd.de>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.
Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.
As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.
See https://github.com/vlasenko/hid-asus-dkms/issues/24 for further
details.
Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Make sure we have enough of a report structure to validate before
looking at it.
Reported-by: Benoit Camredon <benoit.camredon@airbus.com>
Tested-by: Benoit Camredon <benoit.camredon@airbus.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Local "#define DRIVER_LICENSE" obfuscates which license is used
in MODULE_LICENSE(). "fgrep -R MODULE_LICENSE" is more informative
when the string is hard coded in MODULE_LICENSE.
Signed-off-by: Grant Grundler <grundler@google.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This headlamp contains a dummy HID descriptor which pretends to be
a mouse-like device, but can't be used as a mouse at all.
Reported-by: Lukas Ocilka <lukas.ocilka@suse.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
While applying patch d443a0aa3a: "HID: hid-sensor-hub: clear memory to
avoid random data", there was some issues in applying correct version of
the patch. This resulted in the breakage of sensor functions as all
request like power-up will be reset by the memset() in the function
sensor_hub_set_feature().
The reset of caller buffer should be in the function
sensor_hub_get_feature(), not in the sensor_hub_set_feature().
Fixes: d443a0aa3a ("HID: hid-sensor-hub: clear memory to avoid random data")
Cc: Stable <stable@vger.kernel.org> # 4.9+
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The DolphinBar by Mayflash (identified as Dragonrise) needs
HID_QUIRK_MULTI_INPUT to split it up into four input devices. Without this
quirk the adapter is falsely recognized as a tablet. See also bug 115841
(https://bugzilla.kernel.org/show_bug.cgi?id=115841).
Signed-off-by: Marcel Hasler <mahasler@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Futaba TOSD-5711BB VFD crashes when the initial HID report is requested,
register the display in hid-ids and tell hid-quirks to not do the init.
Signed-off-by: Alex Wood <thetewood@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In ishtp_hid_probe(), use %04X instead of %04hX to format __u32 values,
in order to silent a format error reported by clang:
drivers/hid/intel-ish-hid/ishtp-hid.c:212:3: error: format specifies
type 'unsigned short' but the argument has type '__u32' (aka
'unsigned int') [-Werror,-Wformat]
hid->vendor, hid->product);
^~~~~~~~~~~
drivers/hid/intel-ish-hid/ishtp-hid.c:212:16: error: format
specifies type 'unsigned short' but the argument has type '__u32'
(aka 'unsigned int') [-Werror,-Wformat]
hid->vendor, hid->product);
^~~~~~~~~~~~
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Structure ishtp_device contains a logging function, print_log(), which
formats some of its parameters using vsnprintf(). Add a __printf
attribute to this function field (and to ish_event_tracer()) in order to
detect at compile time issues related to the printf-like formatting.
While at it, make format parameter a const pointer as print_log() is not
supposed to modify it.
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When the DS4 dongle is connected, it always generates HID reports
even when no DS4 is paired to it. This patch adds logic to ignore
HID reports from the dongle if there is no DS4 currently attached.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The DS4 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>
The error handling code in sony_input_configured in general uses goto
based cleanup. Recently we migrated code from sony_probe to here, but
we didn't update the existing touchpad registration code, which was
already here to use the goto.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Since commit 8fe89ef076 ("HID: multitouch: enable the Surface 3 Type
Cover to report multitouch data"), the TypeCover can be properly handled
by hid-multitouch and don't require any special quirk in the kernel.
Remove the support of the Surface 4 Type Cover Pro (JP) from
hid-microsoft so it can properly report multitouch from the touchpad.
Signed-off-by: Yuta Kobayashi <alu.ula@outlook.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The previous submission which added Touchpad support broke the
Keyboard support of this driver. This patch:
1. fixes the Keyboard support (by assigning drvdata->input);
2. renames NOTEBOOK_QUIRKS to KEYBOARD_QUIRKS;
3. adds the NO_INIT_REPORT quirk to the KEYBOARD_QUIRKS; and
4. sets the input->name to 'Asus Keyboard' for the keyboard
Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
hid/intel-ish-hid does not use any miscdevice so this patch remove
this unnecessary inclusion.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
commit ba18a9314a ("Revert "HID: i2c-hid: Add support for ACPI GPIO
interrupts"") removed the need for storing the irq in struct i2c_hid.
But then commit de3c99488609 ("HID: i2c-hid: Disable IRQ before freeing
buffers") forgot to update the location of the irq.
Fix this by using the actual I2C client irq.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add a forgotten include that I've by mistake omitted when resolving
merge conflict in ead0687fe30 ("HID: i2c-hid: support regulator power
on/off").
Fixes: ead0687fe30 ("HID: i2c-hid: support regulator power on/off")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The HID report buffers that are initially allocated on i2c_hid_probe()
might not be big enough to hold the HID reports from a specific device,
in which case they will be freed and new ones will be allocated in
i2c_hid_start(), at point which the device's report size is known. But
at this point ihid->irq is already running, and may call
i2c_hid_get_input() which passes ihid->inbuf to i2c_master_recv(). Since
this handler runs in a separate thread, ihid->inbuf may be freed at this
very moment, and i2c_master_recv() will write on memory which may be
already owned by a different part of the kernel, corrupting its data.
This problem has been observed on an Asus UX360UA laptop which has an
I2C touchpad, and results in a complete system freeze or an unusable
slowness with a lof of "BUG: unable to handle kernel paging request at
<address>" warnings. Enabling SLUB debugging shows a use-after-free
warning on memory allocated in i2c_hid_alloc_buffers() and freed in
i2c_hid_free_buffers():
=============================================================================
BUG kmalloc-64 (Not tainted): Poison overwritten
-----------------------------------------------------------------------------
Disabling lock debugging due to kernel taint
INFO: 0xffff880264083273-0xffff88026408329e. first byte 0x0 instead of 0x6b
INFO: Allocated in i2c_hid_alloc_buffers+0x25/0xa0 [i2c_hid] age=35793 cpu=2 pid=430
___slab_alloc+0x41e/0x460
__slab_alloc+0x20/0x40
__kmalloc+0x210/0x280
i2c_hid_alloc_buffers+0x25/0xa0 [i2c_hid]
i2c_hid_probe+0x12f/0x5e0 [i2c_hid]
i2c_device_probe+0x10a/0x1b0
driver_probe_device+0x220/0x4a0
__device_attach_driver+0x71/0xa0
bus_for_each_drv+0x67/0xb0
__device_attach+0xdc/0x170
device_initial_probe+0x13/0x20
bus_probe_device+0x92/0xa0
device_add+0x4aa/0x670
device_register+0x1a/0x20
i2c_new_device+0x18e/0x230
acpi_i2c_add_device+0x1a0/0x210
INFO: Freed in i2c_hid_free_buffers+0x16/0x60 [i2c_hid] age=7552 cpu=1 pid=1473
__slab_free+0x221/0x330
kfree+0x139/0x160
i2c_hid_free_buffers+0x16/0x60 [i2c_hid]
i2c_hid_start+0x2a9/0x2df [i2c_hid]
mt_probe+0x160/0x22e [hid_multitouch]
hid_device_probe+0xd7/0x150 [hid]
driver_probe_device+0x220/0x4a0
__driver_attach+0x84/0x90
bus_for_each_dev+0x6c/0xc0
driver_attach+0x1e/0x20
bus_add_driver+0x1c3/0x280
driver_register+0x60/0xe0
__hid_register_driver+0x53/0x90 [hid]
0xffffffffc004f01e
do_one_initcall+0xb3/0x1f0
do_init_module+0x5f/0x1d0
INFO: Slab 0xffffea0009902080 objects=20 used=20 fp=0x (null) flags=0x17fff8000004080
INFO: Object 0xffff880264083260 @offset=4704 fp=0x (null)
Bytes b4 ffff880264083250: 8d e6 fe ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
Object ffff880264083260: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880264083270: 6b 6b 6b 00 00 00 00 00 00 00 00 00 00 00 00 00 kkk.............
Object ffff880264083280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object ffff880264083290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Redzone ffff8802640832a0: bb bb bb bb bb bb bb bb ........
Padding ffff8802640833e0: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
CPU: 1 PID: 1503 Comm: python3 Tainted: G B 4.4.21+ #10
Hardware name: ASUSTeK COMPUTER INC. UX360UA/UX360UA, BIOS UX360UA.200 05/05/2016
0000000000000086 00000000622d48a2 ffff88026061ba38 ffffffff813f6044
ffff880264082010 ffff880264083260 ffff88026061ba78 ffffffff811e8eab
0000000000000008 ffff880200000001 ffff88026408329f ffff88026a007700
Call Trace:
[<ffffffff813f6044>] dump_stack+0x63/0x8f
[<ffffffff811e8eab>] print_trailer+0x14b/0x1f0
[<ffffffff811e94c1>] check_bytes_and_report+0xc1/0x100
[<ffffffff811e96c4>] check_object+0x1c4/0x240
[<ffffffff81293fde>] ? ext4_htree_store_dirent+0x3e/0x120
[<ffffffff811e9b44>] alloc_debug_processing+0x104/0x180
[<ffffffff811eb7be>] ___slab_alloc+0x41e/0x460
[<ffffffff81293fde>] ? ext4_htree_store_dirent+0x3e/0x120
[<ffffffff8124590b>] ? __getblk_gfp+0x2b/0x60
[<ffffffff8129b969>] ? ext4_getblk+0xa9/0x190
[<ffffffff811eb820>] __slab_alloc+0x20/0x40
[<ffffffff811ed320>] __kmalloc+0x210/0x280
[<ffffffff81293fde>] ? ext4_htree_store_dirent+0x3e/0x120
[<ffffffff812c1602>] ? ext4fs_dirhash+0xc2/0x2a0
[<ffffffff81293fde>] ext4_htree_store_dirent+0x3e/0x120
[<ffffffff812a4f47>] htree_dirblock_to_tree+0x187/0x1b0
[<ffffffff812a5fd2>] ext4_htree_fill_tree+0xb2/0x2e0
[<ffffffff811ebb7a>] ? kmem_cache_alloc_trace+0x1fa/0x220
[<ffffffff81293e45>] ? ext4_readdir+0x775/0x8b0
[<ffffffff81293cb1>] ext4_readdir+0x5e1/0x8b0
[<ffffffff81221c82>] iterate_dir+0x92/0x120
[<ffffffff81222118>] SyS_getdents+0x98/0x110
[<ffffffff81221d10>] ? iterate_dir+0x120/0x120
[<ffffffff818157f2>] entry_SYSCALL_64_fastpath+0x16/0x71
FIX kmalloc-64: Restoring 0xffff880264083273-0xffff88026408329e=0x6b
FIX kmalloc-64: Marking all objects used
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Function hid_post_reset() should return negative error codes on failures.
However, in its implementation, it incorrectly returns 1. This patch fixes the
bug, returning proper error codes on failures.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
post input_sync only when there are input events posted
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-By: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Make sure everything reported from pad are registered
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-By: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Sometime valid events may not be supported by the driver yet. Make
sure we don't process them when the code is not ready.
This fix prevents a kernel panic due to unsupported HID events.
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-By: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
It is unnecessary to return a value since nothing is expecting a
value from it.
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-By: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We have the %pU printf extension for doing exactly this. Saves some
.text, and is likely also a little faster.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Since the gpio-as-irq support has been added, the driver now depends
on proper support being available in gpiolib.
Fixes: 13de9cca51 ("HID: cp2112: add IRQ chip handling")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Update the hid-asus module to add multitouch support for the Asus i2c touchpad.
This patch aims to resolve the issue raised here:
https://bugzilla.kernel.org/show_bug.cgi?id=120181
The issue is in relation to an Asus touchpad device which currently does not
have multitouch support.
The device currently falls through to the hid-generic driver which
treats the device as a mouse.
This patch aims to add the multitouch support.
[jkosina@suse.cz: move most of the 'patch comment' into actual changelog]
[jkosina@suse.cz: drop hunk that changes ->name of the driver]
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Signed-off-by: Victor Vlasenko <victor.vlasenko@sysgears.com>
Signed-off-by: Frederik Wenigwieser <frederik.wenigwieser@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Although unlikely but it is possible that when a connect or disconnect
request is issued to the firmware, before the response comes, user
terminates the client session. In this case when the response is arrived
there is no matching client instance in the list of currently active
clients. In this case, don't issue call to wake up a waiting client.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add support for USB based DS4 dongle device, which allows connecting
a DS4 through Bluetooth, but hides Bluetooth from the host system.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The DS4 side of hid-sony used the hid-core layer to assign buttons
and axes based on the HID report descriptors. The default mapping
was strange e.g. right stick using ABS_Z/ABS_RZ or the physical
'south button' being reported as BTN_EAST etcetera.
This patch makes the DS4 side ofi the hid-sony driver comply to
the Linux game controller spec as suggested in a discussion with
Dmitry on the linux-input list.
Currently the main user of the DS4 is the SDL2 library, which has
a mapping table using vendor/device/version as a key. In order to
not break SDL2 we discussed adjusting the version number, so it
can have both mappings. This was discust on linux-input and we
discussed privately with SDL2 developers.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The dualshock 4 supports both analog sticks of which one uses
ABS_X/_Y and a touchpad. In a recent discussion with Dmitry about
some input-mt changes we proposed for disabling pointer emulation from
input_mt_sync_frame, Dmitry mentioned ABS_X/_Y should report the
same data as ABS_MT_POSITION_X/_Y. The current driver is mixing axes
for different subdevices. It was suggested to make the touchpad
its own sub-device.
This patch turns the touchpad into its own device. In addition
this patch also moves the button underneath the touchpad into
the new device. It felt like this button should be part of the
device. No known user space application (not even SDL2) seems to
be using it.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
A previous patch moved most input initialization from sony_probe to
sony_input_configured to avoid some race conditions. The driver has some
special logic to prevent the device to get registered twice in case the
user connects it both over Bluetooth and USB. When this condition
happens sony_input_configured returns a failure, but sony_probe continues
as hid_hw_start doesn't fail. As was discussed on linux-input, it is
acceptable for this function to fail.
This patch adds a check for the HID_CLAIMED_INPUT flag within sony_probe
to determine whether initialization succeeded correctly. The flag is
not set by the HID layer when sony_input_configured fails.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The GPIO part doesn't provide interrupts when GPIO are toggled.
So use a polling mechanism if someone requests a GPIO as an IRQ.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Instead of forcing the level trigger of the IRQ, we can count
on ACPI or OF to set it up for us.
The first release of the HID over I2C specification mentioned
that the level trigger needed to be active low. In the latest
version of the specification, there is no such explicit mention,
so it's better to not assume one.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We already have in place a quirk for Windows 8 devices, but it looks
like the Surface Cover are not conforming to it.
Given that we are only interested in 3 feature reports (the ones that
the Windows driver retrieves), we should be safe to unconditionally apply
the quirk to everybody.
In case there is an issue with a controller, we can always mark it as such
in the transport driver, and hid-multitouch won't try to retrieve the
feature report.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There is no reasons to filter out keyboard and consumer control collections
in hid-multitouch.
With the previous hid-input fix, there is now a full support of the Type
Cover and we can remove all specific bits from hid-core and hid-microsoft.
hid-multitouch will automatically set HID_QUIRK_NO_INIT_REPORTS so we can
also remove it from the list of ushbid quirks.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The purpose of HID_QUIRK_MULTI_INPUT is to have an input device per
report id. This is useful when the HID device presents several HID
collections of different device types.
The current implementation of hid-input creates one input node per id per
type (input or output). This is problematic for the LEDs of a keyboard as
they are often set through an output report. The current code creates
one input node with all the keyboard keys, and one other with only the
LEDs.
To solve this, we use a two-passes way:
- first, we initialize all input nodes and associate one per report id
- then, we register all the input nodes
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
According to https://msdn.microsoft.com/en-us/library/windows/hardware/mt604195(v=vs.85).aspx
external buttons have some weird usage mapping:
- Button 2 Indicates Button State for external button for primary
(default left) clicking.
- Button 3 Indicates Button State for external button for secondary
(default right) clicking.
So in the current state, the buttons are mapped to right and middle.
Move the usage by one to correctly map the external buttons.
Tested-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
One more device requiring a quirk :/
Reported-by: Christian-Nils Boda <christian-nils.boda@gadz.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
One more device requiring a quirk :/
[jkosina@suse.cz: update comment based on Bastien's remark]
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 user tried to read some fields like hysteresis from IIO sysfs on some
systems, it fails. The reason is that this field is a byte field and caller
of sensor_hub_get_feature() passes a buffer of 4 bytes. Here the function
sensor_hub_get_feature() copies the single byte from the report to the
caller buffer and returns "1" as the number of bytes copied. So caller
can use the return value.
But this is done by multiple callers, so if we just change the
sensor_hub_get_feature so that caller buffer is initialized with 0s
then we don't to change all functions.
Signed-off-by: Song Hongyan <hongyan.song@intel.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Adding support for not JP versions of the Microsoft Surface 4 Type Cover Pro
[jkosina@suse.cz: The identical patch has been sent by Jeff Farthing, so I am
including his signoff as well]
Signed-off-by: Jeff Farthing <jeff@jfarthing.com>
Signed-off-by: Daniel Keller <daniel.keller@gcd.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Kernel v4.9 strictly enforces DMA capable buffers, so we need to remove
buffers allocated on the stack.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Kernel v4.9 strictly enforces DMA capable buffers, so we need to remove
buffers allocated on the stack.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Kernel v4.9 strictly enforces DMA capable buffers, so we need to remove
buffers allocated on the stack.
[jkosina@suse.cz: fix up second usage of hid_hw_raw_request(), spotted by
0day build bot]
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Kernel v4.9 strictly enforces DMA capable buffers, so we need to remove
buffers allocated on the stack.
Use a spinlock to prevent concurrent accesses to the buffer.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
set_current_task() must be called before schedule_timeout(), for this
driver, in order to avoid incorrect usage, use msleep_interrupt()
instead.
Signed-off-by: Even Xu <even.xu@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The macro timed_wait_for_timeout() only be used in one function, so move
this marco from header file and change it to a function in ipc.c, where
it is used.
Signed-off-by: Even Xu <even.xu@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The macro timed_wait_for() in utils.h isn't used in current ipc
driver, so remove it for avoiding confusion.
Signed-off-by: Even Xu <even.xu@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This adds support for the THQ uDraw tablet for the PS3, as
4 separate device nodes, so that user-space can easily consume
events coming from the hardware.
Note that the touchpad two-finger support is fairly unreliable,
and a right-click can only be achieved with a two-finger tap
with the two fingers slightly apart (about 1cm should be enough).
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The eraser end of the 8K pen available for the MobileStudio Pro has a tool
ID of 0x84a. The 'wacom_intuos_get_tool_type' function does not currently
recognize this ID, causing it to return BTN_TOOL_PEN rather than
BTN_TOOL_RUBBER. This does not cause a problem for the MobileStudio Pro
since, as a HID_GENERIC device, the driver relies on the state of the
HID_DG_INVERT usage instead. It would, however, cause problems if the pen
is used with devices that use the traditional 'wacom_intuos_irq' codepath
instead.
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>
This is trying to clear the lower 32 bits but the type is wrong so it
clears everything.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Certain devices produced by Weida Tech need to have a wakeup command sent to
them before powering on. The call itself will come back with error, but the
device can be powered on afterwards.
[jkosina@suse.cz: rewrite changelog]
[jkosina@suse.cz: remove unused device ID addition]
Signed-off-by: HungNien Chen <hn.chen@weidahitech.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
ts_format.reserved is not used anywhere yet, but the compiler generates a
warning when the struct's (uninitialized) field is being copied around
drivers/hid/intel-ish-hid/ipc/ipc.c: In function ‘write_ipc_from_queue’:
drivers/hid/intel-ish-hid/ipc/ipc.c:316: warning: ‘ts_format.reserved’ may be used uninitialized in this function
Avoid this by force-initializing the field to zero.
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
User is unable to access to input-X-yyy and feature-X-yyy where
X is a hex value and more than 9 (e.g. input-a-yyy, feature-b-yyy) in HID
sensor custom sysfs interface.
This is because when creating the attribute, the attribute index is
written to using %x (hex). However, when reading and writing values into
the attribute, the attribute index is scanned using %d (decimal). Hence,
user is unable to access to attributes with index in hex values
(e.g. 'a', 'b', 'c') but able to access to attributes with index in
decimal values (e.g. 1, 2, 3,..).
This fix will change input-%d-%x-%s and feature-%d-%x-%s to input-%x-%x-%s
and feature-%x-%x-%s in show_values() and store_values() accordingly.
Signed-off-by: Ooi, Joyce <joyce.ooi@intel.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
On some platforms ISH interrupt is shared, which causes request_irq to
fail. This requires IRQF_SHARED irq flag.
But IRQF_NO_SUSPEND and IRQF_SHARED should not be used together, so
removed IRQF_NO_SUSPEND flag. Anyway this driver doesn't require
IRQF_NO_SUSPEND, as this interrupt is not required during "noirq" phases
of suspending and resuming devices as well as during the time when
nonboot CPUs are taken offline and brought back online.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When built as a module, modprobe followed by rmmod can fail because
DMA was still active. So to fix this, DMA needs to be disabled during
module exit.
This change disables DMA during modules exit and change the ISH PCI
device status to D3.
Signed-off-by: Even Xu <even.xu@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add a new function ish_disable_dma() and move DMA disable operations
here, so that this functionality can be reused.
Signed-off-by: Even Xu <even.xu@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Same operations are done in ish_hw_start() and _ish_hw_reset() to
wakeup ISH device. Consolidate them by introducing a new function
ish_wakeup() and move the code there.
Signed-off-by: Even Xu <even.xu@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add a new module named hid-mf that implements force feedback for game
controller adapters manufactured by Mayflash. Currently only the PS3 adapter is
supported, other adapters still need to be tested.
Signed-off-by: Marcel Hasler <mahasler@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
All known gamepad adapters by Mayflash (identified as Dragonrise) need
HID_QUIRK_MULTI_INPUT to split them up into four input devices. Without this
quirk those adapters are falsely recognized as tablets. Fixes bug 115841
(https://bugzilla.kernel.org/show_bug.cgi?id=115841).
Signed-off-by: Marcel Hasler <mahasler@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Like many similar devices it needs a quirk to work.
Issuing the request gets the device into an irrecoverable state.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
CC: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Fix
drivers/hid/intel-ish-hid/ipc/pci-ish.c:247:12: warning: ‘ish_suspend’ defined but not used [-Wunused-function]
static int ish_suspend(struct device *device)
^
drivers/hid/intel-ish-hid/ipc/pci-ish.c:282:12: warning: ‘ish_resume’ defined but not used [-Wunused-function]
static int ish_resume(struct device *device)
^
by sticking them in the CONFIG_PM range too.
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Wei Yongjun <weiyongjun1@huawei.com>
Cc: linux-input@vger.kernel.org
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When report count is more than one and report size is not 4 bytes, then we
need some packing into result buffer from the caller of function
sensor_hub_get_feature.
By default the value extracted from a field is 4 bytes from hid core
(using hid_hw_request(hsdev->hdev, report, HID_REQ_GET_REPORT)), even
if report size if less than 4 byte. So when we copy data to user buffer in
sensor_hub_get_feature, we need to only copy report size bytes even
when report count is more than 1. This is
not an issue for most of the sensor hub fields as report count will be 1
where we already copy only report size bytes, but some string fields
like description, it is a problem as the report count will be more than 1.
For example:
Field(6)
Physical(Sensor.OtherCustom)
Application(Sensor.Sensor)
Usage(11)
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Report Size(16)
Report Count(11)
Here since the report size is 2 bytes, we will have 2 additional bytes of
0s copied into user buffer, if we directly copy to user buffer from
report->field[]->value
This change will copy report size bytes into the buffer of caller for each
usage report->field[]->value. So for example without this change, the
data displayed for a custom sensor field "sensor-model":
76 00 101 00 110 00 111 00 118 00 111
(truncated to report count of 11)
With change
76 101 110 111 118 111 32 89 111 103 97
("Lenovo Yoga" in ASCII )
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The "Steering" usage (HID_UP_SIMULATION | 0xc8) is defined in HUT 1.12 as
follows:
"A steering wheel is a single degree-of-freedom device that rotates about
an axis. The zero position is always the neutral or 'straight ahead'
position, with positive values turning clockwise and negative values
turning counterclockwise. If the Coordinate Values Wrap attribute is
set, the steering wheel can be turned past 360 degrees."
The hidinput_configure_usage function canonically maps this usage to the
ABS_WHEEL axis, but hidinput_calc_abs_res does not recognize this axis
as one for which it can calculate a resolution. This effectively prevents
wheels from being assigned a proper resolution that userspace can use
to determine the precise angle of input.
This commit adds ABS_WHEEL as a rotational axis to hidinput_calc_abs_res.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The HID specification that the MobileStudio Pro follows includes usages
for several values that would be good to support so that future devices
"just work" out of the box. Extend the HID_GENERIC pad codepath to handle
these usages.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Adds support for usages that may appear on the pen or pad interface which
report the state of the tablet battery.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
As with usages for the pen, the Custom HID specificiation includes
usages for the pad. Here we add functions to map and handle most
of the pad usages present on the MobileStudio Pro.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Many of Wacom's display tablets include an "outbound" area where pen
digitizing is possible but outside of the display area. To accommodate
such sensors in the HID_GENERIC codepath, we add support for the
necessary vendor-defined HID feature usages and adjust the min/max
values of the X and Y axes accordingly, similar to what is done in
the non-generic codepath.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Many of Wacom's display tablets include an "outbound" area where pen
digitizing is possible but outside of the display area. To ensure that
pen coordinates are mapped to the correct on-screen location, the driver
sets the minimum and maximum axis values of X and Y to those coordinates
which coincide with the screen edge. These values are simply the
hardware minimum/maximum plus/minus the outbound size for a particular
edge.
When outbound support was added/updated in ac414da, fa77034, and
ecd618d, we decided to have the wacom_features structs store the desired
minimum and maximum values directly. In hindsight, this was perhaps not
the best choice since it has allowed minor errors to crop up unnoticed.
Some tablets have had their coordinates over-corrected (e.g. most of the
devices "fixed" in ecd618d were already adjusted in ac414da), while
others never had a correction applied (e.g. the ISDv5 325, whose
declared maximum the hardware maximum instead of the outbound maximum).
A less error-prone method of handling the outbound is to let the driver
calculate the correct minimum/maximum values by providing it with both
the actual hardware maximums and the size of the outbound on each edge.
These values are more easy to verify as correct since the values can be
trivially compared against specifications.
This patch reverts the declared maximum values to the actual hardware
maximums, e.g. as declared prior to ac414da (values for these and other
display tablets that were subsuquently introduced have been verified
against specs). Per-edge outbound sizes are stored in the wacom_features
struct as offset_{left,right,top,bottom} and used in combination with
the hardware ranges to calculate effective axis ranges for ABS_X and
ABS_Y.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Devices following the new Custom HID mode specification (as well as even
some recent component sensors which use the same standard HID usage)
are capable of reporting tool ID information that we need to relay to
userspace. This patch adds support for reading and relaying the tool
type information, which is (unfortunately) split across two usages.
We also advertise the existence of tool types beyond BTN_TOOL_PEN
that might be available.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The 'wacom_intuos_inout' function incorrectly assmebles tool IDs from the
proximity report, shifting the higher values of the ID four bits farther
than intended. This problem was not detected until too late, but has not
caused any issues since the incorrect IDs still fit in a 32-bit integer
and userspace programs have not required the value to match the hardware
(just that the values are unique and constant).
The tool IDs reported by the new MobileStudio Pro (or any future
HID_GENERIC device that supports them) do not suffer from the same
assembly issue, however. In order for 'wacom_intuos_get_tool_type' to
work for with both codepaths, we correct this issue internally and
have 'wacom_intuos_general' only mangle the ID when it is posted to
userspace.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Wacom's professional tablets beginning with the Intuos4 are capable of
reporting an intermediate degree of proximity where the pen is no longer
close enough to communicate with ("in prox"), but still close enough to
be sensed ("in range"). This additional state is particularly useful for
performing palm rejection as it allows the driver to disable the touch
sensor while the pen is a greater distance from the tablet.
Like other professional tablets, the new MobileStudio Pro also reports
this intermeidate "in range" proximity state. Its descriptor assigns
usage 0xff0d0036 to this bit. Normally 'wacom_equivalent_usage' would
translate this to the standard HID "Quality" usage, but since this has
a different meaning we have it explicitly ignore the usage and define
it ourselves as "Sense" (since "In Range" is already defined by the
HID standard and interpreted by our driver as meaning "in prox").
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The airbrush fingerwheel does not have a usage that corresponds cleanly
with a standard HID usage, so we add explicit support for it via its
vendor-defined usage.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The vendor-defined 0xFF0D01032 ("Distance") usage is nearly equivalent to
HID_GD_Z, except that the axis direction is inverted. Unlike HID_GD_Z which
increases in value as the pen-to-surface distance is decreased, this usage
decreases. Treat this usage as a special case to ensure we don't invert the
scale to be ABS_DISTANCE compatible like we do for HID_GD_Z.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Wacom's new "MobileStudio Pro" tablets are the first devices in their
branded product line-up to include a usable HID descriptor for the pen
interface. Like prior branded products, the device can operate in one
of two modes: 'Standard HID', and 'Wacom Custom HID'. Although the
first mode is usable by the HID_GENERIC codepath as-is (huzzah!), it is
subject to some restrictions -- most notably pressure being limited
to 2048 levels instead of 8192. To ensure tablets that include support
for Custom HID mode work optimally, we add support for its usages and
switch the device to Custom HID mode if possible.
The usages defined for Custom HID mode are often numerically similar to
their standard HID equivalents, allowing us to write a simple translation
function that takes arbitrary HID usages as input and which returns
the corresponding standard HID usage as output (if one exists). Switching
on this translated usage instead of the actual usage allows the existing
cases to apply to both modes of operation without having to explicitly
define every Custom HID usage.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The HID standard defines usages that allow digitizers to report the pen's
height, tilt, and rotation and which are used by Wacom's new "MobileStudio
Pro" devices.
Note that 'hidinput_calc_abs_res' expects ABS_Z (historically used by our
driver to report twist) to have linear units. To ensure it calculates a
resolution with the actually-angular units provided in the HID descriptor
we nedd to lie and tell it we're calculating it for the (rotational) ABS_RZ
axis instead.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The product name received from the string descriptor in the new MobileStudio
Pro line of tablets begins with "Wacom", which leads to unnecessary visual
noise in the device name when appended to the vendor name which also includes
"Wacom". Look for and fix cases like this.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
ISDv4 devices have long supported reporting data from each of two barrel
switches, but HID_DG_BARRELSWITCH2 itself was only recently standardized.
Prior to its adoption, ISDv4 devices would associate the bit indicating
the state of the second barrel switch with the "Undefined" 0x000D0000
usage. Although most such devices have explicit support, a few use the
HID_GENERIC codepath which ignores the "Undefined" usage.
This patch adds code which detects the presence of a pre-standard second
barrel switch and corrects the usage value so that the HID_GENERIC code
will declare its presence and report its state.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This just centralizes the logic used in both wacom_setup_numbered_buttons
and wacom_report_numbered_buttons so that they don't drift out of sync.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We've defined several new usages (e.g. WACOM_G9_PEN and WACOM_G9_TOUCHSCREEN)
which aren't checked by the WACOM_PEN_FIELD and WACOM_FINGER_FIELD macros but
probably should be.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Our loose use of "pen" and "digitizer" in the naming of several of our
vendor-defined usages may be a source of confusion given that the terms
have specific meaning within the HID specification. "Pen" specifically
refers to "an integrated display that allows the use of a stylus" (e.g.
something like a tablet PC or Cintiq) wheras "Digitizer" is a better
fit for opaque tablets like an Intuos.
While we're at it, go ahead and rename the definitions to make them more
distinct and better match up with the convention used by HID (e.g. the use
of '_UP_' for usage pages) and make them more distinct.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When i2c-core doesn't find the IRQ associated to the GPIO because
the gpiochip is not available, it assigns -EPROBE_DEFER to the irq.
We need to bail out there and on any other error in an IRQ.
Signed-off-by: David Arcari <darcari@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This reverts commit a485923efb ("HID: i2c-hid: Add support for ACPI
GPIO interrupts") and commit a7d2bf25a4 ("HID: i2c-hid: Do not fail
probing if gpiolib is not enabled") at the same time.
Since commit c884fbd452 ("gpio / ACPI: Add support for retrieving
GpioInt resources from a device") i2c_core already set the IRQ by
looking into the ACPI tree and retrieving the gpioInt. So we just
have some boiler-plate here that is not needed anymore.
The only downside effect here is that now we are not exiting early
enough if the irq is set to -EPROBE_DEFER or any other error, but
this is going to be fixed in the following patch.
Signed-off-by: David Arcari <darcari@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Akai MIDImix (09e8:0031) is a MIDI fader controller that speaks
regular MIDI and works well with Linux. However, initialization gets
delayed due to reports timeout:
[3643645.631124] hid-generic 0003:09E8:0031.0020: timeout initializing reports
[3643645.632416] hid-generic 0003:09E8:0031.0020: hiddev0: USB HID v1.11 Device [AKAI MIDI Mix] on usb-0000:00:14.0-2/input0
Adding "usbhid.quirks=0x09e8:0x0031:0x20000000" on the kernel
command line makes the issues go away.
Signed-off-by: Steinar H. Gunderson <sgunderson@bigfoot.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This reverts commit 18339f59c3 ("HID: dragonrise: fix HID...") because it
breaks certain dragonrise 0079:0006 gamepads. While it may fix a breakage
caused by commit 79346d620e ("HID: input: force generic axis to be mapped
to their user space axis"), it is probable that the manufacturer released
different hardware with the same PID so this fix works for only a subset
and breaks the other gamepads sharing the PID.
What is needed is another more generic solution which fixes 79346d620e
("HID: input: force generic axis ...") breakage for this controller: we
need to add an exception for this driver to make it keep the old behaviour
previous to the initial breakage (this is done in patch 2 of this series).
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit 79346d620e ("HID: input: force generic axis to be mapped to their
user space axis") made mapping generic axes to their userspace equivalents
mandatory and some lower end gamepads which were depending on the previous
behaviour suffered severe regressions because they were reusing axes and
expecting hid-input to multiplex their map to the respective userspace axis
by always searching for and using the next available axis.
One solution is to add a hid quirk for this type of "previous" behaviour in
hid-input to bypass the new axes policy in favour of the old one, but since
only one hardware vendor seems to be affected negatively we're better off
making and exception and mapping in the driver for now; if more vendors or
drivers turn out to experience the problem we should reconsider the quirk
solution.
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The motion sensor values are 16-bit, so make the value range match.
It is hard to reach the upper values, but they can be reached. At
least the current accelerometer value of 8192 is very easy to pass.
It is still not nice that the motion sensors live in no man's land
in between ABS_MISC and ABS_MT_SLOT, but that's something for another
time, which the proposed ABS_ACCEL_*/ABS_GYRO_* were meant for.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Read the touch history field in the HID descriptor and use this value
to determine how many touch events to read from the report. As part
of this patch, we did a first attempt of making the offset calculation
code less magical.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add a CRC value to each output report. This removes the need for the
'no output reports on interrupt end-point' quirk.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Put the report type (feature / output) in the report size definitions.
This prevents name collisions later on for other different reports, which use
the same report id, but have a different size.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Early on the sony_probe function calls hid_hw_start to start the hardware.
Afterwards it issues some hardware requests, initializes other functionality
like Force Feedback, power classes and others. However by the time
hid_hw_start returns, the device nodes have already been created, which leads
to a race condition by user space applications which may detect the device
prior to completion of initialization. We have observed this problem many
times, this patch fixes the problem.
This patch moves most of sony_probe to sony_input_configured, which is called
prior to device registration. This fixes the race condition and the same
approach is used in other HID drivers.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull HID updates from Jiri Kosina:
- Integrated Sensor Hub support (Cherrytrail+) from Srinivas Pandruvada
- Big cleanup of Wacom driver; namely it's now using devres, and the
standardized LED API so that libinput doesn't need to have root
access any more, with substantial amount of other cleanups
piggy-backing on top. All this from Benjamin Tissoires
- Report descriptor parsing would now ignore and out-of-range System
controls in case of the application actually being System Control.
This fixes quite some issues with several devices, and allows us to
remove a few ->report_fixup callbacks. From Benjamin Tissoires
- ... a lot of other assorted small fixes and device ID additions
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (76 commits)
HID: add missing \n to end of dev_warn messages
HID: alps: fix multitouch cursor issue
HID: hid-logitech: Documentation updates/corrections
HID: hid-logitech: Improve Wingman Formula Force GP support
HID: hid-logitech: Rewrite of descriptor for all DF wheels
HID: hid-logitech: Compute combined pedals value
HID: hid-logitech: Add combined pedal support Logitech wheels
HID: hid-logitech: Introduce control for combined pedals feature
HID: sony: Update copyright and add Dualshock 4 rate control note
HID: sony: Defer the initial USB Sixaxis output report
HID: sony: Relax duplicate checking for USB-only devices
Revert "HID: microsoft: fix invalid rdesc for 3k kbd"
HID: alps: fix error return code in alps_input_configured()
HID: alps: fix stick device not working after resume
HID: support for keyboard - Corsair STRAFE
HID: alps: Fix memory leak
HID: uclogic: Add support for UC-Logic TWHA60 v3
HID: uclogic: Override constant descriptors
HID: uclogic: Support UGTizer GP0610 partially
HID: uclogic: Add support for several more tablets
...
Issue reproduction procedure:
1. three or more fingers put on Touchpad.
2. release fingers from Touchpad.
3. move the cursor by one finger.
4. the cursor does not move.
Cause:
We do not notify multi fingers state correctly to input subsystem. For
example, when three fingers release from Touchpad, fingers state is 3 -> 0. It
needs to notify first, second and third finger's releasing state.
Fix this by not breaking out on z axis and move x,y,z input handling
code to the correct place so that it's in fact per-finger.
[jkosina@suse.cz: reword changelog]
Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Move ForceFeedback support for the Formula Force GP into hid-lgff4
and re-write HID descriptor, thus allowing combined pedals or not
as user desires.
Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Rewrite the HID descriptor for _all_ Driving Force wheels (real
or emulated) so that they can report separate Accelerator and
Brake axis.
If the user wants a combined accel/brake axis, they can use the
'combined pedals' feature.
$ echo 1 > /sys/bus/hid/devices/<device-id>/combine_pedals
Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add support for computing a combined accelerator/brake axis for wheels
which don't contain combined data in their HID stream.
This includes DFGT, G25, G27, G29 and Wii-Wheel.
Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add support for reporting a combined accelerator/brake axis for wheels
which contain combined data in their HID stream.
This includes DF, MOMO, MOMO2 and DFP.
Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Introduce a dev_attr which can be used to combine the accelerator
and brake pedals into a single axis. This is useful for older games
which can not handle seperate accelerator and brake.
Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Update the copyright notice with the current year and add a note
about values for controlling the Dualshock 4 reporting rate.
Processing reports at the default full rate of 1000hz can be too
demanding for some low-power embedded processors so noting
alternate values for people working with this hardware can be useful.
Thanks to Rostislav Pehlivanov for finding these values.
Signed-off-by: Frank Praznik <frank.praznik@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When initially connected via USB the Sixaxis isn't fully initialized
until the PS logo button is pressed and won't send any input reports
nor will any state set by output reports be retained.
This adds a 'defer_initialization' flag to the sony_sc struct which,
when set, will delay sending any output reports until the first input
report has arrived. This flag is used with the USB Sixaxis to ensure
that any state sent will persist since, until the PS button is pushed,
any changes sent to the controller via an output report will be lost
after a couple of seconds.
The initial state of the controller is still configured at the time
of the initial connection and won't be internally modified after that,
so any state set by the user between that time and the recepit of the
first input report won't be lost.
Signed-off-by: Frank Praznik <frank.praznik@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some USB-only devices which masquerade as Sixaxis controllers report the
same generic Bluetooth address for all hardware when queried via the HID
report. This causes these devices to be wrongly rejected as duplicates
when more than one is connected at once.
This introduces a connection type comparison when checking for duplicates
and only rejects the newly connected device if the existing matching
device is connected using a different connection protocol.
The results of the connection type comparison are also used when
registering power supply info as the device Bluetooth address is used
as the unique identifier string. In cases where more than one valid
device has the same Bluetooth address the device ID is now appended
to the power supply name string to avoid name collisions when
registering the power supply information.
Signed-off-by: Frank Praznik <frank.praznik@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This reverts commit 3ccc60f9d8.
While investigating bug https://bugzilla.kernel.org/show_bug.cgi?id=37982 ,
there was solid evidences that Microsoft reused the same report
descriptor for the its Digital Media keyboard series.
Since 1989dad "HID: input: ignore System Control application usages if not
System Controls", the keyboard series do not produce a spurious joystick
input device inode without needing to patch the problematic report
descriptor. As such the MS_RDESC_3K reportdescriptor fixup can be removed.
Signed-off-by: Michel Hermier <michel.hermier@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
While at it, remove redundant input_free_device(NULL) call.
[jkosina@suse.cz: ammend changelog]
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The stick device does not work after resume, add U1_SP_ABS_MODE flag can
make the device work after resume.
This has been discovered by pure guesswork, based on how the existing code uses
U1_TP_ABS_MODE flag on both initialization and resume.
I also tested the the patch on an ALPS touchpad without stick device, did not
notice any side effect on suspend/resume, so I made the U1_SP_ABS_MODE flag
mandatory.
[jkosina@suse.cz: made changelog more verbose]
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add quirk for Corsair STRAFE keyboard, similarly to what we've been
doing for other CORSAIR devices already, in order to avoid long delays
during boot.
[jkosina@suse.cz: reword changelog a little bit]
Signed-off-by: Marian Krivos <marian.krivos@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
A kfree(readbuf) call was missed if hid_hw_raw_request() fails, fix it.
Also avoid mixing direct return with goto in the error paths.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add support for the third version of UC-Logic TWHA60, which has
three interfaces and responds to initialization.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Make uclogic_report_fixup override constant descriptors with generated
descriptors, so models reusing product ID, but working with generated
descriptor get correct one.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add partial support for the UGTizer GP0610 tablet (aka iBall PF1064U,
aka UGTizer GT1060) to the hid-uclogic.c driver.
The pen input is supported fully, but frame buttons and wheel don't work
yet.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Based on a patch from: Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com>
Enable abstract keyboard mode for Huion tablets, which makes them report
frame buttons using the pen interface and report ID. Divert these
reports to a virtual report ID describing them.
This makes the tablet compatible with xf86-input-wacom and libinput,
but stops the frame buttons from reporting keyboard events.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Remove unnecessary allocation failure messages from hid-uclogic.c,
following the checkpatch.pl recommendations.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add a dedicated, fixed report descriptor for the second version of KYE
MousePen i608X graphics tablet. The descriptor fixes pressure and
drawing area ranges.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Rename the device ID macro for the second version of KYE MousePen i608x
graphics tablet to have "V" in its name to signify that "2" is a
version.
I.e. USB_DEVICE_ID_KYE_MOUSEPEN_I608X_2 ->
USB_DEVICE_ID_KYE_MOUSEPEN_I608X_V2
This also makes applying additional fixes from DIGImend easier.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Remove comments with broken links to tablet descriptions from
hid-kye/uclogic/waltop drivers.
They pointed to now dead DIGImend project wiki at sf.net. Even though
the DIGImend project still hosts descriptions, now at
digimend.github.io, it's better to avoid them going stale again, and let
anyone interested search the web instead.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Microsoft is reusing its report descriptor again and again, and part of it
looks like this:
0x05, 0x01, // Usage Page (Generic Desktop) 299
0x09, 0x80, // Usage (System Control) 301
0xa1, 0x01, // Collection (Application) 303
0x85, 0x03, // Report ID (3) 305
0x19, 0x00, // Usage Minimum (0) 307
0x29, 0xff, // Usage Maximum (255) 309
0x15, 0x00, // Logical Minimum (0) 311
0x26, 0xff, 0x00, // Logical Maximum (255) 313
0x81, 0x00, // Input (Data,Arr,Abs) 316
0xc0, // End Collection 318
While there is nothing wrong in term of processing, we do however blindly
map the full usage range (it's an array) from 0x00 to 0xff, which creates
some interesting axis, like ABS_X|Y, and a bunch of ABS_MISC + n.
While libinput and other stacks don't care that much (we can detect them),
joydev is very happy and attaches itself to the mouse or keyboard.
The problem is that joydev now handles the device as a joystick, but given
that we have a HID array, it sets all the ABS_* values to 0. And in its
world, 0 means -32767 (minimum value), which sends spurious events to games
(think Steam).
It looks like hid-microsoft tries to tackle the very same problem with its
.report_fixup callback. But fixing the report descriptor is an endless task
and is quite obfuscated.
So take the hammer, and decide that if the application is meant to be
System Control, any other usage not in the System Control range should
be ignored.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1325354
Link: https://bugzilla.kernel.org/show_bug.cgi?id=28912
Link: https://github.com/ValveSoftware/steam-for-linux/issues/3384
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1325354
Link: https://bugzilla.kernel.org/show_bug.cgi?id=37982
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Many modules call misc_register and misc_deregister in its module init
and exit methods without any additional code. This ends up being
boilerplate. This patch adds helper macro module_misc_device(), that
replaces module_init()/ module_exit() with template functions.
This patch also converts drivers to use new macro.
Change since v1:
Add device.h include in miscdevice.h as module_driver macro was not
available from other include files in some architectures.
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use kzalloc rather than kmalloc followed by memset with 0.
Generated by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci
Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Use the module_pci_driver() macro to make the code simpler
by eliminating module_init and module_exit calls.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Adding support for the Microsoft Surface 4 Type Cover Pro (JP).
Signed-off-by: Yuta Kobayashi <alu.ula@outlook.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Need enum quirk to change the base of enums to 1 for
power and report descriptors.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This driver is responsible for implementing ISH HID client, which
gets HID description and report. Once it has completely gets
report descriptors, it registers as a HID LL drivers. This implements
necessary callbacks so that it can be used by HID sensor hub driver.
Original-author: Daniel Drubin <daniel.drubin@intel.com>
Reviewed-and-tested-by: Ooi, Joyce <joyce.ooi@intel.com>
Tested-by: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Rann Bar-On <rb6@duke.edu>
Tested-by: Atri Bhattacharya <badshah400@aim.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This layer is responsible for
- Enumerating over PCI bus
- Inform FW about host readiness
- Provide HW interface to transport layer for control and messages
- Interrupt handling and routing
Original-author: Daniel Drubin <daniel.drubin@intel.com>
Reviewed-and-tested-by: Ooi, Joyce <joyce.ooi@intel.com>
Tested-by: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Rann Bar-On <rb6@duke.edu>
Tested-by: Atri Bhattacharya <badshah400@aim.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The ISH transport layer (ishtp) is a bi-directional protocol implemented
on the top of PCI based inter processor communication layer. This layer
offers:
- Connection management
- Flow control with the firmware
- Multiple client sessions
- Client message transfer
- Client message reception
- DMA for RX and TX for fast data transfer
Refer to Documentation/hid/intel-ish-hid.txt for
overview of the functionality implemented in this layer.
Original-author: Daniel Drubin <daniel.drubin@intel.com>
Reviewed-and-tested-by: Ooi, Joyce <joyce.ooi@intel.com>
Tested-by: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Rann Bar-On <rb6@duke.edu>
Tested-by: Atri Bhattacharya <badshah400@aim.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
If a touchscreen contains both multitouch and single-touch reports in its
descriptor in that order, the driver may overwrite information it saved
about the format of the multitouch report. This can cause the report
processing code to get tripped up and send an incorrect event stream to
userspace.
In particular, this can cause last_slot_field to be overwritten with the
result that the driver prematurely assumes it has finished processing a
slot and sending the ABS_MT_SLOT event at the wrong point in time,
associating events for the current contact with the following contact
instead.
To prevent this from occurring, we update the value of last_slot_field
durring the pre_report phase to ensure that it is correct for the report
that is to be processed.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Touch arbitration is always on in wacom.ko. However, there are
touch enabled applications use both pen and touch simultaneously.
We should provide an option for userland to decide if they want
arbitration on or off.
This patch sets default touch_arbitration to on since most userland
apps are not ready to process pen and touch events simultaneously.
In the future, when userland is ready to accept pen and touch events
together, we will switch default touch_arbitration to off.
Tested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The 'oVid' and 'oPid' variables used by wacom_are_sibling are a hacky
solution to the problem of the driver historically having few good
heuristics to use in determining if two devices should be considered
siblings or not. While it works well enough for explicitly supported
devices, it offers no help for HID_GENERIC devices. Now that we have
a bit more information (e.g. direct/indirect) available to us though,
we should make use of it it to improve the pairing of such devices.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
"Direct" input devices like Cintiqs and Tablet PCs set the INPUT_PROP_DIRECT
property to notify userspace that the sensor and screen are overlaid. This
information can also be useful elsewhere within the kernel driver, however,
so we introduce a new WACOM_DEVICETYPE_DIRECT that signals this to other
kernel code.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Instead of displaying a generic "tablet", now g-c-c shows a pretty
"Wacom Intuos Pro S (WL)".
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Looks like upowerd is ignoring this since October 2013, so there is
no need to keep this around in the kernel.
And as mentioned in 8aaa592 (linux: Ignore ACs coming from devices) in
the upower tree, "We already have enough information on the device
battery".
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When upowerd detects a new device, it tries to map this new device to
an input to guess its kind. It works OK for wired tablets when the
wireless module and its battery are attached, but not so well when
connected over wireless.
In that case, the battery is attached to the wireless HID node, not
the Pen or Pad HID node. So there is no input node as a parent of the
reported battery, which means it will be showed as a computer battery
in gnome-control-center.
If we set the power supply type to USB, upowerd has a heuristic that
detects "wacom_" in the name of the power_supply, and set the type to
tablet. So it's now clear that the reported battery of from a tablet.
(see https://cgit.freedesktop.org/upower/tree/src/linux/up-device-supply.c)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The 24HD has 1 button per LED (first three buttons of each group).
We need a special treatment for them as it's not a uniq button that
switches between the LEDs.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The code for 21UX2 and 24HD makes the LED group 1 on the left, and
the group 0 on the right. The buttons are ordered in the other way,
but libwacom already exports those that way. So we simply can't reassign
LED group 0 to the left buttons, and have to quirk the incoming data...
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The EKR switches the LED directly, and there is no point in having
userspace handling the switch it self when it's easy enough to do
in the kernel.
The other benefit is that now userspace does not need to have root access
to the LED but need only to read them with user privileges.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There is a bug (?) in devm_led_classdev_register() in which its increments
the refcount of the parent. If the parent is an input device, that means
the ref count never reaches 0 when devm_input_device_release() gets called.
This means that the LEDs and all the devres resources attached to the
input device are not released.
Manually force the release of the group so that the leds are released once
we are done using them.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The now obsolete sysfs files for LEDs and EKRemote are kept for backward
compatibility.
Both the EKR (read-only) and the regular Cintiqs and Intuos are now
sharing the same led API.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Or Gnome complains about an empty battery.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Previously, all the remotes attached to the same receiver would share the
same power_supply. That's not good as the remotes will constantly change
the battery information according to their own state.
To have something generic enough, we introduce struct wacom_battery
which regroups all the information we need for a battery.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Thanks to devres, we can now afford to create more than one input node
without having to overload the remove/failure paths. Having one input
node per remote is something which should have been implemented from start
but the probability of having users with several remotes is quite low.
Anyway, still, better looking at the future and implement things properly.
Remote input nodes will be freed/unregistered magically as they are
created in the devres group &remote->remotes[index].
We need to open the hid node now that the remotes are dynamically
allocated.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
No functional changes, just a prep patch for the one after.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This will be useful when each remote will be assigned its own input device.
We won't need to unregister each input and sysfs and other elements one
at a time.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The wacom_remote_create_attr_group() and wacom_remote_destroy_attr_group()
functions were both allocating/destroying the sysfs groups but also
initializing the parameters for the remotes. Have proper functions
that can be called and extended.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Thanks to devres management, we don't need to remember a lot of failure
path. One or two is enough.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
If we want to have one input device per remote, it's better to have our
own struct wacom_remote which is dynamically allocated.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
wacom_remote_status_irq() sends information of addition/removal of EKR.
We want to allocate one input node per remote, so better having this
in a separate worker, not handled in the IRQ directly.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
