13 Dec, 2018
1 commit
-
[ Upstream commit 0fd791841a6d67af1155a9c3de54dea51220721e ]
The Motorola/Zebra Symbol DS4308-HD is a handheld USB barcode scanner
which does not have a battery, but reports one anyway that always has
capacity 2.Let's apply the IGNORE quirk to prevent it from being treated like a
power supply so that userspaces don't get confused that this
accessory is almost out of power and warn the user that they need to charge
their wired barcode scanner.Reported here: https://bugs.chromium.org/p/chromium/issues/detail?id=804720
Signed-off-by: Benson Leung
Reviewed-by: Benjamin Tissoires
Signed-off-by: Benjamin Tissoires
Signed-off-by: Sasha Levin
24 Apr, 2018
2 commits
-
commit 2e210bbb7429cdcf1a1a3ad00c1bf98bd9bf2452 upstream.
The commit 581c4484769e ("HID: input: map digitizer battery usage")
assumed that devices having input (qas opposed to feature) report for
battery strength would report the data on their own, without the need to
be polled by the kernel; unfortunately it is not so. Many wireless mice
do not send unsolicited reports with battery strength data and have to
be polled explicitly. As a complication, stylus devices on digitizers
are not normally connected to the base and thus can not be polled - the
base can only determine battery strength in the stylus when it is in
proximity.To solve this issue, we add a special flag that tells the kernel
to avoid polling the device (and expect unsolicited reports) and set it
when report field with physical usage of digitizer stylus (HID_DG_STYLUS).
Unless this flag is set, and we have not seen the unsolicited reports,
the kernel will attempt to poll the device when userspace attempts to
read "capacity" and "state" attributes of power_supply object
corresponding to the devices battery.Fixes: 581c4484769e ("HID: input: map digitizer battery usage")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198095
Cc: stable@vger.kernel.org
Reported-and-tested-by: Martin van Es
Signed-off-by: Dmitry Torokhov
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman -
commit 3064a03b94e60388f0955fcc29f3e8a978d28f75 upstream.
Follow the change of return type u32 of hid_report_len,
fix all the types of variables those get the return value of
hid_report_len to u32, and all other code already uses u32.Cc: stable@vger.kernel.org
Signed-off-by: Aaron Ma
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman
15 Aug, 2017
1 commit
-
The power_supply subsystem tends to emit uevent every time
power_supply_changed() is called, so we should call this API only when battery
strength reported by the device is actually different from the previous
readings, otherwise we'll drown the system in uevents.Fixes: 581c4484769e ("HID: input: map digitizer battery usage")
Signed-off-by: Dmitry Torokhov
Signed-off-by: Jiri Kosina
02 Aug, 2017
2 commits
-
Manufacturers do not always populate serial number in their devices, so
let's fall back to device ID when forming the battery device name. As a
result, batteries in devices without serial number will be named like
this:hid-0018:2D1F:510E.0001-battery
(as opposed to hid--battery for the first one, and failing to create
batteries for the subsequent ones).Signed-off-by: Dmitry Torokhov
Signed-off-by: Jiri Kosina -
We already mapped battery strength reports from the generic device
control page, but we did not update capacity from input reports, nor we
mapped the battery strength report from the digitizer page, so let's
implement this now.Batteries driven by the input reports will now start in "unknown" state,
and will get updated once we receive first report containing battery
strength from the device.Signed-off-by: Dmitry Torokhov
Signed-off-by: Jiri Kosina
22 May, 2017
1 commit
-
Use a better URL for the HUTRR40 Radio HID Usages documentation and use the
HID_GD_WIRELESS_RADIO_CTLS define rather then hardcoding a check for
0x0001000c.Fixes: 61df56bef9 ("HID: Add mapping for Microsoft Win8 Wireless Radio Controls extensions")
Suggested-by: Benjamin Tissoires
Signed-off-by: Hans de Goede
Signed-off-by: Jiri Kosina
11 May, 2017
1 commit
-
Microsoft has defined some extra HUT codes for the Generic Desktop Page
for Wireless Radio controls, see:https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/airplane-mode-radio-management
https://web.archive.org/web/20170509144631/https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/airplane-mode-radio-managementI've 3 2-in-1 keyboard docks: Dell Venue Pro 11 keyboard dock,
HP pavilion x2 keyboard dock and a PEAQ C1010 keyboard dock which have
a wireless radio toggle hotkey, which uses the 0x000100c6 HUT code
defined in these extensions.This commit adds a mapping for this key, this makes the rfkill toggle
hotkey work on the Dell Venue Pro 11 and HP Pavilion X2 keyboards,
the PEAQ C1010 keyboard does generate events for the 0x000100c6 HUT
code when pressed, but the reported value is always 0.Signed-off-by: Hans de Goede
Reviewed-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
21 Mar, 2017
1 commit
-
This patch fixes an issue in drivers/hid/hid-input.c where values
outside of the logical range are not clamped when "null state" bit of
the input control is not set.This was discussed on the lists [1] and this change stems from the fact
due to the ambiguity of the HID specification it might be appropriate to
follow Microsoft's own interpretation of the specification. As noted in
Microsoft's documentation [2] in the section titled "Required HID usages
for digitizers" it is noted that values reported outside the logical
range "will be considered as invalid data and the value will be changed
to the nearest boundary value (logical min/max)."This patch fixes an issue where the (1292:4745) Innomedia INNEX
GENESIS/ATARI reports out of range values for its X and Y axis of the
DPad which, due to the null state bit being unset, are forwarded to
userspace as is. Now these values will get clamped to the logical range
before being forwarded to userspace. This device was also used to test
this patch.This patch expands on commit 3f3752705dbd ("HID: reject input outside
logical range only if null state is set").[1]: http://lkml.kernel.org/r/20170307131036.GA853@gaia.local
[2]: https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85).aspSigned-off-by: Tomasz Kramkowski
Acked-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
06 Mar, 2017
1 commit
-
This patch fixes an issue in drivers/hid/hid-input.c where USB HID
control null state flag is not checked upon rejecting inputs outside
logical minimum-maximum range. The check should be made according to USB
HID specification 1.11, section 6.2.2.5, p.31. The fix will resolve
issues with some game controllers, such as:
https://bugzilla.kernel.org/show_bug.cgi?id=68621[tk@the-tk.com: shortened and fixed spelling in commit message]
Signed-off-by: Valtteri Heikkilä
Signed-off-by: Tomasz Kramkowski
Acked-By: Benjamin Tissoires
Signed-off-by: Jiri Kosina
14 Dec, 2016
1 commit
-
…for-4.10/intel-ish', 'for-4.10/mayflash', 'for-4.10/microsoft-surface-3', 'for-4.10/multitouch', 'for-4.10/sony', 'for-4.10/udraw-ps3', 'for-4.10/upstream' and 'for-4.10/wacom/generic' into for-linus
28 Nov, 2016
1 commit
-
The purpose of HID_QUIRK_MULTI_INPUT is to have an input device per
report id. This is useful when the HID device presents several HID
collections of different device types.The current implementation of hid-input creates one input node per id per
type (input or output). This is problematic for the LEDs of a keyboard as
they are often set through an output report. The current code creates
one input node with all the keyboard keys, and one other with only the
LEDs.To solve this, we use a two-passes way:
- first, we initialize all input nodes and associate one per report id
- then, we register all the input nodesSigned-off-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
20 Oct, 2016
1 commit
-
The "Steering" usage (HID_UP_SIMULATION | 0xc8) is defined in HUT 1.12 as
follows:"A steering wheel is a single degree-of-freedom device that rotates about
an axis. The zero position is always the neutral or 'straight ahead'
position, with positive values turning clockwise and negative values
turning counterclockwise. If the Coordinate Values Wrap attribute is
set, the steering wheel can be turned past 360 degrees."The hidinput_configure_usage function canonically maps this usage to the
ABS_WHEEL axis, but hidinput_calc_abs_res does not recognize this axis
as one for which it can calculate a resolution. This effectively prevents
wheels from being assigned a proper resolution that userspace can use
to determine the precise angle of input.This commit adds ABS_WHEEL as a rotational axis to hidinput_calc_abs_res.
Signed-off-by: Jason Gerecke
Reviewed-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
07 Oct, 2016
1 commit
-
…or-4.9/intel-ish', 'for-4.9/kye-uclogic-waltop-fixes', 'for-4.9/logitech', 'for-4.9/sony', 'for-4.9/upstream' and 'for-4.9/wacom' into for-linus
19 Sep, 2016
1 commit
-
Microsoft is reusing its report descriptor again and again, and part of it
looks like this:0x05, 0x01, // Usage Page (Generic Desktop) 299
0x09, 0x80, // Usage (System Control) 301
0xa1, 0x01, // Collection (Application) 303
0x85, 0x03, // Report ID (3) 305
0x19, 0x00, // Usage Minimum (0) 307
0x29, 0xff, // Usage Maximum (255) 309
0x15, 0x00, // Logical Minimum (0) 311
0x26, 0xff, 0x00, // Logical Maximum (255) 313
0x81, 0x00, // Input (Data,Arr,Abs) 316
0xc0, // End Collection 318While there is nothing wrong in term of processing, we do however blindly
map the full usage range (it's an array) from 0x00 to 0xff, which creates
some interesting axis, like ABS_X|Y, and a bunch of ABS_MISC + n.While libinput and other stacks don't care that much (we can detect them),
joydev is very happy and attaches itself to the mouse or keyboard.The problem is that joydev now handles the device as a joystick, but given
that we have a HID array, it sets all the ABS_* values to 0. And in its
world, 0 means -32767 (minimum value), which sends spurious events to games
(think Steam).It looks like hid-microsoft tries to tackle the very same problem with its
.report_fixup callback. But fixing the report descriptor is an endless task
and is quite obfuscated.So take the hammer, and decide that if the application is meant to be
System Control, any other usage not in the System Control range should
be ignored.Link: https://bugzilla.redhat.com/show_bug.cgi?id=1325354
Link: https://bugzilla.kernel.org/show_bug.cgi?id=28912
Link: https://github.com/ValveSoftware/steam-for-linux/issues/3384
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1325354
Link: https://bugzilla.kernel.org/show_bug.cgi?id=37982Signed-off-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
05 Aug, 2016
1 commit
-
Add MIC mute key which is found on HP Business Slim Keyboard
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 23 Spd=1.5 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=03f0 ProdID=2f4a Rev=00.10
S: Manufacturer=Chicony
S: Product=HP Business Slim Keyboard
C: #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhidSigned-off-by: AceLan Kao
Signed-off-by: Jiri Kosina
14 Jan, 2016
1 commit
-
…iner-of-cleanups', 'for-4.5/core', 'for-4.5/i2c-hid', 'for-4.5/logitech', 'for-4.5/multitouch', 'for-4.5/sony', 'for-4.5/upstream' and 'for-4.5/wacom' into for-linus
18 Dec, 2015
1 commit
-
This mouse, when asked about the battery, ceases to report movements and
clicks. So just don't ask.Signed-off-by: Alexander E. Patrakov
Signed-off-by: Jiri Kosina
20 Nov, 2015
1 commit
-
The Logitech G920 uses a couple of vendor specific usage pages,
which results in incorrect number of axis/buttons being detected.This patch adds these pages to the 'ignore' list.
Reported-by: Elias Vanderstuyft
Signed-off-by: Simon Wood
Reviewed-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
06 Nov, 2015
1 commit
-
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: Jaikumar Ganesh
Signed-off-by: Arve Hjønnevåg
Reviewed-by: Benjamin Tissoires
Reviewed-by: David Herrmann
Acked-by: Nikolai Kondrashov
Acked-by: Andrew Duggan
Signed-off-by: Dmitry Torokhov
Signed-off-by: Jiri Kosina
01 Sep, 2015
1 commit
04 Aug, 2015
1 commit
-
During unbinding the driver was dereferencing a pointer to memory
already freed by power_supply_unregister().Driver was freeing its internal description of battery through pointers
stored in power_supply structure. However, because the core owns the
power supply instance, after calling power_supply_unregister() this
memory is freed and the driver cannot access these members.Fix this by storing the pointer to internal description of battery in a
local variable before calling power_supply_unregister(), so the pointer
remains valid.Signed-off-by: Krzysztof Kozlowski
Reported-by: H.J. Lu
Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")
Cc:
Reviewed-by: Dmitry Torokhov
Signed-off-by: Jiri Kosina
10 Jul, 2015
1 commit
-
We need to emit EV_SYN/SYN_REPORT between key press and release, otherwise
userspace is allowed to "swallow" the event.[jkosina@suse.com: Dmitry says that he's observing this behavior with
Plantronics headset]Signed-off-by: Dmitry Torokhov
Signed-off-by: Jiri Kosina
28 May, 2015
3 commits
-
This line is too long; split it up.
Signed-off-by: James C Boyd
Signed-off-by: Jiri Kosina -
There are too many bangs in this conditional; therefore
remove them while still maintaining the same logic.Signed-off-by: James C Boyd
Signed-off-by: Jiri Kosina -
GCC reports a -Wlogical-not-parentheses warning here; therefore
add parentheses to shut it up and to express our intent more.Signed-off-by: James C Boyd
Signed-off-by: Jiri Kosina
15 Apr, 2015
1 commit
-
Pull HID updates from Jiri Kosina:
- quite a few firmware fixes for RMI driver by Andrew Duggan
- huion and uclogic drivers have been substantially overlaping in
functionality laterly. This redundancy is fixed by hid-huion driver
being merged into hid-uclogic; work done by Benjamin Tissoires and
Nikolai Kondrashov- i2c-hid now supports ACPI GPIO interrupts; patch from Mika Westerberg
- Some of the quirks, that got separated into individual drivers, have
historically had EXPERT dependency. As HID subsystem matured (as
well as the individual drivers), this made less and less sense. This
dependency is now being removed by patch from Jean Delvare- Logitech lg4ff driver received a couple of improvements for mode
switching, by Michal Malý- multitouch driver now supports clickpads, patches by Benjamin
Tissoires and Seth Forshee- hid-sensor framework received a substantial update; namely support
for Custom and Generic pages is being added; work done by Srinivas
Pandruvada- wacom driver received substantial update; it now supports
i2c-conntected devices (Mika Westerberg), Bamboo PADs are now
properly supported (Benjamin Tissoires), much improved battery
reporting (Jason Gerecke) and pen proximity cleanups (Ping Cheng)- small assorted fixes and device ID additions
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (68 commits)
HID: sensor: Update document for custom sensor
HID: sensor: Custom and Generic sensor support
HID: debug: fix error handling in hid_debug_events_read()
Input - mt: Fix input_mt_get_slot_by_key
HID: logitech-hidpp: fix error return code
HID: wacom: Add support for Cintiq 13HD Touch
HID: logitech-hidpp: add a module parameter to keep firmware gestures
HID: usbhid: yet another mouse with ALWAYS_POLL
HID: usbhid: more mice with ALWAYS_POLL
HID: wacom: set stylus_in_proximity before checking touch_down
HID: wacom: use wacom_wac_finger_count_touches to set touch_down
HID: wacom: remove hardcoded WACOM_QUIRK_MULTI_INPUT
HID: pidff: effect can't be NULL
HID: add quirk for PIXART OEM mouse used by HP
HID: add HP OEM mouse to quirk ALWAYS_POLL
HID: wacom: ask for a in-prox report when it was missed
HID: hid-sensor-hub: Fix sparse warning
HID: hid-sensor-hub: fix attribute read for logical usage id
HID: plantronics: fix Kconfig default
HID: pidff: support more than one concurrent effect
...
24 Mar, 2015
1 commit
-
Do not call power_supply_powers() if power_supply_register() failed
earlier. This fixes possible NULL pointer dereference by
power_supply_powers() in such case.Signed-off-by: Krzysztof Kozlowski
Reported-by: Dan Carpenter
Acked-by: Jiri Kosina
Signed-off-by: Sebastian Reichel
14 Mar, 2015
2 commits
-
Change the ownership of power_supply structure from each driver
implementing the class to the power supply core.The patch changes power_supply_register() function thus all drivers
implementing power supply class are adjusted.Each driver provides the implementation of power supply. However it
should not be the owner of power supply class instance because it is
exposed by core to other subsystems with power_supply_get_by_name().
These other subsystems have no knowledge when the driver will unregister
the power supply. This leads to several issues when driver is unbound -
mostly because user of power supply accesses freed memory.Instead let the core own the instance of struct 'power_supply'. Other
users of this power supply will still access valid memory because it
will be freed when device reference count reaches 0. Currently this
means "it will leak" but power_supply_put() call in next patches will
solve it.This solves invalid memory references in following race condition
scenario:Thread 1: charger manager
Thread 2: power supply driver, used by charger managerTHREAD 1 (charger manager) THREAD 2 (power supply driver)
========================== ==============================
psy = power_supply_get_by_name()
Driver unbind, .remove
power_supply_unregister()
Device fully removed
psy->get_property()The 'get_property' call is executed in invalid context because the driver was
unbound and struct 'power_supply' memory was freed.This could be observed easily with charger manager driver (here compiled
with max17040 fuel gauge):$ cat /sys/devices/virtual/power_supply/cm-battery/capacity &
$ echo "1-0036" > /sys/bus/i2c/drivers/max17040/unbind
[ 55.725123] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 55.732584] pgd = d98d4000
[ 55.734060] [00000000] *pgd=5afa2831, *pte=00000000, *ppte=00000000
[ 55.740318] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
[ 55.746210] Modules linked in:
[ 55.749259] CPU: 1 PID: 2936 Comm: cat Tainted: G W 3.19.0-rc1-next-20141226-00048-gf79f475f3c44-dirty #1496
[ 55.760190] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 55.766270] task: d9b76f00 ti: daf54000 task.ti: daf54000
[ 55.771647] PC is at 0x0
[ 55.774182] LR is at charger_get_property+0x2f4/0x36c
[ 55.779201] pc : [] lr : [] psr: 60000013
[ 55.779201] sp : daf55e90 ip : 00000003 fp : 00000000
[ 55.790657] r10: 00000000 r9 : c06e2878 r8 : d9b26c68
[ 55.795865] r7 : dad81610 r6 : daec7410 r5 : daf55ebc r4 : 00000000
[ 55.802367] r3 : 00000000 r2 : daf55ebc r1 : 0000002a r0 : d9b26c68
[ 55.808879] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 55.815994] Control: 10c5387d Table: 598d406a DAC: 00000015
[ 55.821723] Process cat (pid: 2936, stack limit = 0xdaf54210)
[ 55.827451] Stack: (0xdaf55e90 to 0xdaf56000)
[ 55.831795] 5e80: 60000013 c01459c4 0000002a c06f8ef8
[ 55.839956] 5ea0: db651000 c06f8ef8 daebac00 c04cb668 daebac08 c0346864 00000000 c01459c4
[ 55.848115] 5ec0: d99eaa80 c06f8ef8 00000fff 00001000 db651000 c027f25c c027f240 d99eaa80
[ 55.856274] 5ee0: d9a06c00 c0146218 daf55f18 00001000 d99eaa80 db4c18c0 00000001 00000001
[ 55.864468] 5f00: daf55f80 c0144c78 c0144c54 c0107f90 00015000 d99eaab0 00000000 00000000
[ 55.872603] 5f20: 000051c7 00000000 db4c18c0 c04a9370 00015000 00001000 daf55f80 00001000
[ 55.880763] 5f40: daf54000 00015000 00000000 c00e53dc db4c18c0 c00e548c 0000000d 00008124
[ 55.888937] 5f60: 00000001 00000000 00000000 db4c18c0 db4c18c0 00001000 00015000 c00e5550
[ 55.897099] 5f80: 00000000 00000000 00001000 00001000 00015000 00000003 00000003 c000f364
[ 55.905239] 5fa0: 00000000 c000f1a0 00001000 00015000 00000003 00015000 00001000 0001333c
[ 55.913399] 5fc0: 00001000 00015000 00000003 00000003 00000002 00000000 00000000 00000000
[ 55.921560] 5fe0: 7fffe000 be999850 0000a225 b6f3c19c 60000010 00000003 00000000 00000000
[ 55.929744] [] (charger_get_property) from [] (power_supply_show_property+0x48/0x20c)
[ 55.939286] [] (power_supply_show_property) from [] (dev_attr_show+0x1c/0x48)
[ 55.948130] [] (dev_attr_show) from [] (sysfs_kf_seq_show+0x84/0x104)
[ 55.956298] [] (sysfs_kf_seq_show) from [] (kernfs_seq_show+0x24/0x28)
[ 55.964536] [] (kernfs_seq_show) from [] (seq_read+0x1b0/0x484)
[ 55.972172] [] (seq_read) from [] (__vfs_read+0x18/0x4c)
[ 55.979188] [] (__vfs_read) from [] (vfs_read+0x7c/0x100)
[ 55.986304] [] (vfs_read) from [] (SyS_read+0x40/0x8c)
[ 55.993164] [] (SyS_read) from [] (ret_fast_syscall+0x0/0x48)
[ 56.000626] Code: bad PC value
[ 56.011652] ---[ end trace 7b64343fbdae8ef1 ]---Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Bartlomiej Zolnierkiewicz[for the nvec part]
Reviewed-by: Marc Dietrich[for compal-laptop.c]
Acked-by: Darren Hart[for the mfd part]
Acked-by: Lee Jones[for the hid part]
Acked-by: Jiri Kosina[for the acpi part]
Acked-by: Rafael J. WysockiSigned-off-by: Sebastian Reichel
-
Add new structure 'power_supply_config' for holding run-time
initialization data like of_node, supplies and private driver data.The power_supply_register() function is changed so all power supply
drivers need updating.When registering the power supply this new 'power_supply_config' should be
used instead of directly initializing 'struct power_supply'. This allows
changing the ownership of power_supply structure from driver to the
power supply core in next patches.When a driver does not use of_node or supplies then it should use NULL
as config. If driver uses of_node or supplies then it should allocate
config on stack and initialize it with proper values.Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Bartlomiej Zolnierkiewicz
Acked-by: Pavel Machek[for the nvec part]
Reviewed-by: Marc Dietrich[for drivers/platform/x86/compal-laptop.c]
Reviewed-by: Darren Hart[for drivers/hid/*]
Reviewed-by: Jiri KosinaSigned-off-by: Sebastian Reichel
05 Mar, 2015
1 commit
-
Currently HID code maps usages from telephony page into BTN_0, BTN_1, etc
keys which get interpreted by mousedev and userspace as left/right/middle
button clicks, which is not really helpful.This change adds mappings for usages that have corresponding input event
definitions, and leaves the rest unmapped. This can be changed when
there are userspace consumers for more telephony usages.Signed-off-by: Dmitry Torokhov
Signed-off-by: Jiri Kosina
09 Feb, 2015
1 commit
-
…or-3.20/lenovo', 'for-3.20/logitech', 'for-3.20/rmi', 'for-3.20/upstream' and 'for-3.20/wacom' into for-linus
07 Jan, 2015
3 commits
-
The ignore check that got added in 6ce901eb61 ("HID: input: fix confusion
on conflicting mappings") needs to properly check for VARIABLE reports
as well (ARRAY reports should be ignored), otherwise legitimate keyboards
might break.Cc:
Fixes: 6ce901eb61 ("HID: input: fix confusion on conflicting mappings")
Reported-by: Fredrik Hallenberg
Reported-by: David Herrmann
Signed-off-by: Jiri Kosina -
Enabled quirks necessary for correct battery capacity reporting. Cleaned up
surrounding style.Signed-off-by: Ross Skaliotis
Signed-off-by: Jiri Kosina -
On an PC-101/103/104 keyboard (American layout) the 'Enter' key and its
neighbours look like this:+---+ +---+ +-------+
| 1 | | 2 | | 5 |
+---+ +---+ +-------+
+---+ +-----------+
| 3 | | 4 |
+---+ +-----------+On a PC-102/105 keyboard (European layout) it looks like this:
+---+ +---+ +-------+
| 1 | | 2 | | |
+---+ +---+ +-+ 4 |
+---+ +---+ | |
| 3 | | 5 | | |
+---+ +---+ +-----+(Note that the number of keys is the same, but key '5' is moved down and
the shape of key '4' is changed. Keys '1' to '3' are exactly the same.)The keys 1-4 report the same scan-code in HID in both layouts, even though
the keysym they produce is usually different depending on the XKB-keymap
used by user-space.
However, key '5' (US 'backslash'/'pipe') reports 0x31 for the upper layout
and 0x32 for the lower layout, as defined by the HID spec. This is highly
confusing as the linux-input API uses a single keycode for both.So far, this was never a problem as there never has been a keyboard with
both of those keys present at the same time. It would have to look
something like this:+---+ +---+ +-------+
| 1 | | 2 | | x31 |
+---+ +---+ +-------+
+---+ +---+ +-----+
| 3 | |x32| | 4 |
+---+ +---+ +-----+HID can represent such a keyboard, but the linux-input API cannot.
Furthermore, any user-space mapping would be confused by this and,
luckily, no-one ever produced such hardware.Now, the HID input layer fixed this mess by mapping both 0x31 and 0x32 to
the same keycode (KEY_BACKSLASH==0x2b). As only one of both physical keys
is present on a hardware, this works just fine.Lets introduce hardware-vendors into this:
------------------------------------------Unfortunately, it seems way to expensive to produce a different device for
American and European layouts. Therefore, hardware-vendors put both keys,
(0x31 and 0x32) on the same keyboard, but only one of them is hooked up
to the physical button, the other one is 'dead'.
This means, they can use the same hardware, with a different button-layout
and automatically produce the correct HID events for American *and*
European layouts. This is unproblematic for normal keyboards, as the
'dead' key will never report any KEY-DOWN events. But RollOver keyboards
send the whole matrix on each key-event, allowing n-key roll-over mode.
This means, we get a 0x31 and 0x32 event on each key-press. One of them
will always be 0, the other reports the real state. As we map both to the
same keycode, we will get spurious key-events, even though the real
key-state never changed.The easiest way would be to blacklist 'dead' keys and never handle those.
We could simply read the 'country' tag of USB devices and blacklist either
key according to the layout. But... hardware vendors... want the same
device for all countries and thus many of them set 'country' to 0 for all
devices. Meh..So we have to deal with this properly. As we cannot know which of the keys
is 'dead', we either need a heuristic and track those keys, or we simply
make use of our value-tracking for HID fields. We simply ignore HID events
for absolute data if the data didn't change. As HID tracks events on the
HID level, we haven't done the keycode translation, yet. Therefore, the
'dead' key is tracked independently of the real key, therefore, any events
on it will be ignored.This patch simply discards any HID events for absolute data if it didn't
change compared to the last report. We need to ignore relative and
buffered-byte reports for obvious reasons. But those cannot be affected by
this bug, so we're fine.Preferably, we'd do this filtering on the HID-core level. But this might
break a lot of custom drivers, if they do not follow the HID specs.
Therefore, we do this late in hid-input just before we inject it into the
input layer (which does the exact same filtering, but on the keycode
level).If this turns out to break some devices, we might have to limit filtering
to EV_KEY events. But lets try to do the Right Thing first, and properly
filter any absolute data that didn't change.This patch is tagged for 'stable' as it fixes a lot of n-key RollOver
hardware. We might wanna wait with backporting for a while, before we know
it doesn't break anything else, though.Cc:
Reported-by: Adam Goode
Reported-by: Fredrik Hallenberg
Tested-by: Fredrik Hallenberg
Signed-off-by: David Herrmann
Signed-off-by: Jiri Kosina
17 Dec, 2014
1 commit
-
Apple bluetooth wireless keyboard (sold in UK) has always reported zero
for battery strength no matter what condition the batteries are actually
in. With this patch applied (applying same quirk as other Apple
keyboards), the battery strength is now correctly reported.Signed-off-by: Karl Relton
Signed-off-by: Jiri Kosina
12 Dec, 2014
2 commits
-
… 'for-3.19/logitech', 'for-3.19/microsoft', 'for-3.19/plantronics', 'for-3.19/rmi', 'for-3.19/sony' and 'for-3.19/wacom' into for-linus
-
Conflicts:
drivers/hid/hid-input.c
02 Dec, 2014
1 commit
-
In several hid drivers it is necessary to calculate the length of an
hid_report. This patch exports the existing static function hid_report_len of
hid-core.c as an inline function in hid.hSigned-off-by: Mathieu Magnaudet
Reviewed-by: Benjamin Tissoires
Reviewed-by: David Herrmann
Signed-off-by: Jiri Kosina
29 Oct, 2014
1 commit
-
The commit which introduced TransducerSerialNumber (368c966) is missing
two crucial implementation details. Firstly, the commit does not set the
type/code/bit/max fields as expected later down the code which can cause
the driver to crash when a tablet with this usage is connected. Secondly,
the call to 'set_bit' causes MSC_PULSELED to be sent instead of the
expected MSC_SERIAL. This commit addreses both issues.Signed-off-by: Jason Gerecke
Reviewed-by: Benjamin Tissoires
Reviewed-by: Ping Cheng
Signed-off-by: Jiri Kosina