This reverts commit 3fe1d6bb.

It turns out the current API is not that compatible with
some Microsoft mice, so better start again from scratch.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHarry Cutts <hcutts@chromium.org>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NJiri Kosina <jkosina@suse.cz>

This reverts commit 5fe2ccbe.

It turns out the current API is not that compatible with
some Microsoft mice, so better start again from scratch.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHarry Cutts <hcutts@chromium.org>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NJiri Kosina <jkosina@suse.cz>

Fix the following compile warning:

drivers/hid/hid-logitech-hidpp.c: In function 'hi_res_scroll_enable':
drivers/hid/hid-logitech-hidpp.c:2714:54: warning: 'multiplier' may be used uninitialized in this function [-Wmaybe-uninitialized]
  hidpp->vertical_wheel_counter.resolution_multiplier = multiplier;
Signed-off-by: Nzhong jiang <zhongjiang@huawei.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NHarry Cutts <hcutts@chromium.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There are three features used by various Logitech mice for
high-resolution scrolling: the scrolling acceleration bit in HID++ 1.0,
and the x2120 and x2121 features in HID++ 2.0 and above. This patch
supports all three, and uses the multiplier reported by the mouse for
the HID++ 2.0+ features.

The full list of product IDs of mice which support high-resolution
scrolling was provided by Logitech, but the patch was tested using the
following mice (using the Unifying receiver):

* HID++ 1.0: Anywhere MX, Performance MX
* x2120: M560
* x2121: MX Anywhere 2, MX Master 2S
Signed-off-by: NHarry Cutts <hcutts@chromium.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

"Scrolling acceleration" is a bit of a misnomer: it doesn't deal with
acceleration at all. However, that's the name used in Logitech's spec,
so I used it here.
Signed-off-by: NHarry Cutts <hcutts@chromium.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Trivial fix to spelling mistake in hid_info message and add line break
to split an overly long line to clean up a checkpatch warning.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Acked-By: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by <linux/sysfs.h> work with
const attribute_group. So mark the non-const structs as const.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Check return value from call to devm_kmemdup() in order to prevent a NULL
pointer dereference.
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This way, upower can add a simple udev rule to decide whether or not
it should use the internal unifying support or just the generic kernel
one.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Also enable battery reporting for HID++ 1.0 devices through 2 registers:
0x07: battery status -> reports only 4 levels (critical, low, good, full)
0x0D: battery mileage -> reports true pourcentage
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The Solar Keyboard uses a different feature to report the battery level.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

CAPACITY LEVEL allows to forward rough information on the battery mileage.
HID++ 2.0 devices will either report percentage or levels, so better
forwarding this information to the user space.

The M325 supports only 2 levels: 'Full' and 'Critical'. With mileage,
it will report either 90% or 5%, which might confuse users. With this
change the battery will either report "Full" or "Critical".
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The power_supply term for the percentage is capacity. Capacity level
can be given when non accurate mileage is provided by the device, so
better stick to the terms used in power_supply.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When ONLINE isn't set, upower should ignore the battery capacity,
so there is no need to overload it with some random values.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When a device reconnects, there is a high chance its power supply has
been changed (for a battery replacement for instance). Just forward
the battery state here.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Or the device just answers a valid feature '0'.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The creation of the power_supply should not be in a HID++ 2.0 specific
function.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Better forwarding the device name, manufacturer and serial to upower.
Note that serial is still empty, it will be filled in a later patch
in this series.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Battery events are reported through HID++, so we need to be sure
the report ID is the HID++ one.

Without this, we might receive keyboard events that looks just like
battery events with wrong data and which will confuse user space.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Looks like all users don't care about a disconnect.
Simplify the various variant_connect() and put the connect state check
at the beginning.

For delayed input devices, make sure we go through all other connect
values (protocol, battery) before bailing out.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

hidpp->name can't be null.
Only HID++ 2.0 and above device supports the query.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Unifying devices are different from others because they can probed
while not connected. So we need to talk to the receiver to get some
extra information like the device name and the serial.

Instead of having conditionals while attempting to read the device name
from HID++ 2.0, have a special init path for them.

Store the retrieved serial in hdev->uniq.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Do not pollute the quirks bits field which is public API
with elements that are queried from the device.

Move the 2 battery capabilities into the new field.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Unless they are connected through unifying, they don't support it,
so remove one error in the logs.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Simple check to add, huge improvement :)
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Without a scope defined, UPower assumes that the battery provides
power to the computer it's connected to, like a laptop battery or a UPS.
Tested-by: NPeter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Now that we can create battery power_supply sources, it's better to enable
the connect_event callback unconditionally.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NPeter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

If the 0x1000 Unified Battery Level Status feature exists, expose the battery
level.

The main drawback is that while a device is plugged in its battery level is 0.
To avoid exposing that as 0% charge we make up a number based on the charging
status.
Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

