linux.git/drivers/hid/wacom_sys.c, branch v4.9

HID: wacom: Augment 'oVid' and 'oPid' with heuristics for HID_GENERIC

2016-08-10T09:44:28+00:00

The 'oVid' and 'oPid' variables used by wacom_are_sibling are a hacky
solution to the problem of the driver historically having few good
heuristics to use in determining if two devices should be considered
siblings or not. While it works well enough for explicitly supported
devices, it offers no help for HID_GENERIC devices. Now that we have
a bit more information (e.g. direct/indirect) available to us though,
we should make use of it it to improve the pairing of such devices.

Signed-off-by: Jason Gerecke 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: wacom: power_supply: provide the actual model_name

2016-08-05T11:39:23+00:00

Instead of displaying a generic "tablet", now g-c-c shows a pretty
"Wacom Intuos Pro S (WL)".

Signed-off-by: Benjamin Tissoires 
Acked-by: Ping Cheng 
Signed-off-by: Jiri Kosina

HID: wacom: power_supply: remove ac information

2016-08-05T11:39:22+00:00

Looks like upowerd is ignoring this since October 2013, so there is
no need to keep this around in the kernel.
And as mentioned in 8aaa592 (linux: Ignore ACs coming from devices) in
the upower tree, "We already have enough information on the device
battery".

Signed-off-by: Benjamin Tissoires 
Acked-by: Ping Cheng 
Signed-off-by: Jiri Kosina

HID: wacom: power_supply: mark the type as USB

2016-08-05T11:39:21+00:00

When upowerd detects a new device, it tries to map this new device to
an input to guess its kind. It works OK for wired tablets when the
wireless module and its battery are attached, but not so well when
connected over wireless.
In that case, the battery is attached to the wireless HID node, not
the Pen or Pad HID node. So there is no input node as a parent of the
reported battery, which means it will be showed as a computer battery
in gnome-control-center.

If we set the power supply type to USB, upowerd has a heuristic that
detects "wacom_" in the name of the power_supply, and set the type to
tablet. So it's now clear that the reported battery of from a tablet.
(see https://cgit.freedesktop.org/upower/tree/src/linux/up-device-supply.c)

Signed-off-by: Benjamin Tissoires 
Acked-by: Ping Cheng 
Signed-off-by: Jiri Kosina

HID: wacom: leds: handle the switch of the LEDs directly in the kernel

2016-08-05T11:39:20+00:00

The EKR switches the LED directly, and there is no point in having
userspace handling the switch it self when it's easy enough to do
in the kernel.

The other benefit is that now userspace does not need to have root access
to the LED but need only to read them with user privileges.

Signed-off-by: Benjamin Tissoires 
Acked-by: Ping Cheng 
Signed-off-by: Jiri Kosina

HID: wacom: leds: actually release the LEDs on disconnect

2016-08-05T11:39:19+00:00

There is a bug (?) in devm_led_classdev_register() in which its increments
the refcount of the parent. If the parent is an input device, that means
the ref count never reaches 0 when devm_input_device_release() gets called.
This means that the LEDs and all the devres resources attached to the
input device are not released.

Manually force the release of the group so that the leds are released once
we are done using them.

Signed-off-by: Benjamin Tissoires 
Acked-by: Ping Cheng 
Signed-off-by: Jiri Kosina

HID: wacom: leds: use the ledclass instead of custom made sysfs files

2016-08-05T11:39:19+00:00

The now obsolete sysfs files for LEDs and EKRemote are kept for backward
compatibility.
Both the EKR (read-only) and the regular Cintiqs and Intuos are now
sharing the same led API.

Signed-off-by: Benjamin Tissoires 
Acked-by: Ping Cheng 
Signed-off-by: Jiri Kosina

HID: wacom: EKR: attach the power_supply on first connection

2016-08-05T11:39:19+00:00

Or Gnome complains about an empty battery.

Signed-off-by: Benjamin Tissoires 
Acked-by: Ping Cheng 
Signed-off-by: Jiri Kosina

HID: wacom: EKR: have one power_supply per remote

2016-08-05T11:39:18+00:00

Previously, all the remotes attached to the same receiver would share the
same power_supply. That's not good as the remotes will constantly change
the battery information according to their own state.

To have something generic enough, we introduce struct wacom_battery
which regroups all the information we need for a battery.

Signed-off-by: Benjamin Tissoires 
Acked-by: Ping Cheng 
Signed-off-by: Jiri Kosina

HID: wacom: EKR: allocate one input node per remote

2016-08-05T11:39:18+00:00

Thanks to devres, we can now afford to create more than one input node
without having to overload the remove/failure paths. Having one input
node per remote is something which should have been implemented from start
but the probability of having users with several remotes is quite low.
Anyway, still, better looking at the future and implement things properly.

Remote input nodes will be freed/unregistered magically as they are
created in the devres group &remote->remotes[index].

We need to open the hid node now that the remotes are dynamically
allocated.

Signed-off-by: Benjamin Tissoires 
Acked-by: Ping Cheng 
Signed-off-by: Jiri Kosina