user/sven/linux.git/include/linux/hid.h, branch v3.3.5

Merge branch 'hid-battery' of git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen into for-linus

2012-01-09T10:24:59Z

hid-input/battery: remove battery_val

2012-01-08T07:31:18Z

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: Jeremy Fitzhardinge

hid-input/battery: deal with both FEATURE and INPUT report batteries

2012-01-08T07:30:37Z

Some devices seem to report batteries as FEATUREs, others as INPUTs. Signed-off-by: Jeremy Fitzhardinge

hid-input/battery: add quirks for battery

2012-01-08T07:30:37Z

Some devices always report percentage, despite having 0/255 as their min/max, so add a quirk for them. Signed-off-by: Jeremy Fitzhardinge

hid-input: add support for HID devices reporting Battery Strength

2012-01-08T07:30:34Z

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: Daniel Nicoletti

Merge branches 'hyperv', 'multitouch', 'roccat', 'upstream', 'upstream-fixes', 'wacom' and 'wiimote' into for-linus

2012-01-05T14:51:02Z

HID: usbhid: defer LED setting to a workqueue

2011-12-21T10:18:35Z

Defer LED setting action to a workqueue. This is more likely to send all LED change events in a single URB. Signed-off-by: Daniel Kurtz Acked-by: Oliver Neukum Signed-off-by: Jiri Kosina

HID: hid-input: add support for HID devices reporting Battery Strength

2011-11-28T10:10:22Z

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--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: Jeremy Fitzhardinge Signed-off-by: Jiri Kosina

include: convert various register fcns to macros to avoid include chaining

2011-10-31T23:32:32Z

The original implementations reference THIS_MODULE in an inline. We could include , but it is better to avoid chaining. Fortunately someone else already thought of this, and made a similar inline into a #define in for device_schedule_callback(), [see commit 523ded71de0] so follow that precedent here. Also bubble up any __must_check that were used on the prev. wrapper inline functions up one to the real __register functions, to preserve any prev. sanity checks that were used in those instances. Signed-off-by: Paul Gortmaker

Merge branch 'upstream' into for-linus

2011-10-25T07:59:04Z

Conflicts: drivers/hid/hid-core.c drivers/hid/hid-ids.h