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: NAaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri 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: NAaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri 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: NJason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri 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: NJason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri 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: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri 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: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri 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: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri 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: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri 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: NJason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

We use generic hid_report_len() to get individual packet length now.
Signed-off-by: NPing Cheng <pingc@wacom.com>
Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri 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: NPing Cheng <pingc@wacom.com>
Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri 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: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The constant is not used (leftover from previous patch versions
that never got merged).
Reported-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri 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: NJason Gerecke <killertofu@gmail.com>
Acked-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri 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: NJosep Sanchez Ferreres <josep.sanchez.ferreres@est.fib.upc.edu>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NJosep Sanchez Ferreres <josep.sanchez.ferreres@est.fib.upc.edu>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

These devices have accelerometers. To report accelerometer coordinates, a new
property, INPUT_PROP_ACCELEROMETER, is added.
Signed-off-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri 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: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Bamboo Pads are using the generic processing but their report descriptors
differ from the ISDv* line. The pen fields are marked with the .physical
as Digitizer_Pen, which makes also sense.

Add this field to the checks and enable for free Bamboo Pads.
Reported-by: NJosep Sanchez Ferreres <josep.sanchez.ferreres@est.fib.upc.edu>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NJiri 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: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The existing generic touch code only reports events after reading an
entire HID report, which practically means that only data about the last
contact in a report will ever be provided to userspace. This patch uses
a trick from hid-multitouch.c to discover what type of field is at the
end of each contact; when such a field is encountered all the stored
contact data will be reported.
Signed-off-by: NJason Gerecke <killertofu@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NPing Cheng <pingc@wacom.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Tested-by: NPrzemo Firszt <przemo@firszt.eu>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

First, merge the Graphire BT tablet.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Tested-by: NPrzemo Firszt <przemo@firszt.eu>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Tested-by: NPrzemo Firszt <przemo@firszt.eu>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NPrzemo Firszt <przemo@firszt.eu>
Acked-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NPrzemo Firszt <przemo@firszt.eu>
Acked-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

- 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: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NPrzemo Firszt <przemo@firszt.eu>
Acked-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

wacom.ko is now a full HID driver, we have to move it into the proper
subdirectory: drivers/hid.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

pktlen is now overwritten by the driver directly by reading the hid
report descriptor. There is no need to declare it statically.
We also move down the position of the field in the struct so that
we can keep the current declaration of Wacom devices.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NJason Gerecke <killertofu@gmail.com>
Tested-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NJason Gerecke <killertofu@gmail.com>
Tested-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

All USB Wacom tablets are actually HID devices.
For historical reasons, they are handled as plain USB devices.
The current code makes more and more reference to the HID subsystem
like implementing its own HID report descriptor parser to handle new
devices.

From the user point of view, we can transparently switch from this state
to a driver handled in the HID subsystem and clean up a lot of USB specific
code in the wacom.ko driver.

The other benefit once the USB dependecies have been removed is that we can
use a tool like uhid to make regression tests and allow further cleanup or
new implementations without risking breaking current behaviors.

To match the current handling of devices in wacom_wac.c, we rely on the
hid_type set by usbhid. usbhid sets the hid_type to HID_TYPE_USBMOUSE when
it sees a USB boot mouse protocol declared and HID_TYPE_USBNONE when the
device is plain HID. There is thus a one to one matching between the list
of supported devices before and after the switch from USB to HID.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NJason Gerecke <killertofu@gmail.com>
Tested-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Currently, the pad events are sent through the stylus input device
for the Intuos/Cintiqs, and through the touch input device for the
Bamboos.

To differentiate the buttons pressed on the pad from the ones pressed
on the stylus, the Intuos/Cintiq uses MISC_SERIAL and ABS_MISC. This
lead to a multiplexing of the events into one device, which are then
splitted out in xf86-input-wacom. Bamboos are not using MISC events
because the pad is attached to the touch interface, and only BTN_TOUCH
is used for the finger (and DOUBLE_TAP, etc...). However, the user space
driver still splits out the pad from the touch interface in the same
way it does for the pro line devices.

The other problem we can see with this fact is that some of the Intuos
and Cintiq have a wheel, and the effective range of the reported values
is [0..71]. Unfortunately, the airbrush stylus also sends wheel events
(there is a small wheel on it), but in the range [0..1023]. From the user
space point of view it is kind of difficult to understand that because
the wheel on the pad are quite common, while the airbrush tool is not.

A solution to fix all of these problems is to split out the pad device
from the stylus/touch. This decision makes more sense because the pad is
not linked to the absolute position of the finger or pen, and usually, the
events from the pad are filtered out by the compositor, which then convert
them into actions or keyboard shortcuts.

For backward compatibility with current xf86-input-wacom, the pad devices
still present the ABS_X, ABS_Y and ABS_MISC events, but they can be
completely ignored in the new implementation.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Reviewed-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

New Cintiq tablets have a 200 tablet counts outside of screen area.
Add x/y_min for ABS_X/Y to pass this information to userland.
Signed-off-by: NPing Cheng <pingc@wacom.com>
Reviewed-by: NJason Gerecke <killertofu@gmail.com>
Tested-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This patch adds support for the 0x4004, 0x5000, and 0x5002 sensors found
on what should be the Motion R12, Fujitsu Q704, and Fujitsu T904. These
tablets use a new report ID (3) for their touch packets and a slightly
different HID descriptor format, but are otherwise largely identical in
protocol to the "MTTPC" tablets.

Note:
 * The R12 uses its 0x4004 sensor for touch input only. A pen interface
   is not present in its HID descriptor, though its possible a 0x4004
   may be used for pen input by other tablet PCs in the future.

 * The 0x5002 sensor appears to use a new report ID (8) for its pen
   packets. The other sensors continue to use the traditional report
   ID (2).
Signed-off-by: NJason Gerecke <killertofu@gmail.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The Win8 version of the Panasonic CF-H2 includes a new Wacom device.
The pen interface appears to use the same protocol as before, but the
touch interface has been tweaked to send Win8-compatible reports.
Signed-off-by: NJason Gerecke <killertofu@gmail.com>
Reviewed-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>