An error occurred fetching the project authors.
- 27 Feb, 2015 2 commits
-
-
Benjamin Tissoires authored
The stylus of this device works just fine out of the box. The touch is seen by default as a mouse with relative events and some gestures. The wireless and the wired version have slightly different firmwares, but the debug mode 2 on the feature 2 is common to the 2 devices. In this mode, all the reports are emitted through the debug interface (pen, raw touch and mouse emulation), so we have to re-route manually the events. We keep the Pen interface as a HID_GENERIC one because it works, and only parse the raw touches while discarding the mouse emulation & gestures. Switching the default in raw mode allows us to have a consistent user experience accross all the multitouch touchpads (and enable the touch part of the devices). Note that the buttons of this devices are reported through the touch interface. There is no 'Pad' interface. It seemed more natural to have the BTN_LEFT and BTN_RIGHT reported with the touch because they are placed under the touch interface and it looks like they belong to the touch part. Tested-by:
Josep Sanchez Ferreres <josep.sanchez.ferreres@est.fib.upc.edu> Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by:
Ping Cheng <pingc@wacom.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz>
-
Benjamin Tissoires authored
The Bamboo PAD in debug mode needs to re-route events from the debug interface to the Pen interface. This can be easily done with hid_input_report(), but that means that we need to keep a reference to the various hid_devices. There should be only one touch and one pen interface per physical tablet, so there is no need to keep a list of hid-devices, plain pointers are sufficient. Tested-by:
-
- 29 Jan, 2015 1 commit
-
-
Ping Cheng authored
These devices have accelerometers. To report accelerometer coordinates, a new property, INPUT_PROP_ACCELEROMETER, is added. Signed-off-by:
-
- 06 Jan, 2015 1 commit
-
-
Benjamin Tissoires authored
We introduced nice macros in wacom_wac.c to check whether a field is a pen or a touch one. wacom_usage_mapping() still uses it's own tests, which are not in sync with the wacom_wac tests (.application is not checked). That means that some legitimate fields might be filtered out from the usage mapping, and thus will not be used properly while receiving the events. Signed-off-by:
-
- 10 Dec, 2014 1 commit
-
-
Jason Gerecke authored
If a HID descriptor places HID_DG_CONTACTID before HID_DG_X and HID_DG_Y then the ABS_X and ABS_Y will not be automatically initialized by the call to input_mt_init_slots. To ensure that this is not a problem, we relocate that call to occur after HID parsing has been completed and we've initalized all the multitouch axes. Signed-off-by:
Jason Gerecke <killertofu@gmail.com> Reviewed-by:
-
- 02 Dec, 2014 1 commit
-
-
Benjamin Tissoires authored
Since the conversion from USB to HID (in v3.17), some people reported a freeze on boot with the wacom driver. Hans managed to get a stacktrace: [ 240.272331] Call Trace: [ 240.272338] [<ffffffff813de7b9>] ? usb_hcd_submit_urb+0xa9/0xb10 [ 240.272347] [<ffffffff81555579>] schedule+0x29/0x70 [ 240.272355] [<ffffffff815559e6>] schedule_preempt_disabled+0x16/0x20 [ 240.272363] [<ffffffff81557365>] __mutex_lock_slowpath+0xe5/0x230 [ 240.272372] [<ffffffff815574c7>] mutex_lock+0x17/0x30 [ 240.272380] [<ffffffffa063c1d2>] wacom_resume+0x22/0x50 [wacom] [ 240.272396] [<ffffffffa01aea8a>] hid_resume_common+0xba/0x110 [usbhid] [ 240.272404] [<ffffffff813e5890>] ? usb_runtime_suspend+0x80/0x80 [ 240.272417] [<ffffffffa01aeb1d>] hid_resume+0x3d/0x70 [usbhid] [ 240.272425] [<ffffffff813e44a6>] usb_resume_interface.isra.6+0xb6/0x120 [ 240.272432] [<ffffffff813e4774>] usb_resume_both+0x74/0x140 [ 240.272439] [<ffffffff813e58aa>] usb_runtime_resume+0x1a/0x20 [ 240.272446] [<ffffffff813b1912>] __rpm_callback+0x32/0x70 [ 240.272453] [<ffffffff813b1976>] rpm_callback+0x26/0xa0 [ 240.272460] [<ffffffff813b2d71>] rpm_resume+0x4b1/0x690 [ 240.272468] [<ffffffff812ab992>] ? radix_tree_lookup_slot+0x22/0x50 [ 240.272475] [<ffffffff813b2c1a>] rpm_resume+0x35a/0x690 [ 240.272482] [<ffffffff8116e9c9>] ? zone_statistics+0x89/0xa0 [ 240.272489] [<ffffffff813b2f90>] __pm_runtime_resume+0x40/0x60 [ 240.272497] [<ffffffff813e4272>] usb_autopm_get_interface+0x22/0x60 [ 240.272509] [<ffffffffa01ae8d9>] usbhid_open+0x59/0xe0 [usbhid] [ 240.272517] [<ffffffffa063ac85>] wacom_open+0x35/0x50 [wacom] [ 240.272525] [<ffffffff813f37b9>] input_open_device+0x79/0xa0 [ 240.272534] [<ffffffffa048d1c1>] evdev_open+0x1b1/0x200 [evdev] [ 240.272543] [<ffffffff811c899e>] chrdev_open+0xae/0x1f0 [ 240.272549] [<ffffffff811c88f0>] ? cdev_put+0x30/0x30 [ 240.272556] [<ffffffff811c17e2>] do_dentry_open+0x1d2/0x320 [ 240.272562] [<ffffffff811c1cd1>] finish_open+0x31/0x50 [ 240.272571] [<ffffffff811d2202>] do_last.isra.36+0x652/0xe50 [ 240.272579] [<ffffffff811d2ac7>] path_openat+0xc7/0x6f0 [ 240.272586] [<ffffffff811cf012>] ? final_putname+0x22/0x50 [ 240.272594] [<ffffffff811d42d2>] ? user_path_at_empty+0x72/0xd0 [ 240.272602] [<ffffffff811d43fd>] do_filp_open+0x4d/0xc0 [...] So here, wacom_open is called, and then wacom_resume is called by the PM system. However, wacom_open already took the lock when wacom_resume tries to get it. Freeze. A little bit of history shows that this already happened in the past - commit f6cd3783 ("Input: wacom - fix runtime PM related deadlock"), and the solution was to call first the PM function before taking the lock. The lock was introduced in commit commit e7224094 ("Input: wacom - implement suspend and autosuspend") when the autosuspend feature has been added. Given that usbhid already takes care of this very same locking between suspend/resume, I think we can simply kill the lock in open/close. The lock is now used also with LEDs, so we can not remove it completely. Reported-by:
Hans Spath <inbox-546@hans-spath.de> Tested-by:
-
- 01 Dec, 2014 1 commit
-
-
Mathieu Magnaudet authored
In several hid drivers it is necessary to calculate the length of an hid_report. This patch exports the existing static function hid_report_len of hid-core.c as an inline function in hid.h Signed-off-by:
Mathieu Magnaudet <mathieu.magnaudet@enac.fr> Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@gmail.com> Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
- 26 Nov, 2014 1 commit
-
-
Ping Cheng authored
PAD can be on pen interface (Intuos Pro and Cintiq series) or touch interface (Bamboo PT and Intuos PT series) or its own interface (Bamboo pen-only and Intuos Pen M/S). We need to mark it independently. Signed-off-by:
-
- 20 Nov, 2014 1 commit
-
-
Ping Cheng authored
Bamboo models do not support HID_DG_CONTACTMAX. Plus, Bamboo pen-only has touch descriptor. This leads to some complications in the code. This patch also fixes duplicated PAD interfeaces for Intuos Pen models. Signed-off-by:
-
- 01 Oct, 2014 5 commits
-
-
Benjamin Tissoires authored
Signed-off-by:
-
Benjamin Tissoires authored
ISDv4 and v5 are plain HID devices. We can directly implement a generic HID parsing/handling and remove the need to manually add those PID in the list of supported devices. This patch implements the pen support only. The finger part will come in a later patch. To be properly notified of an .event() and a .report(), we need to force hid-core to go through the HID parsing. By default, wacom.ko binds only hidraw, so the hid parsing is not done by hid-core. When a true HID device is there, we add the flag HID_CLAIMED_DRIVER to hid->claimed which will force hid-core to parse the incoming reports. (Note that this can be easily backported by directly setting the .claimed flag to HID_CLAIMED_DRIVER even if hid-core does not support HID_CONNECT_DRIVER) Signed-off-by:
-
Benjamin Tissoires authored
This allows to have the input devices ready in while parsing the reports descriptor. Signed-off-by:
-
Benjamin Tissoires authored
If the input can be created earlier during probe, we can already populate them while reading the report descriptor. This way, we can rely on the hid subsystem directly for tablets which already provide a meaningful report descriptor (like ISDv4-5). This patch only splits the allocation and registration, but do not change where we allocate the input. This will come in a later patch. Signed-off-by:
-
Benjamin Tissoires authored
When we have to deal with new elements in probe, having the exit labels named sequencially is a pain to maintain. Put a meaningful name instead so that we do not have to renumber them on inserts. Signed-off-by:
-
- 22 Sep, 2014 1 commit
-
-
Benjamin Tissoires authored
Some Wacom tablets (at least the ISDv4 found in the Lenovo X230) timeout during probe while retrieving the input reports. The only time this information is valuable is during the feature_mapping stage, so we can ask for it there and discard the generic input reports retrieval. This gives a code path closer to the wacom.ko driver when it was in the input subtree (not HID). Cc: stable@vger.kernel.org # requires cherry-pick of c64d8834Signed-off-by:
-
- 12 Sep, 2014 1 commit
-
-
Benjamin Tissoires authored
Currently, tablets connected to the WL receiver all share the same VID/PID. There is no way for the user space to know which one is which besides parsing the name. We can force the PID to be set to the actual hardware. This way, the input device will have the correct PID which can be match in libwacom. With only this trick, the pad input does not inherit the ID_INPUT_TABLET udev property from its parent. We can force udev to accept it by declaring a BTN_STYLUS which is never used. This way, tablets connected through WL can be used from the user point of view in the same way they are used while connected through wire. Signed-off-by:
-
- 11 Sep, 2014 4 commits
-
-
Ping Cheng authored
And associate all LED/OLED to PAD device Signed-off-by:
-
Ping Cheng authored
It is assigned in buf[0] anyway. Signed-off-by:
-
Ping Cheng authored
changed to scnprintf(buf, PAGE_SIZE, ... ) as suggested in sysfs.txt for show functions Signed-off-by:
Paul A. Tessier <phernost@gmail.com> Signed-Off-by:
-
Ping Cheng authored
RW : ug=rw,o=r WO : ug=w And enabled reading relavent sysfs attributes. Signed-off-by:
-
- 12 Aug, 2014 1 commit
-
-
Geert Uytterhoeven authored
If CONFIG_PM is not set: drivers/hid/wacom_sys.c:1436: warning: ‘wacom_reset_resume’ defined but not used Protect the unused functions by #ifdef CONFIG_PM to fix this. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 06 Aug, 2014 6 commits
-
-
Benjamin Tissoires authored
Putting the various MODULE_* makes them appear several times in modinfo because wacom.h is used both in wacom_sys.c and wacom_wac.h. Having the macros near the module declaration makes them appear only once. Add also MODULE_VERSION(DRIVER_VERSION) to export the current version number. Signed-off-by:
-
Przemo Firszt authored
Every call of wacom_set_report was passing "id" as a separate parameter and buffer also passed the same information. We can use first u8 of the buffer instead of "id" Signed-off-by:
Przemo Firszt <przemo@firszt.eu> Signed-off-by:
-
Benjamin Tissoires authored
Bluetooth Intuos 4 use 1-bit definition while the USB ones use a 4-bits definition. This changes the size of the raw image we receive, and thus the kernel will only accept 1-bit images for Bluetooth and 4-bits for USB. Signed-off-by:
-
Benjamin Tissoires authored
A good point of this change is that now, the Intuos4 bluetooth can handle the different tools (artpen, airbrush, mice), and we get a common interface between USB and BT for accessing the LEDs/OLEDs. Signed-off-by:
-
Benjamin Tissoires authored
First, merge the Graphire BT tablet. Signed-off-by:
-
Benjamin Tissoires authored
Now that wacom is a hid driver, there is no point in having a separate driver for bluetooth devices. This patch prepares the common paths of Bluetooth devices in the common wacom driver. It also adds the sysfs file "speed" used by Bluetooth devices. Signed-off-by:
-
- 26 Jul, 2014 13 commits
-
-
Benjamin Tissoires authored
This is used by HID Bluetooth devices but also add some more information to the USB Wireless Receiver. We are just porting the bits from hid-wacom.c to the common driver here. Signed-off-by:
-
Benjamin Tissoires authored
The current implementation uses "wacom_battery" as a generic name for batteries. This prevents us to have two Wacom devices with a battery attached as the power system will complain about the name which is already registered. Use an incremental name for each battery attached. Related bug: https://sourceforge.net/p/linuxwacom/bugs/248/Signed-off-by:
-
Benjamin Tissoires authored
- Reports the current status of the battery (discharging, charging, full). - Also notify the upower daemon when there is a change in the battery value. - keep the battery value as a percentage, not the raw value - add WACOM_QUIRK_BATTERY to easily add a battery to a device (required for Bluetooth devices) Signed-off-by:
-
Benjamin Tissoires authored
This solves a bug with the wireless receiver: - at plug, the wireless receiver does not know which Wacom device it is connected to, so it does not actually creates all the LEDs - when the tablet connects, wacom->wacom_wac.features.type is set to the proper device so that wacom_wac can understand the packets - when the receiver is unplugged, it detects that a LED should have been created (based on wacom->wacom_wac.features.type) and tries to remove it: crash when removing the sysfs group. Side effect, we can now safely call several times wacom_destroy_leds(). Signed-off-by:
-
Benjamin Tissoires authored
wacom.ko is now a full HID driver, we have to move it into the proper subdirectory: drivers/hid. Signed-off-by:
-
Benjamin Tissoires authored
This may infer a small difference with the previous implementation due to the DIV_ROUND_CLOSEST() in the hid implementation. Signed-off-by:
-
Benjamin Tissoires authored
HID already parses the report descriptor, so use it instead of implementing our own. The special case for Bamboo PT 3rd gen is also removed and handled in the same way Intuos 5 is treated, by hardcoding it in the driver. Last, the unit_exponent stored into the hid field already is signed, so there is no need to handle a two's complement anymore. Signed-off-by:
-
Benjamin Tissoires authored
Removes one more need of usb and intf. Signed-off-by:
-
Benjamin Tissoires authored
Use the HID device as the parent for the power device when dealing with a wireless receiver. Removes one more usb dependency and does not break user space. Signed-off-by:
-
Benjamin Tissoires authored
Wacom tablets can share different physical sensors on one physical device. These are called siblings in the code. The current way of implementation relies on the USB topology to be able to share data amongs those sensors. We can replace the code to match a HID subsystem, without involving the USB topology: - the first probed sensor does not find any siblings in the list wacom_udev_list, so it creates its own wacom_hdev_data with its own struct hid_device - the other sensor checks the current list of siblings in wacom_hdev_data, and if there is a match, it associates itself to the matched device. To be sure that we are not associating different sensors from different physical devices, we also check for the phys path of the hid device which contains the USB topology. Signed-off-by:
-
Benjamin Tissoires authored
Matches the current behavior of the HID subsystem and removes one more dependency over USB. The current user space clients which relies on this to fetch the LEDs path need an update. However, we already break them in the kernel v3.11 for the Bluetooth Wacom devices. They are going to be fixed soon. Signed-off-by:
-
Benjamin Tissoires authored
Removes one more dependency over USB, but requires some changes in the user space to find the sysfs files correctly. This patch breaks the user space. However, the number of program accessing the LEDs is quite limited and we can easily patch them to handle the new HID behavior. Signed-off-by:
-
Benjamin Tissoires authored
This removes an USB dependency and is more accurate: the computed pktlen is the actual maximum size of the reports forwarded by the device. Given that the pktlen is correctly computed/validated, we can store it now in the features struct instead of having a special handling in the rest of the code. Likewise, this information is not mandatory anymore in the description of devices in wacom_wac.c. They will be removed in a separate patch. Signed-off-by:
-
