USB device
Vendor 05ac (Apple)
Device 0267 (Magic Keyboard)
This keyboard supports both Bluetooth and USB connections, this patch
only covers USB.
Thanks to Maxime Poulin <maxpoulin64@gmail.com>
Signed-off-by: Jean-Gabriel Gill-Couture <jeangab@jeangab.fr.nf>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Properly handle this __le16 value on big endian systems.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add support for Greynut Luxafor. This device has two groups of three
independent LED's each.
Successfully tested with such a device.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add support for the HID-compliant Delcom Visual Signal Indicator
generation 2 devices.
Successfully tested with part no 904000 from the family of these devices.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Delcom uses the report id to submit command information. To be able to
use the hidled framework also for Delcom devices we have to remove the
report id from struct hidled_config.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The usage Confidence is mandary to Windows Precision Touchpad devices. If
it is examined in input_mapping on a WIndows Precision Touchpad, a new add
quirk MT_QUIRK_CONFIDENCE desgned for such devices will be applied to the
device. A touch with the confidence bit is not set is determined as
invalid.
Tested on Dell XPS13 9343
Cc: stable@vger.kernel.org # v4.5+
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andy Lutomirski <luto@kernel.org> # XPS 13 9350, BIOS 1.4.3
Signed-off-by: Allen Hung <allen_hung@dell.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This reverts commit 25a84db15b ("HID: multitouch: enable palm rejection
if device implements confidence usage")
The commit enables palm rejection for Win8 Precision Touchpad devices but
the quirk MT_QUIRK_VALID_IS_CONFIDENCE it is using is not working very
properly. This quirk is originally designed for some WIn7 touchscreens. Use
of this for a Win8 Precision Touchpad will cause unexpected pointer jumping
problem.
Cc: stable@vger.kernel.org # v4.5+
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andy Lutomirski <luto@kernel.org> # XPS 13 9350, BIOS 1.4.3
Signed-off-by: Allen Hung <allen_hung@dell.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch validates the num_values parameter from userland during the
HIDIOCGUSAGES and HIDIOCSUSAGES commands. Previously, if the report id was set
to HID_REPORT_ID_UNKNOWN, we would fail to validate the num_values parameter
leading to a heap overflow.
Cc: stable@vger.kernel.org
Signed-off-by: Scott Bauer <sbauer@plzdonthack.me>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Remove an unnecessary codes.
Change input_ivent() function to appropriate function.
Add the device ID of "HID_DEVICE_ID_ALPS_U1_DUAL".
[jkosina@suse.cz: removed unnecessary bitshifts of values passed
input_report_key() as spotted by Dmitry]
Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Now that support for ThingM blink(1) was merged into the hid-led driver
the dedicated driver for this device can be removed.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Acked-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add support for ThingM blink(1) and make the dedicated ThingM driver
obsolete.
Successfully tested with a blink(1) mk2.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add i2c_hid_shutdown for i2c-hid driver to send suspend cmd & free
irq before device shutdown.
Some HW design (i.e. Umaro, a chromebook model) is that the power to
i2c hid device won't down after device shutdown. Also the i2c-hid driver
do not send suspend cmd to the hid i2c device and free its irq before
shutdown.So if We touch the touchscreen or some other i2c hid device,
the power consumtion will be go up even when the device is in shutdown
state.
Though the root cause maybe a HW issue. But it seems that it is a
good pratice to set power sleep for i2c-hid device before shutdown.
Signed-off-by: Guohua Zhong <ghzhong@yifangdigital.com>
Acked-By: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
All devices with ALPS_JP VID are handled by hid-alps driver, hence they require
an entry in hid_have_special_driver[].
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Kernel printf format %*ph allows to print small buffers up to 64 bytes.
Make use of it to simplify the debug output code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Calculating size of the report as sizeof(pointer) always passess the length
corresponding to the pointer type, not the underlying data report.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The driver port was done carefully not to depend on USB at all, in favor of
being generic HID driver instead. Therefore there is no need to explicitly
talk about USB only in the config.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch migrates the USB LED driver to the HID subsystem.
Supported are Dream Cheeky Webmail Notifier / Friends Alert
and Riso Kagaku Webmail Notifier.
Benefits:
- Avoid using USB low-level calls and use the HID subsystem instead
(as this device provides a USB HID interface)
- Use standard LED subsystem instead of proprietary sysfs entries,
this allows e.g. to use the device with features like triggers
Successfully tested with a Dream Cheeky Webmail Notifier and a
Riso Kagaku Webmail Notifier compatible device.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
i2c-hid devices' suspend/resume are usually time-consuming process.
For example, the touch controller(i2c-ATML1000:00) on ASUS T100 tablet
takes about 160ms for suspending and 120ms for resuming. This patch
enables i2c-hid devices to suspend/resume asynchronously. This will
take advantage of multicore and speed up system suspend/resume process.
Signed-off-by: Zhonghui Fu <zhonghui.fu@linux.intel.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Many devices use userspace bluetooth stacks like BlueZ or Bluedroid in combination
with uhid. If any of these stacks is used with a HID device for which the driver
performs a HID request as part .probe (or technically another HID operation),
this results in a deadlock situation. The deadlock results in a 5 second timeout
for I/O operations in HID drivers, so isn't fatal, but none of the I/O operations
have a chance of succeeding.
The root cause for the problem is that uhid only allows for one request to be
processed at a time per uhid instance and locks out other operations. This means
that if a user space is creating a new HID device through 'UHID_CREATE', which
ultimately triggers '.probe' through the HID layer. Then any HID request e.g. a
read for calibration data would trigger a HID operation on uhid again, but it
won't go out to userspace, because it is still stuck in UHID_CREATE.
In addition bluetooth stacks are typically single threaded, so they wouldn't be
able to handle any requests while waiting on uhid.
Lucikly the UHID spec is somewhat flexible and allows for fixing the issue,
without breaking user space. The idea which the patch implements as discussed
with David Herrmann is to decouple adding of a hid device (which triggers .probe)
from UHID_CREATE. The work will kick off roughly once UHID_CREATE completed (or
else will wait a tiny bit of time in .probe for a lock). A HID driver has to call
HID to call 'hid_hw_start()' as part of .probe once it is ready for I/O, which
triggers UHID_START to user space. Any HID operations should function now within
.probe and won't deadlock because userspace is stuck on UHID_CREATE.
We verified this patch on Bluedroid with Android 6.0 and on desktop Linux with
BlueZ stacks. Prior to the patch they had the deadlock issue.
[jkosina@suse.cz: reword subject]
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The firmware found in the touch screen of an SP3 is buggy and may miss
to send lift off reports for contacts. Try to work around that issue by
using MT_QUIRK_NOT_SEEN_MEANS_UP.
based on a patch from: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Flushing a work that reschedules itself is not a sensible operation. It needs
to be killed. Failure to do so leads to a kernel panic in the timer code.
CC: stable@vger.kernel.org
Signed-off-by: Oliver Neukum <ONeukum@suse.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit 7e12978 ("HID: wacom: break out wacom_intuos_get_tool_type") by accident
removed stylus_in_proximity flag for Intuos series while shuffling the code
around.
Fix that by reintroducing that flag setting in wacom_intuos_inout(), where
it originally was.
Fixes: 7e12978 ("HID: wacom: break out wacom_intuos_get_tool_type")
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The fuzz present on the distance and tilt axes is noticable when a puck is
present, and userspace (specifically libinput) would like the ability to
filter out the noise. To facilitate this, we assign a fuzz value of '1'
for the distance and tilt axes. This is large enough to cover most of the
natural variation in distance value as the puck is moved around, and
enough to cover the jitter in rotation (reported through tilt axes) when
the puck is left alone.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
These devices feature multiple interfaces/endpoints: a legacy BIOS/boot
interface (endpoint 0x81), as well as 2 corsair-specific keyboard interfaces
(endpoint 0x82, 0x83 IN/0x03 OUT) and an RGB LED control interface (endpoint
0x84 IN/0x04 OUT)
Because the extra 3 interfaces are not of subclass USB_INTERFACE_SUBCLASS_BOOT,
HID_QUIRK_NOGET is not automatically set on them and a 10s timeout per-endpoint
(30s per device) occurs initialising reports on boot. We configure
HID_QUIRK_NO_INIT_REPORTS for these devices.
Additionally the left-side G1-G18 macro keys on the K95RGB generate output on
the un-opened 0x82/0x83 endpoints which causes the keyboard to stop responding
waiting for this event to be collected. We enable HID_QUIRK_ALWAYS_POLL to
prevent this situation from occurring.
Signed-off-by: Trent Lloyd <trent@lloyd.id.au>
Tested-by: SUGNIAUX Wilfried <wsu@ppharm2k20.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Needed for v2 of the device firmware, otherwise kernel will stuck for few
seconds and throw "usb_submit_urb(ctrl) failed: -1" early on system boot.
Signed-off-by: Nazar Mokrynskyi <nazar@mokrynskyi.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
LED core takes care of handling failed calls to thingm_let_set.
- print error message in set_brightness_delayed or
- pass error to caller in led_set_brightness_sync
Also the error message here doesn't provide any hint what actually
went wrong. Therefore remove it.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@rehat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Use recently introduced flag LED_HW_PLUGGABLE to avoid warnings when
the device is unplugged.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull HID fixes from Jiri Kosina:
- fix for how scaling linearization is computed in wiimote driver, by
Cyan Ogilvie
- endless retry loop fix in generic USB HID core reset-resume handling,
by Alan Stern
- two functional fixes affecting particular devices, and oops fix for
wacom driver, by Jason Gerecke
- multitouch slot numbering fix from Gabriele Mazzotta
- a couple more small fixes on top
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: wacom: Support switching from vendor-defined device mode on G9 and G11
HID: wacom: Initialize hid_data.inputmode to -1
HID: microsoft: add support for 3 more devices
HID: multitouch: Synchronize MT frame on reset_resume
HID: wacom: fix Bamboo ONE oops
HID: lenovo: Don't use stack variables for DMA buffers
HID: usbhid: fix inconsistent reset/resume/reset-resume behavior
HID: wiimote: Fix wiimote mp scale linearization
The 'size' variable is not really needed, and we can also shift constant
in the loop body when masking off existing bits.
Also we do not have to use 64 bit calculations if we take an extra
branch.
[jkosina@suse.cz: fix a small error in changelog]
Suggested-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
A tablet PC booted into Windows may have its pen/touch hardware switched
into "Wacom mode" similar to what we do with explicitly-supported hardware.
Some devices appear to maintain this state across reboots, preventing their
use with the generic HID driver. This patch adds support for detecting the
presence of the mode switch feature report used by devices based on the G9
and G11 chips and has the HID codepath always attempt to reset the device
back to sending standard HID reports.
Fixes: https://sourceforge.net/p/linuxwacom/bugs/307/
Fixes: https://sourceforge.net/p/linuxwacom/bugs/310/
Fixes: https://github.com/linuxwacom/input-wacom/issues/15
Co-authored-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
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>
Commit 5ae6e89 introduced hid_data.inputmode with a comment that it
would have the value -1 if undefined, but then forgot to actually
perform the initialization. Although this doesn't appear to have
caused any problems in practice, it should still be remedied.
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 the Micrsift Digital 4K, Media 600 and Media 3000 V1 Keyboards,
which have the same quirks as the already existing hardware MS_NE4K.
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=52841
[jkosina@suse.cz: rephrase changelog]
Signed-off-by: Alistair Leslie-Hughes <leslie_alistair@hotmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Asus X205TA and E200HA built-in keyboard contain wrong logical maximum value in
report descriptor.
This patch correct wrong logical maximum in report descriptor.
Signed-off-by: Yusuke Fujimaki <usk.fujimaki@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
My static checker complains that "devid" can be uninitialized if
alloc_chrdev_region() fails. Fix this by moving the error hanling
forward a couple lines.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
My static checker complains because we use "dev_id" before we check for
errors so it could be uninitialized. Fix this by moving the error
handling forward a couple lines.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
input_mt_get_slot_by_key() requires input_mt_sync_frame() to be called
at each frame. Do it when releasing the touches, or else we won't get
a proper slot number after mt_reset_resume().
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Benjamin TIssoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Looks like recent changes in the Wacom driver made the Bamboo ONE crashes.
The tablet behaves as if it was a regular Bamboo device with pen, touch
and pad, but there is no physical pad connected to it.
The weird part is that the pad is still sending events and given that
there is no input node connected to it, we get anull pointer exception.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1317116
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The lenovo_send_cmd_cptkbd function uses a stack variable to submit
commands via hid_hw_raw_request. Eventually this gets to the
usb_hcd_map_urb_for_dma function, which causes a warning to be thrown
if the CONFIG_DMA_API_DEBUG option is enabled.
Fix this by allocating a temporary buffer instead.
[jkosina@suse.cz: no need to NULL-initialize buf, spotted by Benjamin]
Reported-by: lejeczek <peljasz@yahoo.co.uk>
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
