Looks like recent changes in the Wacom driver made the Bamboo ONE crashes.
The tablet behaves as if it was a regular Bamboo device with pen, touch
and pad, but there is no physical pad connected to it.
The weird part is that the pad is still sending events and given that
there is no input node connected to it, we get anull pointer exception.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1317116
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Allow to reuse the code in a later series and simplifies
the reading of wacom_intuos_inout().
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
INTUOSHT2 in range event is not used to indicate in proximity state.
INTUOSHT2 only has one stylus.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
stylus_in_proximity was introduced to support touch arbitration
before in range was supported. With in range event, the logic
changed. stylus_in_proximity should be set for both in prox and
in range events.
To finish a clean touch arbitration logic, we should send touch
up (if it was down) before posting any general pen events.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Move general events related data validation to wacom_intuos_general.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Move wacom_intuos_schedule_prox_event inside wacom_intuos_general
so we don't call it when general event data isn't ready.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit c7f0522 incorrectly constructs the 'buttons' variable for the
CINTIQ_COMPANION_2 case. The high nybble of data[2] is shifted four
bits too far, leaving the bits associated with BTN_7 through BTN_A
unset.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit c7f0522 reports incorrect touchring values to userspace. This is
due to its incorrect handling of the 'touched' bit present in the 'ring1'
and 'ring2' variables. Instead of using this bit when determining if a
value should be sent, the ABS_WHEEL and ABS_INPUT check (different?!)
portions of the position bits. Furthermore, the full values of 'ring1'
and 'ring2' are reported to userspace, despite the 'touched' flag
needing to be trimmed beforehand. This commit addresses both issues.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit c7f0522 accidentally used ABS_RX for reporting both 'strip1' and
'strip2', when the latter should actually be reported through ABS_RY.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit c7f0522 uses sixteen bits of data in the construction of 'strip1'
and 'strip2'. This can cause problems in some cases, however, since some
tablets store flags in the MSB of data[2] and data[4] that should not be
included in these values. This restores the 0x1f mask that used prior
to c7f0522.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Smatch complains that these should probably be bitwise ORs instead of
logical. It doesn't matter for "prox" but it makes a difference for
"strip1" and "strip2".
Fixes: c7f0522a1a ('HID: wacom: Slim down wacom_intuos_pad processing')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When splitting the touch-only "BAMBOO_TOUCH" type out of the existing
"BAMBOO_PT" type in 3b164a00, the lowres quirk was not updated so that
it would continue to apply to these devices (effectively only the 0xD0).
The absence of this quirk does not significantly impact usability, but
is a correctness issue nonetheless.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
"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: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Make the logic for reading X, Y, distance, and pressure a bit more
clear. An additional bit was stuffed into the packet format many
models back, and /most/ devices in use will use it. If we happen
to be dealing with a particularly old tablet, just shift it off
the end to pretend we never read it.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Continue re-organizing and trimming cases to make it easier to wrap
the brain around. A number of changes were made after consulting the
protocol spec and so don't necessarily follow from the code itself.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Reasoning through the conditions under which a particular block of code
in 'wacom_intuos_general' will be reached is not at all easy due to the
sheer number of magic masks and comparisons. Remove these and replace
them with a switch statement over the various 'types' of packets that
will be encountered.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Continue to slim down 'wacom_intuos_irq' by moving all decoding and
reporting of pen packet data into the 'wacom_intuos_general' function.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Seperate the function into two halves: first gather data from the packet,
next report all gathered data. The input subsystem should automatically
mute any events that aren't actually declared for the tablet at hand.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Begin slimming down the body of 'wacom_intuos_irq' by moving out its
largest block of code to a dedicated 'wacom_intuos_pad' function.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Given that INTUOSHT < BAMBOO_PT
features->type >= INTUOSHT || features->type <= BAMBOO_PT
condition is always true, and therefore device_type is under certain
circumstances wrongly set with WACOM_DEVICETYPE_PAD bit set.
Fix the condition so that it actually represents the range as intended.
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
DTU1141 has an extra 1 mm tablet active outbounding area on each
side of the display, same as those recently released DTUs.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The pad handling code introduced for the Cintiq Companion 2 (f7acb55)
looks at the wrong bytes in the report when deciding whether ABS_MISC
should be sent. This does not cause any issues with the X driver now
that the pen and pad have been split to separate devices, but is
incorrect and has caused issues when backporting to distros with pre-
3.17 kernels.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: Dale Brewe <dlbrewe@hotmail.com>
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When introduced in commit 1b5d514, the check 'if (hid_data->cc_index >= 0)'
in 'wacom_wac_finger_pre_report' was intended to switch where the driver
got the expected number of contacts from: HID_DG_CONTACTCOUNT if the usage
was present, or 'touch_max' otherwise. Unfortunately, an oversight worthy
of a brown paper bag (specifically, that 'cc_index' could never be negative)
meant that the latter 'else' clause would never be entered.
The patch prior to this one introduced a way for 'cc_index' to be negative,
but only if HID_DG_CONTACTCOUNT is present in some report _other_ than the
one being processed. To ensure the 'else' clause is also entered for devices
which don't have HID_DG_CONTACTCOUNT on _any_ report, we add the additional
constraint that 'cc_report' be non-zero (which is true only if the usage is
present in some report).
Cc: stable@vger.kernel.org
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The new Intuos tablets added in eda01da and the Cintiq 13HD Touch added
in b4bf212 are capable of reporting 2048 levels of pressure. Although the
kernel reports the correct range to userspace, an oversight has resulted
in the driver ingoring the 11th pressure bit and only sending pressures
of 0 through 1023.
We could fix this issue by expanding the type check to include these
devices, but it makes much more sense to just have the driver look at
the device's maximum pressure when determining if it should read the
11th bit.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Clifford Jolly <expiredpopsicle@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This series of devices supports both pen and touch. It reports
touch data in Bamboo3 format and pen data in Intuos pro format.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Tested-By: Aaron Skomra <aaron.skomra@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Not all Bamboo support both pen and touch. Make sure we deal with
pen only and touch only devices properly.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Tested-By: Aaron Skomra <aaron.skomra@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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>
