Support battery capacity on another Apple wireless keyboard.
Signed-off-by: NOrtwin Glück <odi@odi.ch>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Button names for USB gamepads are currently assigned incorrectly, as the evdev
code assigned to buttons is "BTN_GAMEPAD + code", which on devices with more
then 16 buttons bleeds over into button names reserved for graphic tablets
(BTN_TOOL_PEN, etc.). This causes problems further down the line as the device
are now no longer detected as joystick. This patch fixes that by assigning
buttons outside the range to BTN_TRIGGER_HAPPY (as is already the case for USB
joysticks).

Furthermore this patch corrects the assignment to BTN_TRIGGER_HAPPY, as
currently the first button over 16 is assigned to BTN_TRIGGER_HAPPY17 (i.e.
BTN_TRIGGER_HAPPY+0x10) not BTN_TRIGGER_HAPPY.
Signed-off-by: NIngo Ruhnke <grumbel@gmail.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

A hid device may create several input devices, and a driver may need
to prepare or finalize the configuration per input device. Currently,
there is no sane way for a driver to know when a device has been
configured. This patch adds a callback providing that information.
Reviewed-and-tested-by: NBenjamin Tissoires <benjamin.tissoires@enac.fr>
Tested-by: NPing Cheng <pingc@wacom.com>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>

The keys are found on the keyboards bundled with HP All-In-One machines
with USB VID/PID of 04ca:004d and 04f2:1061.
Signed-off-by: NKeng-Yu Lin <kengyu@canonical.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI, to the quirk list since it report
wrong feature type and wrong percentage range.
Signed-off-by: NDaniel Nicoletti <dantti12@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Switch the driver over to device group handling.  By adding the
HID_GROUP_MULTITOUCH group to hid-core, hid-generic will no longer
match multitouch devices.  By adding the HID_GROUP_MULTITOUCH entry to
the device list, hid-multitouch will match all unknown multitouch
devices, and udev will automatically load the module.

Since HID_QUIRK_MULTITOUCH never gets set, the special quirks handling
can be removed.  Since all HID MT devices have HID_DG_CONTACTID, they
can be removed from the hid_have_special_driver list.

With this patch, the unknown device ids are no longer NULL, so the code
is modified to check for the generic entry instead.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add digitizer X Tilt and Y Tilt usage support along with resolution calculation.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Allow array field values out of range as per HID 1.11 specification,
section 6.2.25:

	Rather than returning a single bit for each button in the group, an
	array returns an index in each field that corresponds to the pressed
	button (like keyboard scan codes). An out-of range value in and array
	field is considered no controls asserted.

Apparently, "and" above is a typo and should be "an".

This fixes at least Waltop tablet pen clicks - otherwise BTN_TOUCH is never
released.

The relevant part of Waltop tablet report descriptors is this:

	0x09, 0x42,         /*          Usage (Tip Switch),         */
	0x09, 0x44,         /*          Usage (Barrel Switch),      */
	0x09, 0x46,         /*          Usage (Tablet Pick),        */
	0x15, 0x01,         /*          Logical Minimum (1),        */
	0x25, 0x03,         /*          Logical Maximum (3),        */
	0x75, 0x04,         /*          Report Size (4),            */
	0x95, 0x01,         /*          Report Count (1),           */
	0x80,               /*          Input,                      */

