An error occurred fetching the project authors.
- 19 Oct, 2017 1 commit
-
-
Jason Gerecke authored
The WACOM_PEN_FIELD macro is used to determine if a given HID field should be associated with pen input. This field includes several known collection types that Wacom pen data is contained in, but the WACOM_HID_WD_PEN application collection type is notably missing. This can result in fields within this kind of collection being completely ignored by the `wacom_usage_mapping` function, preventing the later '*_event' functions from being notified about changes to their value. Fixes: c9c09587 ("HID: wacom: generic: Support and use 'Custom HID' mode and usages") Fixes: ac2423c9 ("HID: wacom: generic: add vendor defined touch") Cc: stable@vger.kernel.org Reviewed-by:
Ping Cheng <ping.cheng@wacom.com> Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jason Gerecke <jason.gerecke@wacom.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz>
-
- 05 May, 2017 2 commits
-
-
Jason Gerecke authored
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 authored
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:
-
- 06 Apr, 2017 1 commit
-
-
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:
-
- 06 Mar, 2017 3 commits
-
-
Ping Cheng authored
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:
Aaron Armstrong Skomra <aaron.skomra@wacom.com> Signed-off-by:
-
Benjamin Tissoires authored
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:
-
Ping Cheng authored
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:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
- 26 Jan, 2017 6 commits
-
-
Aaron Armstrong Skomra authored
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:
Ping Cheng <pingc@wacom.com> Signed-off-by:
-
Aaron Armstrong Skomra authored
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 Armstrong Skomra authored
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 Armstrong Skomra authored
Input_event_flag duplicates the information we track in wacom_wac->hid_data.inrange_state for the pad. Signed-off-by:
-
Jason Gerecke authored
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 authored
Centralize our definition of report IDs by moving those for device commands into wacom_wac.h alongside those for input reports. Signed-off-by:
-
- 09 Dec, 2016 1 commit
-
-
Ping Cheng authored
post input_sync only when there are input events posted Signed-off-by:
-
- 20 Oct, 2016 12 commits
-
-
Jason Gerecke authored
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 authored
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 authored
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 authored
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 authored
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 ac414da3, fa770340, and ecd618dc, 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 ecd618dc were already adjusted in ac414da3), 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 ac414da3 (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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
- 11 Aug, 2016 1 commit
-
-
Jason Gerecke authored
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:
-
- 10 Aug, 2016 1 commit
-
-
Jason Gerecke authored
"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:
-
- 05 Aug, 2016 5 commits
-
-
Benjamin Tissoires authored
Instead of displaying a generic "tablet", now g-c-c shows a pretty "Wacom Intuos Pro S (WL)". Signed-off-by:
-
Benjamin Tissoires authored
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 authored
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 authored
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 authored
We currently have a complex clean_inputs() function while this can be handled all by devres. Set a group that we can destroy in wireless_work(). Signed-off-by:
-
- 03 May, 2016 1 commit
-
-
Jason Gerecke authored
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:
-
- 05 Apr, 2016 1 commit
-
-
Jason Gerecke authored
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/15Co-authored-by:
-
- 08 Jan, 2016 1 commit
-
-
Jason Gerecke authored
Unlike other tablets which are compatible with the wacom_intuos_irq handler, INTUOSHT2 devices provide pen ID with report ID 8 instead of 5. To ensure wacom_intuos_schedule_prox_event works as intended for these tablets, we must be sure it uses the correct report ID in this case. Signed-off-by:
-
- 02 Dec, 2015 1 commit
-
-
Jason Gerecke authored
"INTUOSREAD" and "INTUOSWRITE" are poorly named. These are report IDs for pen ID (proximity) packets. It should be noted that the latter is only used on Intuos/Intuos2 for a second stylus when DualTrack is in use. Signed-off-by:
-
- 02 Nov, 2015 1 commit
-
-
Ping Cheng authored
Intuos Pen in wireless mode does not have the same report id (2) as when it is in USB mode (17). This patch also moves WIRELESS next to REMOTE in type enum so we can group devices with similar features easily. Reported-by:
Dale Brewe <dlbrewe@hotmail.com> Tested-by:
-
- 21 Oct, 2015 2 commits
-
-
Jason Gerecke authored
The cached indicies 'cc_index' and 'cc_value_index' introduced in 1b5d514 are only valid for a single report ID. If a touchscreen has multiple reports with a HID_DG_CONTACTCOUNT usage, its possible that the values will not be correct for the report we're handling, resulting in an incorrect value for 'num_expected'. This has been observed with the Cintiq Companion 2. To address this, we store the ID of the report those indicies are valid for in a new 'cc_report' variable. Before using them to get the expected contact count, we first check if the ID of the report we're processing matches 'cc_report'. If it doesn't, we update the indicies to point to the HID_DG_CONTACTCOUNT usage of the current report (if it has one). Cc: stable@vger.kernel.org Signed-off-by:
-
Jason Gerecke authored
Adds support for the EMR (pen+pad) and touchscreen devices used by the Wacom Cintiq Companion 2. This applies both to using the device as a standalone system, as well as when operating in "Cintiq mode" (where the EMR/touchscreen are simply exposed as USB devices to the system its connected to). Signed-off-by:
Clifford Jolly <expiredpopsicle@gmail.com> Signed-off-by:
-
