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>

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>

The LED URB was left unkilled when the USB device is disconnected.
Signed-off-by: NWillem Penninckx <willem.penninckx@cs.kuleuven.be>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

usb_kbd_event() and usb_kbd_led() can be called concurrently, but they are not
synchronized. They both readwrite kbd->leds, and usb_kbd_event() originally just
checked the URB status field, while urb.h states that "It [status field] should
not be examined before the URB is returned to the completion handler."

To fix this unsynchronized behavior, this patch introduces a boolean
representing whether the URB is submitted, and a spinlock.
Signed-off-by: NWillem Penninckx <willem.penninckx@cs.kuleuven.be>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Adding support for Dream Cheeky DL1800B Friend Alert device.
Signed-off-by: NDan Delaney <drdelaney@loclhst.com>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The USB HID Usage Tables spec defines page 6 for Generic Device Controls, the
most useful of which (to me) is Battery Strength.
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>

This allows the latest N-Trig devices to function properly.

BugLink: https://bugs.launchpad.net/bugs/724831

Cc: stable@vger.kernel.org
Signed-off-by: NChase Douglas <chase.douglas@canonical.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Casting (void *) value returned by kmalloc is useless
as mentioned in Documentation/CodingStyle, Chap 14.

The semantic patch that makes this change is available
in scripts/coccinelle/api/alloc/drop_kmalloc_cast.cocci.
Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This reverts commit 0db3bfc7 (""HID: multitouch: decide if hid-multitouch
needs to handle mt devices").

The generic detection of hid-mt devices has two major flaws, and was
merged prematurely. Firstly, the hid-multitouch gets loaded even when
the device is handled by a special device. Secondly, the patch only
partially duplicates the device whitelist already present in hid-core,
effectively rendering a number of devices non-functional.
Reported-by: NSean Young <sean@mess.org>
Tested-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

It is not possible to take the lock in device if device is NULL.
The mutex_lock is thus moved after the NULL test.  New error handling
labels are added at the end to differentiate between the cases where
different sets of locks should be unlocks, and between whether or not
reader should be freed (only on error).

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
expression E, E1;
identifier f;
statement S1,S2,S3;
@@

if (E == NULL)
{
  ... when != if (E == NULL || ...) S1 else S2
      when != E = E1
*E->f
  ... when any
  return ...;
}
else S3
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

I've recently bought a Apple wireless aluminum keyboard (model 2011) which is
not yet supported by the kernel - it seems they just changed the device id.
After applying the attached patch, the device is fully functional.
Signed-off-by: NAndreas Krist <andreas.krist@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch adds keyboard support for Macbook Pro 8 models which has
WELLSPRING5A model name and 0x0252, 0x0253 and 0x0254 USB IDs. Trackpad
support for those models are added to bcm5974 in
c331eb58 ("Input: bcm5974 - Add
support for newer MacBookPro8,2).
Signed-off-by: NGökçen Eraslan <gokcen@pardus.org.tr>
Acked-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

hid-magicmouse was advertising the Apple Magic Trackpad as having 2
buttons (left and right) when it actually only has 1 button.

Advertising multiple buttons makes Xorg disable all button 2 and 3
emulation (using multi-finger clicks). So Xorg users don't get working
right/middle-click emulation out of the box.

This patch makes hid-magicmouse correctly only report one real button
for Magic Trackpad, which in turn makes Xorg enable multi-finger click
support to emulate right/middle buttons.

[http://launchpad.net/bugs/862094]
Signed-off-by: NDaniel van Vugt <vanvugt@gmail.com>
Reviewed-by: NChase Douglas <chase.douglas@canonical.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Support the following models: Super Joy Box 3 Pro, Super Dual Box Pro
and Super Joy Box 5 Pro. These models have support for pressure
sensitive buttons and they can force the controller to either digital
or analog mode, both of which are not supported yet.
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Remove Kconfig dependency for hid-primax driver on CONFIG_EXPERT.
Please see changelog of 73d5e8f7 ("HID: fix up 'EMBEDDED' mess in
Kconfig") for reasoning behind this.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Primax keyboards with the issue this driver addresses report modifier
keys as in band key events instead of as out of band modifier bits,
resulting in the modifier keys generating key up events immediately
before the keys they are intended to modify.  This driver rewrites
the raw report data from such keyboards into USB HID 1.11 compliant
report data.  It only matches the USB vendor and product IDs for the
keyboard it has been tested on. Since there are several keyboards,
notably a number of laptops and folding USB keyboards known to have
similar unresolved problem reports, the list is expected to grow.
Signed-off-by: NTerry Lambert <tlambert@chromium.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This makes sure IO is never restarted while a reset is going on

In particular there seems to be no protection from hid_retry_timeout() calling
hid_start_in() which would start IO after hid_pre_reset() has already called
hid_cease_io() because that uses del_timer(), not del_timer_sync()
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

We shouldn't change the event flags of input devices after they get registered.
Otherwise, udev will not get notified of these flags and cannot setup the
devices properly.
This fixes the probing to set the input event flags on the input_mapped callback
instead of the probe function.
Reported-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

MacbookAir 4,1 doesn't require extra mapping table, as the mappings
are identical to apple_fn_keys[].
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The respective mouse devices are already supported by bcm5974. Now that
Nobuhiro Iwamatsu added support for keyboard to hid-apple driver, we need
to ignore the mouse interfaces of these so that they can still be properly
claimed by bcm5974 driver.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Added USB device IDs and keyboard map for MacBookAir 4,1 keyboard.
Signed-off-by: NNobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In hidraw_open, if hid_hw_power returns with error, hidraw device open count
should not increase.
Signed-off-by: NAmit Nagal <helloin.amit@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Smatch has a new check for Rosenberg type information leaks where
structs are copied to the user with uninitialized stack data in them.

In this case, the hiddev_devinfo struct has a two byte hole.

struct hiddev_devinfo {
        __u32                      bustype;              /*     0     4 */
        __u32                      busnum;               /*     4     4 */
        __u32                      devnum;               /*     8     4 */
        __u32                      ifnum;                /*    12     4 */
        __s16                      vendor;               /*    16     2 */
        __s16                      product;              /*    18     2 */
        __s16                      version;              /*    20     2 */

        /* XXX 2 bytes hole, try to pack */

        __u32                      num_applications;     /*    24     4 */
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Now that hid-generic ignores all win7 compatible multitouch devices, this patch
allows hid-multitouch to catch them.  The idea is to rely on the quirk
HID_QUIRK_MULTITOUCH to drop the device if no ContactID is given.

There is the need for a blacklist here as other devices may need a special
driver (ntrig for instance).
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@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>

There's been a small oversight when adding support for Logitech Driving Force
GT. Entry in hid-core was missing so the generic driver instead of hid-logitech
was being used.
Signed-off-by: NMichal Malý <madcatxster@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There is a bug where a device with index 6 would write out of bounds in
the array of paired devices.
This patch fixes that problem.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NOlivier Gay <ogay@logitech.com>
Signed-off-by: NNestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The function hidraw_disconnect() only acquires the hidraw minors_lock
when clearing the entry in hidraw_table. However the device_destroy()
call can cause a userland read/write to return with an error. It may
cause the program to release the file descripter before the disconnect
is finished. hidraw_disconnect() has already set hidraw->exist to 0,
which makes hidraw_release() kfree the hidraw structure, which
hidraw_disconnect() continues to access and even tries to kfree again.
Similarly if a hidraw_release() occurs after setting hidraw->exist to 0,
the same thing can happen.

This is fixed by expanding the mutex critical section to cover the whole
function from setting hidraw->exist to 0 to freeing the hidraw
structure, preventing a hidraw_release() from interfering.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Tested-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>