This is a regression fix for commit b4b583d4 ("HID: be more strict when
ignoring out-of-range fields").
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Set the battery's power supply scope to "Device" and point the power
supply to the powered device.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Apple keyboards require a FEATURE report to query the battery state,
even though they list as an input.  Without this, it returns an error.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>

hidinput_get_battery_property() now directly polls the device for the
current battery strength, so there's no need for battery_val, or the
code to set it on the input event path.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>

It just isn't a battery which is powering the computer.  upower needs
a more nuanced understanding of this.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>

Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>

Some devices seem to report batteries as FEATUREs, others as INPUTs.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>

Some devices always report percentage, despite having 0/255 as their
min/max, so add a quirk for them.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>

Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>

I've sent an email earlier asking for help with a GetFeature code, and now I
have a second patch on top of Jeremy's to provide the battery functionality
for devices that support reporting it.

If I understood correctly when talking to Jeremy he said his device
never actually reported the status as an input event (sorry if I didn't
understand it correctly), and after reading HID specs I believe it's
really because it was meant to be probed, I have an Apple Keyboard and
Magic Trackpad both bluetooth batteries operated, so using PacketLogger
I saw that Mac OSX always ask the battery status using the so called
GetFeature.

What my patch does is basically:
- store the report id that matches the battery_strength
- setup the battery if 0x6.0x20 is found, even if that is reported as a feature
  (as it was meant to be but only the MagicTrackpad does)
- when upower or someone access /sys/class/power_supply/hid-*/capacity it
  will probe the device and return it's status.

It works great for both devices, but I have two concerns:
- the report_features function has a duplicated code
- it would be nice if it was possible for specific drivers to provide their own
  probe as there might be some strange devices... (but maybe it's
already possible)

I've talked to the upower dev and he fixed it to be able to show the
right percentage.

Here how the uevent file (in /sys/class/power_supply/hid-*/) looks like:
POWER_SUPPLY_NAME=hid-00:22:41:D9:18:E7-battery
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_CAPACITY=66
POWER_SUPPLY_MODEL_NAME=MacAdmin’s keyboard
POWER_SUPPLY_STATUS=Discharging

POWER_SUPPLY_NAME=hid-70:CD:60:F5:FF:3F-battery
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_CAPACITY=62
POWER_SUPPLY_MODEL_NAME=nexx’s Trackpad
POWER_SUPPLY_STATUS=Discharging
Signed-off-by: NDaniel Nicoletti <dantti12@gmail.com>

Defer LED setting action to a workqueue.
This is more likely to send all LED change events in a single URB.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Acked-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

As reported by Stephen Rothwell:
drivers/hid/hid-input.c: In function 'hidinput_hid_event':
drivers/hid/hid-input.c:865:6: error: 'struct hid_device' has no member
named 'battery_val'
drivers/hid/hid-input.c:866:3: error: 'struct hid_device' has no member
named 'battery_min'
drivers/hid/hid-input.c:866:3: error: 'struct hid_device' has no member
named 'battery_max'
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event.  Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.

The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.

Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).

Still, this patch is the first step.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

HID 1.11 specification, section 5.10 tells us:

	HID class devices support the ability to ignore selected fields in a
	report at run- time. This is accomplished by declaring bit field in a
	report that is capable of containing a range of values larger than
	those actually generated by the control. If the host or the device
	receives an out-of-range value then the current value for the
	respective control will not be modified.

So we shouldn't be restricted to EV_ABS only.
Reported-by: NDenilson Figueiredo de Sá <denilsonsa@gmail.com>
Tested-by: NDenilson Figueiredo de Sá <denilsonsa@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Linux should ignore values outside logical min/max range, as they are not
meaningful. This is what at least some of other OSes do, and it also makes
sense (currently the value gets misinterpreted larger up the stack).
Reported-by: NDenilson Figueiredo de Sá <denilsonsa@gmail.com>
Tested-by: NDenilson Figueiredo de Sá <denilsonsa@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

As mentioned by http://www.microsoft.com/whdc/device/input/DigitizerDrvs_touch.mspx
multitouch devices are those that have the input report HID_CONTACTID.

This patch detects this and unloads the generic-usb driver.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@enac.fr>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

I've got a Tivo Slide bluetooth remote/dongle, which uses a fair number
of hid usages that aren't currently mapped in hid-input.c. I'd initially
written additions to hid-input.c with just this device in mind,
including some bits that were specific to the device. This go around,
I'm looking at adding/correcting as many generic HID usages from the HID
Usage Tables, version 1.12, as I can -- which also serves to enable all
but four of the buttons on the Tivo Slide remote[*].

Outside of fixing the obviously incorrect mapping of 0xc 0x45 from
KEY_RADIO to KEY_RIGHT, and making use of the new KEY_IMAGES (just added
in 2.6.39-rc4) for AL Image Browser instead of KEY_MEDIA, these are
purely additions, and thus should have no negative impact on any already
functional HID devices. Most of the added mappings seemed to be
perfectly logical to me, but there were a few that were mapped on more
of an "I think this makes the most sense" basis.

