This device is pad (buttons) only, there is no stylus or touch. Up to
five remotes can pair with the device's associated USB dongle.
Signed-off-by: Aaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Prior to this commit, numbered button bit setting was done separately
for each device type in wacom_setup_pad_capabilities(). Here we add a
numbered_buttons property to the wacom_features struct and extract the
repeated bit setting code to a new function:
wacom_settup_numbered_buttons().
Signed-off-by: Aaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The current generation of "Intuos" tablets (i.e. INTUOSHT) report touch
width and height data just like the "Intuos Pro" do. This commit changes
the code to allow these tablets to use the appropriate codepath instead
of the one intended for Intuos5/Bamboo.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Unlike other IRQ functions, 'wacom_pl_irq' uses the second element of
the 'tool' array to store information about its single pen. This makes
the function more difficult to understand (since it doesn't follow the
general pattern of other IRQ functions) and prevents the possibility of
refactoring how pen state is stored.
This patch rewrites 'wacom_pl_irq' to follow the usual IRQ conventions,
including storing tool type in 'tool[0]' and implicitly tracking prox
with the 'id[0]' variable.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
WACOM_QUIRK_NO_INPUT is a signal to the driver that input devices
should not be created for a particular device. This quirk was used by
the wireless receiver to prevent any devices from being created during
the initial probe (defering it instead until we got a tablet connection
event in 'wacom_wireless_work').
This quirk is not necessary now that a device_type is associated with each
device. Any input device allocated by 'wacom_allocate_inputs' which is
not necessary for a particular device is freed in 'wacom_register_inputs'.
In particular, none of the wireless receivers devices have the pen, pad,
or touch device types set so the same effect is achieved without the need
to be explicit.
We now return early in wacom_retrieve_hid_descriptor for wireless devices
(to prevent the device_type from being overridden) but since we ignore the
HID descriptor for the wireless reciever anyway, this is not an issue.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The monitor interface on the wireless receiver is more logically expressed
as a type of device instead of a quirk.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The HID_DG_WIDTH and HID_DG_HEIGHT usages report with width and height of
contacts. From this information, a crude determination of orientation is
also possible. This patch reports all three to userspace if a device
reports this usage.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The reports sent from some touch devices (e.g. the Cintiq 24HDT) contain
junk data in the contact slots which follow the final "valid" contact.
To avoid forwarding it to usrspace, we store the reported contact count
during the pre-process phase and then only process that many contacts.
If a device sends its contacts across multiple reports (what Microsoft
refers to as "hybrid" mode) then the contact count will be zero for
reports other than the first.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
In some cases, we need access to information before it becomes available
to the 'event' handler. In particular, for some devices we cannot properly
process the finger data without first knowing the "contact count" at the
very end of the report (e.g. the Cintiq 24HDT touch screen, when forced
through the GENERIC codepath).
Since the HID subsystem doesn't provide a way to take action before 'event'
is called, we take a cue from hid-multitouch.c and add a pre-process step
within the 'report' handler that performs the same function.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
As mentioned in the comment in the code, both the pen and touch data
come from the interface tagged as BAMBOO_PAD. The driver re-routes the
events for the Pen to the generic HID interface and keeps the ones for
the touch through this current interface.
Clearing the WACOM_DEVICETYPE_PEN bit removes the extra unused interface
added in 2a6cdbd ("HID: wacom: Introduce new 'touch_input' device") and
makes the Bamboo PAD to behave like in 4.1.
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Commit 862cf55 ("HID: wacom: Introduce a new WACOM_DEVICETYPE_PAD device_type")
neglected to set the WACOM_DEVICETYPE_PAD flag for older two-finger Bamboo
Touch tablets. Not only does this result in the pad device not appearing when
such a tablet is plugged in, but also causes a segfault when 'wacom_bpt_touch'
tries to send pad events. This patch adds the flag to resolve these issues.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Instead of having a single 'input_dev' device that will take either pen
or touch data depending on the type of the device, create seperate devices
devices for each. By splitting things like this, we can support devices
(e.g. the I2C "AES" sensors in some newer tablet PCs) that send both pen
and touch reports from a single endpoint.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This splits the 'wacom_setup_pentouch_input_capabilites' function into
pieces dedicated to doing setup for just the pen interface and just
the touch interface. This makes it easier to focus on the relevant
piece when making changes.
This patch introduces no functional changes.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Historically, both the touch and pad tools would have shared the
'BTN_TOOL_FINGER' type. Any time you needed to distinguish the two, you
had to use some other bit of knowledge (e.g. that the pad was on the same
interface as the pen, and thus 'touch_max' would be zero).
To make these checks more readable, we introduce WACOM_DEVICETYPE_PAD.
Although we still have to rely on other bits of knowledge to set this
bit on the right interface (since it cannot be detected from the HID
descriptor), it can be done just once inside 'wacom_setup_device_quirks'.
This patch introduces no functional changes.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The USB devices that this driver has historically supported segregate the
pen and touch portions of the tablet. Oftentimes the segregation would be
done at the interface level, though on occasion (e.g. Cintiq 24HDT) the
tablet would combine two totally independent USB devices behind an internal
USB hub. Because pen and touch never shared the same interface, it made
sense for the 'device_type' to store a single value: "pen" or "touch".
Recently, however, some I2C devices have been created which combine the
two. A first step to accomodating this is to expand 'device_type' so that
it can represent two (or potentially more) types simultaneously. To do
this, we treat it as a bitfield and set/check individual bits rather
than using the '=' and '==' operators.
This should not result in any functional change since no supported devices
(that I'm aware of, at least) have HID descriptors that indicate both
pen and touch reports on a single interface.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We assumed all touch interfaces report touch data. But, Bamboo
and Intuos non-touch devices report express keys on touch
interface. We need to check touch_max before counting touches.
Reported-by: Tasos Sahanidis <tasos@tasossah.com>
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Currently, we assume a device_type of BTN_TOOL_PEN before scanning the
HID descriptor and then change the device_type if what we discover
proves that assumption wrong. This way of doing things makes it more
difficult to figure out if a device (particularly a HID_GENERIC device)
actually does tablet/touch input or is something completley different.
This patch leaves device_type at its initial value of 0 and then calls
'wacom_parse_hid' for every device (not just those that have touch).
As we map the usages, we can set the device_type as before. After we're
finished, we can then check if the value is still zero and do whatever
is most appropriate.
Detecting the pen can be a little tricky on most Wacom devices because
the descriptors describe opaque blobs. Fortunately, older Wacom tablets
have the HID_DG_DIGITIZER usage on the pen's application collection and
newer tablets seem to have a similar vendor-defined usage that we can
trigger on.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
To determine if a touch is present in the single-touch case, we can
simply check if the BTN_TOUCH key is active or not. This will work for
both HID_GENERIC and other device types.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
It makes probe routine easy to follow.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull HID updates from Jiri Kosina:
- quite a few firmware fixes for RMI driver by Andrew Duggan
- huion and uclogic drivers have been substantially overlaping in
functionality laterly. This redundancy is fixed by hid-huion driver
being merged into hid-uclogic; work done by Benjamin Tissoires and
Nikolai Kondrashov
- i2c-hid now supports ACPI GPIO interrupts; patch from Mika Westerberg
- Some of the quirks, that got separated into individual drivers, have
historically had EXPERT dependency. As HID subsystem matured (as
well as the individual drivers), this made less and less sense. This
dependency is now being removed by patch from Jean Delvare
- Logitech lg4ff driver received a couple of improvements for mode
switching, by Michal Malý
- multitouch driver now supports clickpads, patches by Benjamin
Tissoires and Seth Forshee
- hid-sensor framework received a substantial update; namely support
for Custom and Generic pages is being added; work done by Srinivas
Pandruvada
- wacom driver received substantial update; it now supports
i2c-conntected devices (Mika Westerberg), Bamboo PADs are now
properly supported (Benjamin Tissoires), much improved battery
reporting (Jason Gerecke) and pen proximity cleanups (Ping Cheng)
- small assorted fixes and device ID additions
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (68 commits)
HID: sensor: Update document for custom sensor
HID: sensor: Custom and Generic sensor support
HID: debug: fix error handling in hid_debug_events_read()
Input - mt: Fix input_mt_get_slot_by_key
HID: logitech-hidpp: fix error return code
HID: wacom: Add support for Cintiq 13HD Touch
HID: logitech-hidpp: add a module parameter to keep firmware gestures
HID: usbhid: yet another mouse with ALWAYS_POLL
HID: usbhid: more mice with ALWAYS_POLL
HID: wacom: set stylus_in_proximity before checking touch_down
HID: wacom: use wacom_wac_finger_count_touches to set touch_down
HID: wacom: remove hardcoded WACOM_QUIRK_MULTI_INPUT
HID: pidff: effect can't be NULL
HID: add quirk for PIXART OEM mouse used by HP
HID: add HP OEM mouse to quirk ALWAYS_POLL
HID: wacom: ask for a in-prox report when it was missed
HID: hid-sensor-hub: Fix sparse warning
HID: hid-sensor-hub: fix attribute read for logical usage id
HID: plantronics: fix Kconfig default
HID: pidff: support more than one concurrent effect
...
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: Jiri Kosina <jkosina@suse.cz>
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: Ping Cheng <pingc@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <pingc@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: Ping Cheng <pingc@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: Jiri Kosina <jkosina@suse.cz>
486b908 (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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Jason Gerecke <killertofu@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: Jason Gerecke <killertofu@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <killertofu@gmail.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <killertofu@gmail.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <killertofu@gmail.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <killertofu@gmail.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: Jason Gerecke <killertofu@gmail.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
touch_down is a flag to indicate if there are touches on tablet
or not. Since one set of touch events may be posted over more
than one data packet/touch frame, and pen may come in proximity
while touch events are partially sent, counting all touch events
for the set reflects the actual status of touch_down.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
If pen comes in proximity while touch is down, we force touch up
before sending pen events. Otherwise, there can be unfinished
touch events compete with pen events. This idea has been fully
implemented for Tablet PCs. But other tablets that support both
pen and touch are not fully considered.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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>
Lenovo Thinkpad 10 has wacom digitizer connected as a I2C-HID device. Add
generic support for this.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
input_mt_sync_frame() calls input_mt_report_pointer_emulation() and do
some internal steps required to keep in sync the state of the touch within
the various reports.
Given that we use input_mt_get_slot_by_key() in this driver, it is better to
use input_mt_sync_frame().
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
27QHD has the same x_min/y_min (WACOM_CINTIQ_OFFSET) as other Cintiqs.
ABS_MISC event is required for PAD packet to work properly with
xf86-input-wacom.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
These devices have accelerometers. To report accelerometer coordinates, a new
property, INPUT_PROP_ACCELEROMETER, is added.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
After PAD moved to its own interface, there were duplicated statements in
wacom_setup_pentouch_input_capabilities. Merge them together to reduce future
maintenance effort.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
stylus_in_proximity is used to make sure no touch event is sent while pen is in
proximity. touch_down is used to make sure a touch up event is sent when pen
comes into proximity while touch is down.
Two touch routines didn't store touch_down. One touch routine forgot to check
stylus_in_proximity before sending touch events. This patch fixes those issues.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
It appears that the Cintiq Companion Hybrid does not send an ABS_MISC event to
userspace when any of its ExpressKeys are pressed. This is not strictly
necessary now that the pad exists on its own device, but should be fixed for
consistency's sake.
Traditionally both the stylus and pad shared the same device node, and
xf86-input-wacom would use ABS_MISC for disambiguation. Not sending this causes
the Hybrid to behave incorrectly with xf86-input-wacom beginning with its
8f44f3 commit.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some Cintiq and Intuos tablets report In Range event. This event is sent before
valid data is reported when tool enters proximity; or before out of proximity
event is reported when tool exits.
While entering proximity, In Range means a pen is detected. This information
can be used for palm/touch rejection on both pen and touch enabled devices.
While exiting, it means the tool has reached its maximum detectable distance.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Users may use unsupported tools on Cintiq or Intuos. When invalid tools or data
are detected, they should be ignored. That is, no event from those tools should
be reported.
Consolidating that code in wacom_intuos_inout simplifies the logic and make it
easier for future code change.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Jiri Kosina