It just isn't a battery which is powering the computer. upower needs
a more nuanced understanding of this.
Signed-off-by: Jeremy 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: Jeremy 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: Daniel 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: Jeremy Fitzhardinge <jeremy@goop.org>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Jiri 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: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The LED URB was left unkilled when the USB device is disconnected.
Signed-off-by: Willem Penninckx <willem.penninckx@cs.kuleuven.be>
Signed-off-by: Jiri 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: Willem Penninckx <willem.penninckx@cs.kuleuven.be>
Signed-off-by: Jiri 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: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jiri 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: Denilson Figueiredo de Sá <denilsonsa@gmail.com>
Tested-by: Denilson Figueiredo de Sá <denilsonsa@gmail.com>
Signed-off-by: Jiri 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: Denilson Figueiredo de Sá <denilsonsa@gmail.com>
Tested-by: Denilson Figueiredo de Sá <denilsonsa@gmail.com>
Signed-off-by: Jiri 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: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
Revert "HID: multitouch: decide if hid-multitouch needs to handle mt devices"
HID: drivers/hid/hid-roccat.c: eliminate a null pointer dereference
HID: hid-apple: add device ID of another wireless aluminium
HID: Add device IDs for Macbook Pro 8 keyboards
This reverts commit 0db3bfc72a (""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: Sean Young <sean@mess.org>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Jiri 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: Julia Lawall <julia@diku.dk>
Signed-off-by: Jiri 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: Andreas Krist <andreas.krist@gmail.com>
Signed-off-by: Jiri 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
c331eb580a ("Input: bcm5974 - Add
support for newer MacBookPro8,2).
Signed-off-by: Gökçen Eraslan <gokcen@pardus.org.tr>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* 'pm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (63 commits)
PM / Clocks: Remove redundant NULL checks before kfree()
PM / Documentation: Update docs about suspend and CPU hotplug
ACPI / PM: Add Sony VGN-FW21E to nonvs blacklist.
ARM: mach-shmobile: sh7372 A4R support (v4)
ARM: mach-shmobile: sh7372 A3SP support (v4)
PM / Sleep: Mark devices involved in wakeup signaling during suspend
PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image
PM / Hibernate: Do not initialize static and extern variables to 0
PM / Freezer: Make fake_signal_wake_up() wake TASK_KILLABLE tasks too
PM / Hibernate: Add resumedelay kernel param in addition to resumewait
MAINTAINERS: Update linux-pm list address
PM / ACPI: Blacklist Vaio VGN-FW520F machine known to require acpi_sleep=nonvs
PM / ACPI: Blacklist Sony Vaio known to require acpi_sleep=nonvs
PM / Hibernate: Add resumewait param to support MMC-like devices as resume file
PM / Hibernate: Fix typo in a kerneldoc comment
PM / Hibernate: Freeze kernel threads after preallocating memory
PM: Update the policy on default wakeup settings
PM / VT: Cleanup #if defined uglyness and fix compile error
PM / Suspend: Off by one in pm_suspend()
PM / Hibernate: Include storage keys in hibernation image on s390
...
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: Daniel van Vugt <vanvugt@gmail.com>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Jiri 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: Sean Young <sean@mess.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Remove Kconfig dependency for hid-primax driver on CONFIG_EXPERT.
Please see changelog of 73d5e8f77e ("HID: fix up 'EMBEDDED' mess in
Kconfig") for reasoning behind this.
Signed-off-by: Jiri 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: Terry Lambert <tlambert@chromium.org>
Signed-off-by: Jiri 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: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri 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: Bastien Nocera <hadess@hadess.net>
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* pm-runtime:
PM / Tracing: build rpm-traces.c only if CONFIG_PM_RUNTIME is set
PM / Runtime: Replace dev_dbg() with trace_rpm_*()
PM / Runtime: Introduce trace points for tracing rpm_* functions
PM / Runtime: Don't run callbacks under lock for power.irq_safe set
USB: Add wakeup info to debugging messages
PM / Runtime: pm_runtime_idle() can be called in atomic context
PM / Runtime: Add macro to test for runtime PM events
PM / Runtime: Add might_sleep() to runtime PM functions
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: Jiri Kosina <jkosina@suse.cz>
In hidraw_open, if hid_hw_power returns with error, hidraw device open count
should not increase.
Signed-off-by: Amit Nagal <helloin.amit@gmail.com>
Signed-off-by: Jiri 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: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jiri 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: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Jiri 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: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Signed-off-by: Jiri 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: Michal Malý <madcatxster@gmail.com>
Signed-off-by: Jiri 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: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Olivier Gay <ogay@logitech.com>
Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: Jiri 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: James Hogan <james.hogan@imgtec.com>
Tested-by: David Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The IDEACOM 6650 multitouch chip, present in various all-in-one computers,
uses the serial version of the HID multitouch protocol. No existing class
supports this.
In principle, the new MT_CLS_SERIAL should work for other
serial panels as well, perhaps including some eGalax panels.
Signed-off-by: Stephane Chatty <chatty@enac.fr>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
With this driver, all the devices paired to a single Unifying
receiver are exposed to user processes in separated /input/dev
nodes.
Keyboards with different layouts can be treated differently,
Multiplayer games on single PC (like home theater PC) can
differentiate input coming from different kbds paired to the
same receiver.
Up to now, when Logitech Unifying receivers are connected to a
Linux based system, a single keyboard and a single mouse are
presented to the HID Layer, even if the Unifying receiver can
pair up to six compatible devices. The Unifying receiver by default
multiplexes all incoming events (from multiple keyboards/mice)
into these two.
Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Adds INPUT_PROP_POINTER or INPUT_PROP_DIRECT as necessary to the
hardware supported by the Wacom driver. The DIRECT property is
assigned to devices with an embedded screen (i.e. touchscreens
and display tablets). The POINTER property is assigned to those
without embedded screens.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