[*] I'll handle the last four tivo buttons via an hid-tivo.c follow-up.

CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CC: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When the multi input quirk is set, there is a new input device
created for every feature report. Since the idea is to present
features per hid device, not per input device, revert back to
the original report loop and change the feature_mapping() callback
to not take the input device as argument.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Tested-by: NBenjamin Tissoires <benjmain.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Goto out_cleanup infers a kernel oops: hidinput_disconnect calls
input_unregister_driver to all members of hid->inputs.
However, hidinput already has been added to hid->inputs even
though input_register_device was not called.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@enac.fr>
Reviewed-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

All users of old style get/setkeycode methids have been converted so
it is time to retire them.
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Currently hid doesn't export the features it knows to the specific modules.
Some information can be really important in such features: MosArt and
Cypress devices are by default not in a multitouch mode.
We have to send the value 2 on the right feature.

This patch exports to the module the features report so they can find the
right feature to set up the correct mode.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@enac.fr>
Acked-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Instead of using magic values, use their corresponding BTN_* defines
from linux/input.h.
Signed-off-by: NFlorian Fainelli <ffainelli@freebox.fr>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Neaten current uses of dev_<level> by adding and using
hid specific hid_<level> macros.

Convert existing uses of dev_<level> uses to hid_<level>.
Convert hid-pidff printk uses to hid_<level>.

Remove err_hid and use hid_err instead.

Add missing newlines to logging messages where necessary.
Coalesce format strings.

Add and use pr_fmt(fmt) KBUILD_MODNAME ": " fmt

Other miscellaneous changes:

Add const struct hid_device * argument to hid-core functions
extract() and implement() so hid_<level> can be used by them.
Fix bad indentation in hid-core hid_input_field function
that calls extract() function above.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Instead of exposing the guts of hid->ll_driver relationship to HID
sub-drivers provide these helpers to encapsulate the details.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Input ABI requires reporting resolution on main axes in units per
millimeter, not units per inch, so we need to convert accordingly.
Tested-by: NNikolai Kondrashov <spbnick@gmail.com>
Acked-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add absolute axis resolution calculation to the core HID layer, according to HID
specification v1.11 6.2.2.7 Global Items. Only exponent 1 length units for
X/Y/Z/RX/RY/RZ axis are supported for now.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

As of lately, HID devices which send per-frame data split over several
HID reports have started to emerge. This patch adds a quirk which
allows the HID driver to take over the input layer synchronization,
and hence the control of the frame boundary.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Currently HID layer only allows to remap keycodes for known usages,
and responds with -EINVAL when user tries to map new usage code.
This precludes us form relying on udev/keymap for establishing correct
mappings and forces us to write dummy HID drivers responsible only for
setting up keymaps.

Let's allow remapping not only usages that have been set up as keys
(usage->type == EV_KEY) but also yet-unmapped usages (usage->type == 0).
Acked-by: NJarod Wilson <jarod@redhat.com>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Switch HID code to use new style of getkeycode and setkeycode
methods to allow retrieving and setting keycodes not only by
their scancodes but also by index.
Acked-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Many tablet input drivers use BTN_STYLUS2 code to report a second
tablet stylus button. Yet, the generic HID input driver doesn't map it.
Apparently, because there is no corresponding usage in the HID Usage Tables.

This patch selects a compromise usage - "Tablet Pick" (0x46) to be mapped to
BTN_STYLUS2. Some tablets use "Eraser" usage, but mapping it to a button
wouldn't be entirely correct, because the specification says it may be "a
pressure quantity".
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

SMART Technologies has recommended this change to fix a problem reported
with SMART Board series interactive whiteboards.

A description of the device-specific symptom follows:

  When the board is connected my mouse bounces up to the top left corner.

Bjorn has tested this fix with model SB680.
Tested-by: NBjorn Behrendt <bbehrendt@msjvermont.org>
Signed-off-by: NForest Bond <forest@alittletooquiet.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>