03 May, 2017
1 commit
-
Pull trivial tree updates from Jiri Kosina.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial:
tty: fix comment for __tty_alloc_driver()
init/main: properly align the multi-line comment
init/main: Fix double "the" in comment
Fix dead URLs to ftp.kernel.org
drivers: Clean up duplicated email address
treewide: Fix typo in xml/driver-api/basics.xml
tools/testing/selftests/powerpc: remove redundant CFLAGS in Makefile: "-Wall -O2 -Wall" -> "-O2 -Wall"
selftests/timers: Spelling s/privledges/privileges/
HID: picoLCD: Spelling s/REPORT_WRTIE_MEMORY/REPORT_WRITE_MEMORY/
net: phy: dp83848: Fix Typo
UBI: Fix typos
Documentation: ftrace.txt: Correct nice value of 120 priority
net: fec: Fix typo in error msg and comment
treewide: Fix typos in printk
02 May, 2017
3 commits
-
…', 'for-4.12/hid-core-null-state-handling', 'for-4.12/hiddev', 'for-4.12/i2c-hid', 'for-4.12/innomedia', 'for-4.12/logitech-hidpp-battery-power-supply', 'for-4.12/multitouch', 'for-4.12/nti', 'for-4.12/upstream' and 'for-4.12/wacom' into for-linus
26 Apr, 2017
1 commit
-
Like other switches, the Aten CS-1758 KVM switch needs a quirk to avoid
spewing errors:[12599018.071059] usb 5-2: input irq status -75 received
[12599018.079053] usb 5-2: input irq status -75 receivedSigned-off-by: Vasilis Liaskovitis
Signed-off-by: Jiri Kosina
20 Apr, 2017
1 commit
-
It apears that devices designed around Wacom's G11 chipset (e.g. Lenovo
ThinkPad Yoga 260, Lenovo ThinkPad X1 Yoga, Dell XPS 12 9250, Dell Venue
8 Pro 5855, etc.) suffer from a common issue in their HID descriptors.
The logical maximum is not updated for the "Contact Identifier" usage,
leaving it as just "1" despite these devices being capable of tracking
far more touches.Commit 60a221869803 began ignoring usages with out-of-range values,
causing problems for devices based on this chipset. Touches after
the first will have an out-of-range Contact Identifier, and ignoring
that usage will cause the kernel to incorrectly slot each finger's
events (along with all the knock-on userspace effects that entails).This commit checks for these buggy descriptors and updates the maximum
where required. Prior chipsets have used "255" as the maximum (and the
G11, at least, doesn't seem to actually use IDs outside the range of
1..CONTACTMAX) so continue using this value.Cc: stable@vger.kernel.org
Fixes: 60a221869803 ("HID: wacom: generic: add support for touchring")
Signed-off-by: Jason Gerecke
Signed-off-by: Jiri Kosina
19 Apr, 2017
1 commit
-
Because HID_DG_TOOLSERIALNUMBER doesn't first cast the value recieved from HID
to an unsigned type, sign-extension rules can cause the value of
wacom_wac->serial[0] to inadvertently wind up with all 32 of its highest bits
set if the highest bit of "value" was set.This can cause problems for Tablet PC devices which use AES sensors and the
xf86-input-wacom userspace driver. It is not uncommon for AES sensors to send a
serial number of '0' while the pen is entering or leaving proximity. The
xf86-input-wacom driver ignores events with a serial number of '0' since it
cannot match them up to an in-use tool. To ensure the xf86-input-wacom driver
does not ignore the final out-of-proximity event, the kernel does not send
MSC_SERIAL events when the value of wacom_wac->serial[0] is '0'. If the highest
bit of HID_DG_TOOLSERIALNUMBER is set by an in-prox pen which later leaves
proximity and sends a '0' for HID_DG_TOOLSERIALNUMBER, then only the lowest 32
bits of wacom_wac->serial[0] are actually cleared, causing the kernel to send
an MSC_SERIAL event. Since the 'input_event' function takes an 'int' as
argument, only those lowest (now-cleared) 32 bits of wacom_wac->serial[0] are
sent to userspace, causing xf86-input-wacom to ignore the event. If the event
was the final out-of-prox event, then xf86-input-wacom may remain in a state
where it believes the pen is in proximity and refuses to allow other devices
under its control (e.g. the touchscreen) to move the cursor.It should be noted that EMR devices and devices which use both the
HID_DG_TOOLSERIALNUMBER and WACOM_HID_WD_SERIALHI usages (in that order) would
be immune to this issue. It appears only AES devices are affected.Fixes: f85c9dc678a ("HID: wacom: generic: Support tool ID and additional tool types")
Cc: stable@vger.kernel.org
Signed-off-by: Jason Gerecke
Acked-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
13 Apr, 2017
1 commit
-
The latest USB keyboards shipped on several ASUS laptop models
(including ROG laptop models such as GL702VMK) have the keyboards
backlight controlled by the keyboard firmware.The firmware implements at least 3 different commands:
- Init command (to use when the system starts)
- Configuration command (to get keyboard status/information)
- Backlight level control (to change the level of the keyboard light)With this patch we create the usual 'asus::kbd_backlight' led class
entry to control the keyboard backlight.[jkosina@suse.cz: remove pointless cancel_work_sync() call while
handling an error in asus_kbd_register_leds(), as spotted by
Benjamin]Signed-off-by: Carlo Caione
Reviewed-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
11 Apr, 2017
1 commit
-
This reverts commit 279967a65b320d174a507498aea7d44db3fee7f4.
Multiple regressions [1] [2] [3] have been reported. The hid-rmi
support would have to fixed and redone in 4.11+.[1] http://lkml.kernel.org/r/b79b88c8-770a-13f6-5668-c3a94254e5e0@gmail.com
[2] http://lkml.kernel.org/r/375e67b5-2cb8-3491-1d71-d8650d6e9451@gmail.com
[3] https://bugzilla.kernel.org/show_bug.cgi?id=195287Reported-by: Cameron Gutman
Reported-by: Gabriele Mazzotta
Reported-by: Lorenzo J. Lucchini
Reported-by: Thorsten Leemhuis
Signed-off-by: Jiri Kosina
06 Apr, 2017
29 commits
-
These two functions awkwardly break up the otherwise-contiguous chunk of
related Intuos IRQ functions with a 500 line tangent about the operation
of the EKR. Their presence makes it difficult to read/navigate through the
the Intuos code. Since there is no dependency between these functions, it
is possible to simply move them down somewhat. This commit moves them
to be after the final Intuos IRQ function.Signed-off-by: Jason Gerecke
Signed-off-by: Jiri Kosina -
Commits d793ff8 and 4082da8 introduced two pad usages which do not
actually send pad input events. To make sure we do not post empty
pad packets, pad_input_event_flag is introduced. Turn on the flag
for real pad input events so we can synchronize them properly.Signed-off-by: Ping Cheng
Reviewed-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina -
This device has a different vendor id but responds to initialization.
Signed-off-by: Xiaolei Yu
Reviewed-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina -
err is being checked for failure each time it is being updated
so this err check is totally redundant and can be removedDetected with CoverityScan, CID#1420665 ("Logically dead code")
Signed-off-by: Colin Ian King
Reviewed-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina -
Make sure we sure register any sensor when sony_input_configured failes.
Somehow this line got lost during resolving of merge conflicts in the
motion sensor patch series and a redudant remove was added as well later
on.Signed-off-by: Roderick Colenbrander
Signed-off-by: Jiri Kosina -
By default when using bluetooth the DS4 reports data at about 1kHz,
which is quite fast especially on weak devices. We now make the
device use the USB poll interval, which is a fixed 4ms. In addition
we make the value adjustable through sysfs.The error handling in sony_input_configured is a little tricky. It
is not easy to add other goto's as not all codepaths have logic
for adding this attribute. Luckily we are setting the value for the
attribute to a default value, so we can use that to detect if we need
to remove the file.Signed-off-by: Roderick Colenbrander
Signed-off-by: Jiri Kosina -
Only set bit flags for the portions of the DS4 output report
for which we have data.Signed-off-by: Roderick Colenbrander
Signed-off-by: Jiri Kosina -
These colors are more the default colors normally used on the DS4.
The previous ones were faint and not so noticeable.Signed-off-by: Roderick Colenbrander
Signed-off-by: Jiri Kosina -
The navigation controller is a DS3 (sixaxis) with fewer physical
axes and buttons. It utilizes the same HID report as the DS3 and
thus reports axes/buttons which aren't physically present.
Currently many non-existing buttons and axes are reported, which
we are now removing.For the axes/buttons which do exist, we make the axis/button mapping
similar to the DS3.Signed-off-by: Roderick Colenbrander
Signed-off-by: Jiri Kosina -
The DS3 MAC address is reported as a unique identified when
using Bluetooth. For USB there is no unique identifier reported
yet, so use the MAC address.Signed-off-by: Roderick Colenbrander
Signed-off-by: Jiri Kosina -
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: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
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 pourcentageSigned-off-by: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
The Solar Keyboard uses a different feature to report the battery level.
Signed-off-by: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
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: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
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: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
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: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
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: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
Or the device just answers a valid feature '0'.
Signed-off-by: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
The creation of the power_supply should not be in a HID++ 2.0 specific
function.Signed-off-by: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
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: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
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: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
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: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
hidpp->name can't be null.
Only HID++ 2.0 and above device supports the query.Signed-off-by: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
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: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
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: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
Unless they are connected through unifying, they don't support it,
so remove one error in the logs.Signed-off-by: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
Simple check to add, huge improvement :)
Signed-off-by: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
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: Peter Hutterer
Signed-off-by: Bastien Nocera
Signed-off-by: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina -
Register 0xB5 should be handled specially no matter what function is
used. This allows to retrieve the serial and the Quad ID from
hid-logitech-hidpp directly.Signed-off-by: Benjamin Tissoires
Tested-by: Bastien Nocera
Signed-off-by: Jiri Kosina
30 Mar, 2017
2 commits
-
Commit 3b164a00a9fc ("HID: wacom: Cleanup unsupported device_type
for BAMBOO_PT") cleaned up Bamboo devices which our driver falsely
claimed had touch. Bamboo One Medium also does not have touch.Signed-off-by: Aaron Armstrong Skomra
Signed-off-by: Jiri Kosina -
Commit a544c619a54b ("HID: wacom: do not attempt to switch mode
while in probe") introduces delayed work for querying (setting the
mode) on all tablets. Bamboo Touch (056a:00d0) has a ghost
interface which claims to be a pen device. Though this device can
be removed, we have to set the mode on the ghost pen interface
before we remove it. After the aforementioned delay was introduced
the device was being removed before the mode setting could be
executed.Signed-off-by: Aaron Armstrong Skomra
Signed-off-by: Jiri Kosina
