- 13 Apr, 2015 1 commit
-
-
Jiri Kosina authored
Merge branches 'for-4.0/upstream-fixes', 'for-4.1/genius', 'for-4.1/huion-uclogic-merge', 'for-4.1/i2c-hid', 'for-4.1/kconfig-drop-expert-dependency', 'for-4.1/logitech', 'for-4.1/multitouch', 'for-4.1/rmi', 'for-4.1/sony', 'for-4.1/upstream' and 'for-4.1/wacom' into for-linus
-
- 10 Apr, 2015 1 commit
-
-
Jiri Kosina authored
In the unlikely case of hdev vanishing while hid_debug_events_read() was sleeping, we can't really break out of the case switch as with other cases, as on the way out we'll try to remove ourselves from the hdev waitqueue. Fix this by taking a shortcut exit path and avoiding cleanup that doesn't make sense in case hdev doesn't exist any more anyway. Reported-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
Jiri Kosina <jkosina@suse.cz>
-
- 07 Apr, 2015 1 commit
-
-
Benjamin Tissoires authored
The case occurred recently with a touchscreen using twice a slot during a single EV_SYN event: E: 0.288415 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 0.296207 0003 002f 0000 # EV_ABS / ABS_MT_SLOT 0 E: 0.296207 0003 0039 -001 # EV_ABS / ABS_MT_TRACKING_ID -1 E: 0.296207 0003 002f 0001 # EV_ABS / ABS_MT_SLOT 1 E: 0.296207 0003 0035 0908 # EV_ABS / ABS_MT_POSITION_X 908 E: 0.296207 0003 0036 1062 # EV_ABS / ABS_MT_POSITION_Y 1062 E: 0.296207 0003 002f 0000 # EV_ABS / ABS_MT_SLOT 0 E: 0.296207 0003 0039 8787 # EV_ABS / ABS_MT_TRACKING_ID 8787 E: 0.296207 0003 0035 1566 # EV_ABS / ABS_MT_POSITION_X 1566 E: 0.296207 0003 0036 0861 # EV_ABS / ABS_MT_POSITION_Y 861 E: 0.296207 0003 0000 0908 # EV_ABS / ABS_X 908 E: 0.296207 0003 0001 1062 # EV_ABS / ABS_Y 1062 E: 0.296207 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- This occurred because while having already slots 0 and 1 assigned, the touchscreen sent: 0.293377 Tip Switch: 0 | Contact Id: 0 | X: 539 | Y: 1960 | Contact Count: 3 0.294783 Tip Switch: 1 | Contact Id: 1 | X: 908 | Y: 1062 | Contact Count: 0 0.296187 Tip Switch: 1 | Contact Id: 2 | X: 1566 | Y: 861 | Contact Count: 0 Slot 0 is released correclty, but when we look for Contact ID 2, the slot 0 is then picked up again because it is marked as inactive (trackingID < 0). This is wrong, and we should not reuse a slot in the same frame. The test should also check for input_mt_is_used(). In addition, we need to initialize mt->frame to an other value than 0. With mt->frame being 0, all slots are tags as currently used, and so input_mt_get_slot_by_key() would return -1 for all requests. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=88903Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
- 05 Apr, 2015 1 commit
-
-
Julia Lawall authored
Return a negative error code on failure. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier ret; expression e1,e2; @@ ( if (\(ret < 0\|ret != 0\)) { ... return ret; } | ret = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Reviewed-by:
-
- 02 Apr, 2015 8 commits
-
-
Ping Cheng authored
Cintiq 13HD Touch is a new display tablet with pen and 10 finger touches. Signed-off-by:
Ping Cheng <pingc@wacom.com> Signed-off-by:
-
Benjamin Tissoires authored
The Logitech T650 used to report 3 fingers swipes to the up as a press on the Super key. When we switched the touchpad to the raw mode, we also disable such firmware gesture and some users may rely on it. Unfortunately, 3 finger swipes are still not supported in most of the Linux environments, which means that we disabled a feature of the touchpad. Allow users to revert the raw reporting mode and keep going with the firmware gestures by providing a new module parameter. Signed-off-by:
-
Oliver Neukum authored
The device exists with two device IDs instead of one as previously believed. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Oliver Neukum authored
During a stress test these mice kept dropping and reappearing in runlevel 1 as opposed to 5. Signed-off-by:
-
Ping Cheng authored
In wacom_bpt_pen, we checked touch_down before assigning new stylus_in_proximity value. This would cause stylus_in_proximity not updated properly if touch is down before pen is in proximity. [jkosina@suse.cz: fix if-else style] Signed-off-by:
Jason Gerecke <jason.gerecke@wacom.com> Signed-off-by:
-
Ping Cheng authored
Counting number of touching fingers by wacom_wac_finger_count_touches so we don't have to count them inside individual routines. Signed-off-by:
-
Ping Cheng authored
The quirk was added for devices that support both pen and touch. It decides if a device supports multiple inputs by hardcoded feature type. However, for some devices, we do not know if they support both before accessing their HID descriptors. This patch relies on dynamically assigned device_type to make the decision. Also, we make it certain that wacom_wac->shared is always created. That is, the driver will not be loaded if it fails to create wacom_wac->shared. Signed-off-by:
-
Jiri Kosina authored
Conflicts: drivers/hid/wacom_wac.c Need to fetch the 4.0 fixes to apply 4.1 patches based on top of those. Signed-off-by:
-
- 27 Mar, 2015 1 commit
-
-
Jiri Kosina authored
Force-beedback core guarantees that the 'effect' pointer that's being passed to ->upload() callback is non-NULL. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 25 Mar, 2015 2 commits
-
-
Oliver Neukum authored
This mouse is also known under other IDs. It needs the quirk or will disconnect in runlevel 1 or 3. Signed-off-by:
-
Oliver Neukum authored
This mouse needs QUIRK_ALWAYS_POLL. Signed-off-by:
-
- 17 Mar, 2015 1 commit
-
-
Benjamin Tissoires authored
486b908d (HID: wacom: do not send pen events before touch is up/forced out) introduces a kernel oops when plugging a tablet without touch. wacom->shared is null for these devices so this leads to a null pointer exception. Change the condition to make it clear that what we need is wacom->shared not NULL. Signed-off-by:
-
- 16 Mar, 2015 5 commits
-
-
Benjamin Tissoires authored
If noone listens to the input device when a tool comes in proximity, the tablet does not send the in-prox event when a client becomes available. That means that no events will be sent until the tool is taken out of proximity. In this situation, ask for the report WACOM_REPORT_INTUOSREAD which will read the corresponding feature and generate an in-prox event. To make some generation of hardware working, we need to unset the quirk NO_GET set by hid-core because the interfaces are seen as "boot mouse". We don't schedule this read in a worker while we are in an IO interrupt. We know that usbhid will do it asynchronously. If this is triggered by uhid, then this is obviously a client side bug :) Signed-off-by:
Jason Gerecke <killertofu@gmail.com> Signed-off-by:
-
Stefan Richter authored
This driver didn't exist until before v3.19. Why would suddenly everybody want to build it? Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Jim Keir authored
The PID driver (usbhid/hid-pidff.c) does not set the effect ID when uploading an effect. The result is that the initial upload works but subsequent uploads to modify effect parameters are all directed at the last-created effect. The targeted effect ID must be passed back to the device when effect parameters are changed. This is done at the start of "pidff_set_condition_report", "pidff_set_periodic_report" etc. based on the value of "pidff->block_load[PID_EFFECT_ BLOCK_INDEX].value[0]". This value is only ever set during pidff_request_effect_upload. The result is stored in "pidff->pid_id[effect->id]" at the end of pid_upload_effect, for later use. However, if an effect is modified and re-sent then this identifier is not being copied back from pidff->pid_id[effect->id] before sending the command to the device. The fix is to do this at the start of pidff_upload_effect. Signed-off-by:
Jim Keir <jimkeir@oracledbadirect.com> Signed-off-by:
-
Jean Delvare authored
Many HID driver options are hidden unless EXPERT is set. While I understand the idea of simplifying the kernel configuration for most users, in practice I believe it adds more confusion than it helps. One thing that worries me is that, in non-EXPERT mode, these drivers will be either built-in or modular based on apparent magic. For example, switching INPUT and HID from m to y will cause all these drivers to be built into the kernel when they were previously built as modules. Short of enabling EXPERT mode altogether, the user has no control over that. Generally I do not think tristate options should depend on !EXPERT. Of these, 11 of 15 are currently in the hid subsystem. The HID_LOGITECH option is even worse than the others. Sub-options depend on it, and this causes menuconfig and friends to display the option even though the user can't change its value. The help page for HID_LOGITECH will not explain why the value can't be changed. It only says, for example: Depends on: INPUT [=y] && HID [=y] and that leaves the user puzzled about why the option is forced to y. You might argue that this is a Kconfig bug, but that doesn't make it less annoying for the user. Even worse is that some of the sub-options of HID_LOGITECH select INPUT_FF_MEMLESS, which in turn gets out of control for the user. So, if you set INPUT=y and HID=y (something most general purpose distributions would do these days, as both modules would get loaded on a vast majority of systems otherwise), and you want support for force-feedback game controllers, you can't have that as a module, it has to be built-in, regardless of how rare these devices are. Of course, all this madness goes away once EXPERT is enabled, but then the rest of the kernel configuration becomes more complex, which totally voids the original point. For this reason, I would like all HID device tristate options to be displayed regardless of EXPERT being set or not. We can let the default settings still depend on EXPERT, that's not intrusive. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
-
Benjamin Tissoires authored
No need to retrieve the USB handle in input_mapping() when we already do that in probe. It also allows to use the quirk without having to add the product ID matching. Signed-off-by:
-
- 15 Mar, 2015 2 commits
-
-
Pavel Machek authored
Makefile that can actually build the example, and allow selecting device to work on. Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Forest Wilkinson authored
The linux kernel has supported the TiVo Slide remote control for some time, but does not recognize the USB ID of the newer Slide Pro. This patch adds the missing data structures so the newer remote will be recognized by the driver, thereby allowing the TiVo, LiveTV, and Thumbs Up/Down buttons to be mapped with a hwdb file. Signed-off-by:
Forest Wilkinson <web11.forest@tibit.com> Signed-off-by:
-
- 12 Mar, 2015 1 commit
-
-
Seth Forshee authored
According to [1], Windows Precision Touchpad devices must supply a button type usage in the device capabilities feature report. A value of 0 indicates that the device contains a depressible button (i.e. it's a click-pad) whereas a value of 1 indicates a non-depressible button. Add support for this usage and set INPUT_PROP_BUTTONPAD on the touchpad input device whenever a depressible button is present. [1] https://msdn.microsoft.com/en-us/library/windows/hardware/dn467314(v=vs.85).aspxSigned-off-by:
Seth Forshee <seth.forshee@canonical.com> Reviewed-by:
-
- 11 Mar, 2015 9 commits
-
-
Jason Gerecke authored
Declare the POWER_SUPPLY_PROP_PRESENT property to provide userspace with a way to determine if the battery on a wireless tablet is plugged in. Although current wireless tablets do not explicitly report this information, it can be inferred from other state information. In particular, a battery is assumed to be present if any of the following are true: a non-zero battery level reported, the battery is reported as charging, or the tablet is operating wirelessly. Note: The last condition above may not strictly hold for the Graphire Wireless (it charges from a DC barrel jack instead of a USB port), but I do not know what is reported in the no-battery condition. Signed-off-by:
-
oliver@neukum.org authored
This device disconnects every 60s without X Signed-off-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Jiri Kosina authored
The constant is not used (leftover from previous patch versions that never got merged). Reported-by:
-
Jason Gerecke authored
The status packet for tablets which can use a wireless module contains a bit that is set if the battery is charging. This bit will be 0 if either a battery is not present or if the battery has reached full charge. Note that the charging circuit may continue to charge the battery for a short time after reaching "100%". Signed-off-by:
-
Jason Gerecke authored
Calls the wacom_status_irq function to report battery status for the Intuos Pro and Intuos5 (in addition to the already-reporting Intuos and last-generation Bamboo). Signed-off-by:
-
Jason Gerecke authored
If a wireless adapter (which contains the charging circuitry) is detected as being attached to the tablet then create a new battery interface and update its status as data is reported. Also destroy the battery if the adapter goes away. Signed-off-by:
-
Jason Gerecke authored
Tablets like the Intuos, Intuos Pro, and Bamboo have a connector for an optional wireless module that can be connected on the fly. The presence (or absence) of this module is indicated in a status report recieved from the tablet. This patch adds a workqueue function that will create or destroy a power_supply object at runtime to match the current state of the WACOM_QUIRK_BATTERY flag. Signed-off-by:
-
Jason Gerecke authored
Has the 'wacom_notify_battery' function take on the job of detecting if updating the power supply is necessary to remove multiple nearly-identical 'if' blocks. Signed-off-by:
-
Jason Gerecke authored
In addition to the touchswitch state for "Intuos", these packets are also sent by the Intuos Pro, Intuos5, and last-generation Bamboo tablets when using a wired connection. They contain, among other things, information about the optional wireless module and battery charge state (to be supported in subsuquent patches). Signed-off-by:
-
- 06 Mar, 2015 1 commit
-
-
Benjamin Tissoires authored
Touchpads that have only one button are called clickpads and should be advertised as such by the kernel. Signed-off-by:
Jason Ekstrand <jason@jlekstrand.net> Signed-off-by:
-
- 04 Mar, 2015 2 commits
-
-
Dmitry Torokhov authored
Currently HID code maps usages from telephony page into BTN_0, BTN_1, etc keys which get interpreted by mousedev and userspace as left/right/middle button clicks, which is not really helpful. This change adds mappings for usages that have corresponding input event definitions, and leaves the rest unmapped. This can be changed when there are userspace consumers for more telephony usages. Signed-off-by:
-
Benjamin Tissoires authored
In commit 08177f40 (HID: uclogic: merge hid-huion driver in hid-uclogic) HID_HUION depends explicitely on USB_HID because it contained quite some USB-isms. Now that hid-uclogic is the new home of Huion tablets, we need to also add the dependency on USB_HID to this driver. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
- 03 Mar, 2015 4 commits
-
-
Benjamin Tissoires authored
This hack is only needed for Huion tablets. It does not seem to have any effect on the other tablets handled by this device right now, but it's better to check for the product id sooner than discovering that we have messed up one tablet later. Signed-off-by:
Nikolai Kondrashov <spbnick@gmail.com> Signed-off-by:
-
Benjamin Tissoires authored
Some Huion tablets present 2 HID Pen interfaces. Only one is used, so we can drop the unused one. Reviewed-by:
-
Benjamin Tissoires authored
NO_EMPTY_INPUT is useful when MULTI_INPUT is set. It prevents to create empty input nodes that user space does not know what to do with. It does not seem to be required at the moment, this is just a preventive patch. This check is only made during the plug of the device, so it does not hurt to have it. Reviewed-by:
-
Benjamin Tissoires authored
We append "Pen", "Pad", "Mouse", "Keyboard", "Consumer Control" or "System Control" suffix to the appropriate input node to match what the Wacom driver does and be more convenient for the user to know which one is which. Reviewed-by:
-