hidpp_ff_init() and hidpp_ff_deinit() are not used outside of
hid-logitech-hidpp.c, so let's make them static.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch implements force feedback support for the Logitech
G920 Driving Force Racing Wheel. It is a generic implementation
of feature 0x8123 of the Logitech HID++ protocol and should be
usable for any future devices that implement this feature.

This patch should be applied after the basic G920 support patch
by Simon Wood:
http://www.spinics.net/lists/linux-input/msg42174.html

The driving supports everything that is supported by the G920
firmware:
    FF_CONSTANT
    FF_PERIODIC
    FF_SINE
    FF_SQUARE
    FF_SAW_UP
    FF_SAW_DOWN
    FF_TRIANGLE
    FF_SPRING
    FF_DAMPER
    FF_AUTOCENTER
    FF_GAIN
and for version 2 firmware also:
    FF_FRICTION
    FF_INERTIA
    FF_RAMP

Both envelopes and replay values are supported as well, but some
problems may occur when using firmware release 1. There is also a
small residual clockwise damper in the wheel when using the first
firmware release. All problems are fixed in the soon te be released
firmware version 2.

The default spring is disabled by permanently placing a spring
force in the wheel. This spring is also used as the autocenter
spring.

Note: The wheel _DOES_NOT_ auto switch to Logitech/HID mode (it is stuck
in XBox since the xpad changes where not included). Michal has an
alternative approach documented here (and the changes should be submitted
upstream to usb_modeswitch project):

===
Create a file named "046d:c261" in "/etc/usb_modeswitch.d" with the
following content:

DefaultVendor=046d
DefaultProduct=c261
MessageEndpoint=01
ResponseEndpoint=01
TargetClass=0x03
MessageContent="0f00010142"

Then run "usb_modeswitch -c /etc/modeswitch.d/046d:c291" as root and
watch the magic happen:)
===

[jkosina@suse.cz: added information about mode switching from Simon]
[jkosina@suse.cz: fixed a few stylistic issues pointed out by Simon]
[jkosina@suse.cz: fix merge conflict due to to_hid_device() changes]
Signed-off-by: NEdwin Velds <e.velds@gmail.com>
Tested-by: NElias Vanderstuyft <elias.vds@gmail.com>
Tested-by: NSimon Wood <simon@mungewell.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

to_hid_device() macro is defined in both hid-lg4ff.c and
hid-logitech-hidpp.c. So I move it to include/linux/hid.h.
Signed-off-by: NGeliang Tang <geliangtang@163.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Ensure that the G920 is not given the default deadzones.
Signed-off-by: NSimon Wood <simon@mungewell.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The G920 can adjust the amount of 'turn' it permits, this patch adds
a sysfs file 'range' to control this.
Signed-off-by: NSimon Wood <simon@mungewell.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch adds basic support for the Logitech G920 wheel when in HID
mode. This wheel 'speaks' the HID++ protocol, and therefor is driven
with hid-logitech-hidpp.

At this stage the driver only shows that it can communicate with the
wheel by outputting the name discovered over HID++.

The normal HID functions work to give input functionality using
joystick/event interface.

Note: in 'hidpp_probe()' we have to start the hardware to get packets
flowing, the same might apply in future for other devices which don't
use the unifying protocol.
Signed-off-by: NSimon Wood <simon@mungewell.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Patch add support for the 'very long' HID++ packets, which are
64 bytes in length.
Signed-off-by: NSimon Wood <simon@mungewell.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When configuring input device via input_configured callback we may
encounter errors (for example input_mt_init_slots() may fail). Instead
of continuing with half-initialized input device let's allow driver
indicate failures.
Signed-off-by: NJaikumar Ganesh <jaikumarg@android.com>
Signed-off-by: NArve Hjønnevåg <arve@android.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NNikolai Kondrashov <Nikolai.Kondrashov@redhat.com>
Acked-by: NAndrew Duggan <aduggan@synaptics.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When configuring input device via input_configured callback we may
encounter errors (for example input_mt_init_slots() may fail). Instead
of continuing with half-initialized input device let's allow driver
indicate failures.
Signed-off-by: NJaikumar Ganesh <jaikumarg@android.com>
Signed-off-by: NArve Hjønnevåg <arve@android.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NNikolai Kondrashov <Nikolai.Kondrashov@redhat.com>
Acked-by: NAndrew Duggan <aduggan@synaptics.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The Logitech K400 keyboard has an embedded touchpad which is seen as a
mouse from the OS point of view. There is a hardware shortcut to disable
tap-to-click but the setting is not remembered accross reset, annoying
some users.

We can toggle this feature from the host by using the feature 0x6010:
Touchpad FW items
Reported-by: NBALATON Zoltan <balaton@eik.bme.hu>
Tested-by: NBALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

HIDPP_QUIRK_DELAYED_INIT means two things currently:
- we want to delay the initialization process
- we do not want hid to create an input device based on the report
  descriptor.

This should actually be 2 different quirks so we can have special connect
events while still having HID creating the input for us.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>