- 02 May, 2017 1 commit
-
-
Jiri Kosina authored
Merge branches 'for-4.11/upstream-fixes', 'for-4.12/accutouch', 'for-4.12/cp2112', 'for-4.12/hid-core-null-state-handling', 'for-4.12/hiddev', 'for-4.12/i2c-hid', 'for-4.12/innomedia', 'for-4.12/logitech-hidpp-battery-power-supply', 'for-4.12/multitouch', 'for-4.12/nti', 'for-4.12/upstream' and 'for-4.12/wacom' into for-linus
-
- 26 Apr, 2017 1 commit
-
-
Vasilis Liaskovitis authored
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>
-
- 20 Apr, 2017 1 commit
-
-
Jason Gerecke authored
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 60a22186 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: 60a22186 ("HID: wacom: generic: add support for touchring") Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 19 Apr, 2017 1 commit
-
-
Jason Gerecke authored
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: f85c9dc6 ("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>
-
- 11 Apr, 2017 1 commit
-
-
Jiri Kosina authored
This reverts commit 279967a6. Multiple regressions [1] [2] [3] have been reported. The hid-rmi support would have to fixed and redone in 4.11+. [1] http://lkml.kernel.org/r/b79b88c8-770a-13f6-5668-c3a94254e5e0@gmail.com [2] http://lkml.kernel.org/r/375e67b5-2cb8-3491-1d71-d8650d6e9451@gmail.com [3] https://bugzilla.kernel.org/show_bug.cgi?id=195287Reported-by: Cameron Gutman <aicommander@gmail.com> Reported-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Reported-by: Lorenzo J. Lucchini <ljlbox@tiscali.it> Reported-by: Thorsten Leemhuis <linux@leemhuis.info> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 06 Apr, 2017 22 commits
-
-
Jason Gerecke authored
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>
-
Ping Cheng authored
Commits d793ff81 and 4082da80 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>
-
Xiaolei Yu authored
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>
-
Benjamin Tissoires authored
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>
-
Benjamin Tissoires authored
Also enable battery reporting for HID++ 1.0 devices through 2 registers: 0x07: battery status -> reports only 4 levels (critical, low, good, full) 0x0D: battery mileage -> reports true pourcentage Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
Benjamin Tissoires authored
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>
-
Benjamin Tissoires authored
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>
-
Benjamin Tissoires authored
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>
-
Benjamin Tissoires authored
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>
-
Benjamin Tissoires authored
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>
-
Benjamin Tissoires authored
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>
-
Benjamin Tissoires authored
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>
-
Benjamin Tissoires authored
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>
-
Benjamin Tissoires authored
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>
-
Benjamin Tissoires authored
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>
-
Benjamin Tissoires authored
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>
-
Benjamin Tissoires authored
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>
-
Benjamin Tissoires authored
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>
-
Benjamin Tissoires authored
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>
-
Benjamin Tissoires authored
Simple check to add, huge improvement :) Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
Bastien Nocera authored
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>
-
Benjamin Tissoires authored
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>
-
- 30 Mar, 2017 4 commits
-
-
Aaron Armstrong Skomra authored
Commit 3b164a00 ("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>
-
Aaron Armstrong Skomra authored
Commit a544c619 ("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>
-
Aaron Armstrong Skomra authored
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: 41372d5d ("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>
-
Xiaolei Yu authored
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>
-
- 24 Mar, 2017 1 commit
-
-
Peter Stein authored
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>
-
- 21 Mar, 2017 8 commits
-
-
Bartosz Golaszewski authored
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>
-
Jaejoong Kim authored
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>
-
Jaejoong Kim authored
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>
-
Martyn Welch authored
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>
-
Benjamin Tissoires authored
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>
-
Tomasz Kramkowski authored
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 3f375270 ("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).aspSigned-off-by: Tomasz Kramkowski <tk@the-tk.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
Ping Cheng authored
Commit f85c9dc6 ("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>
-
Oscar Campos authored
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>
-