IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVD1VGAAoJEHm+PkMAQRiG7yoH/juKOQ1zbxi5M+mleDEEJtA0
RxQSojqEMWIKrWi8PNZxjENn1OZB6XOLIXOhlyAZBrmgsjO34p1DyXlZMznr/R8W
kQ2Xxs061hRtB3OuruMIqOApUrjuqsaCwgbgUS1qWmqZcoyZN4oELyZMP6OOlqv5
UUBZm8MfyXGyxrCcg39mjct3VEOhiuEcvL6SUxOC380CdSVAnyqHFPcz0JVqMUn9
9RUBs0T9cMdhb0mZ2bfXzt6AKArj63G2nXOum+VzFcvspSm2U+MPIDCuoE+ZbTPS
jqIAgG0rj1ezRyb5oeJrvlU0Yy3u/cXoMPs9+kORvpladooYNLti8ovh6qllm0I=
=d/ye
-----END PGP SIGNATURE-----
Merge tag 'v4.0-rc5' into next
Merge with the latest upstream to synchronize Synaptics changes
and bring in new infrastructure pieces.
Conflicts:
drivers/input/mouse/synaptics.c
486b908 (HID: wacom: do not send pen events before touch is up/forced out)
introduces a kernel oops when plugging a tablet without touch.
wacom->shared is null for these devices so this leads to a null pointer
exception.
Change the condition to make it clear that what we need is wacom->shared
not NULL.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
If noone listens to the input device when a tool comes in proximity,
the tablet does not send the in-prox event when a client becomes available.
That means that no events will be sent until the tool is taken out of
proximity.
In this situation, ask for the report WACOM_REPORT_INTUOSREAD which will
read the corresponding feature and generate an in-prox event.
To make some generation of hardware working, we need to unset the
quirk NO_GET set by hid-core because the interfaces are seen as "boot
mouse".
We don't schedule this read in a worker while we are in an IO interrupt.
We know that usbhid will do it asynchronously. If this is triggered by
uhid, then this is obviously a client side bug :)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Jason Gerecke <killertofu@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Since I can't change the type of hid_set_field argument 3, using __force __s32 to remove
this warning.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
For defining enumeration values like report or power status events, the
enumeration usage ids are enclosed in a logical collection. In this case we
need to match logical usage id for pending read on this usage id. For example,
in the below field, when read is requested for 0319, the report will
contain one of the status usages like 850, 851 etc. In this case the raw
event will not match 0319. So when logical collection matches, then wake
up the pending thread.
Physical(Sensor.OtherCustom)
Logical(Sensor.0319)
Application(Sensor.Sensor)
Usage(6)
Sensor.0850
Sensor.0851
Sensor.0852
Sensor.0853
Sensor.0854
Sensor.0855
Logical Minimum(1)
Logical Maximum(5)
Report Size(8)
Report Count(1)
Report Offset(24)
Flags( Array Absolute )
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This driver didn't exist until before v3.19.
Why would suddenly everybody want to build it?
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The PID driver (usbhid/hid-pidff.c) does not set the effect ID when
uploading an effect. The result is that the initial upload works but
subsequent uploads to modify effect parameters are all directed at the
last-created effect.
The targeted effect ID must be passed back to the device when effect
parameters are changed. This is done at the start of
"pidff_set_condition_report", "pidff_set_periodic_report" etc. based on
the value of "pidff->block_load[PID_EFFECT_
BLOCK_INDEX].value[0]".
This value is only ever set during pidff_request_effect_upload.
The result is stored in "pidff->pid_id[effect->id]" at the end of
pid_upload_effect, for later use. However, if an effect is modified and
re-sent then this identifier is not being copied back from
pidff->pid_id[effect->id] before sending the command to the device. The
fix is to do this at the start of pidff_upload_effect.
Signed-off-by: Jim Keir <jimkeir@oracledbadirect.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Many HID driver options are hidden unless EXPERT is set. While I
understand the idea of simplifying the kernel configuration for most
users, in practice I believe it adds more confusion than it helps.
One thing that worries me is that, in non-EXPERT mode, these drivers
will be either built-in or modular based on apparent magic. For
example, switching INPUT and HID from m to y will cause all these
drivers to be built into the kernel when they were previously built
as modules. Short of enabling EXPERT mode altogether, the user has no
control over that.
Generally I do not think tristate options should depend on !EXPERT.
Of these, 11 of 15 are currently in the hid subsystem.
The HID_LOGITECH option is even worse than the others. Sub-options
depend on it, and this causes menuconfig and friends to display the
option even though the user can't change its value. The help page for
HID_LOGITECH will not explain why the value can't be changed. It only
says, for example:
Depends on: INPUT [=y] && HID [=y]
and that leaves the user puzzled about why the option is forced to y.
You might argue that this is a Kconfig bug, but that doesn't make it
less annoying for the user.
Even worse is that some of the sub-options of HID_LOGITECH select
INPUT_FF_MEMLESS, which in turn gets out of control for the user. So,
if you set INPUT=y and HID=y (something most general purpose
distributions would do these days, as both modules would get loaded on
a vast majority of systems otherwise), and you want support for
force-feedback game controllers, you can't have that as a module, it
has to be built-in, regardless of how rare these devices are.
Of course, all this madness goes away once EXPERT is enabled, but then
the rest of the kernel configuration becomes more complex, which
totally voids the original point.
For this reason, I would like all HID device tristate options to be
displayed regardless of EXPERT being set or not. We can let the
default settings still depend on EXPERT, that's not intrusive.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
No need to retrieve the USB handle in input_mapping() when we already
do that in probe. It also allows to use the quirk without having to
add the product ID matching.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The linux kernel has supported the TiVo Slide remote control for some time, but
does not recognize the USB ID of the newer Slide Pro. This patch adds the
missing data structures so the newer remote will be recognized by the driver,
thereby allowing the TiVo, LiveTV, and Thumbs Up/Down buttons to be
mapped with a hwdb file.
Signed-off-by: Forest Wilkinson <web11.forest@tibit.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 manager
THREAD 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 : [<00000000>] lr : [<c034b0b4>] 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] [<c034b0b4>] (charger_get_property) from [<c0346864>] (power_supply_show_property+0x48/0x20c)
[ 55.939286] [<c0346864>] (power_supply_show_property) from [<c027f25c>] (dev_attr_show+0x1c/0x48)
[ 55.948130] [<c027f25c>] (dev_attr_show) from [<c0146218>] (sysfs_kf_seq_show+0x84/0x104)
[ 55.956298] [<c0146218>] (sysfs_kf_seq_show) from [<c0144c78>] (kernfs_seq_show+0x24/0x28)
[ 55.964536] [<c0144c78>] (kernfs_seq_show) from [<c0107f90>] (seq_read+0x1b0/0x484)
[ 55.972172] [<c0107f90>] (seq_read) from [<c00e53dc>] (__vfs_read+0x18/0x4c)
[ 55.979188] [<c00e53dc>] (__vfs_read) from [<c00e548c>] (vfs_read+0x7c/0x100)
[ 55.986304] [<c00e548c>] (vfs_read) from [<c00e5550>] (SyS_read+0x40/0x8c)
[ 55.993164] [<c00e5550>] (SyS_read) from [<c000f1a0>] (ret_fast_syscall+0x0/0x48)
[ 56.000626] Code: bad PC value
[ 56.011652] ---[ end trace 7b64343fbdae8ef1 ]---
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
[for the nvec part]
Reviewed-by: Marc Dietrich <marvin24@gmx.de>
[for compal-laptop.c]
Acked-by: Darren Hart <dvhart@linux.intel.com>
[for the mfd part]
Acked-by: Lee Jones <lee.jones@linaro.org>
[for the hid part]
Acked-by: Jiri Kosina <jkosina@suse.cz>
[for the acpi part]
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
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 <k.kozlowski@samsung.com>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
[for the nvec part]
Reviewed-by: Marc Dietrich <marvin24@gmx.de>
[for drivers/platform/x86/compal-laptop.c]
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
[for drivers/hid/*]
Reviewed-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
According to [1], Windows Precision Touchpad devices must supply
a button type usage in the device capabilities feature report. A
value of 0 indicates that the device contains a depressible
button (i.e. it's a click-pad) whereas a value of 1 indicates
a non-depressible button. Add support for this usage and set
INPUT_PROP_BUTTONPAD on the touchpad input device whenever a
depressible button is present.
[1] https://msdn.microsoft.com/en-us/library/windows/hardware/dn467314(v=vs.85).aspx
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Declare the POWER_SUPPLY_PROP_PRESENT property to provide userspace
with a way to determine if the battery on a wireless tablet is plugged
in. Although current wireless tablets do not explicitly report this
information, it can be inferred from other state information. In
particular, a battery is assumed to be present if any of the following
are true: a non-zero battery level reported, the battery is reported as
charging, or the tablet is operating wirelessly.
Note: The last condition above may not strictly hold for the Graphire
Wireless (it charges from a DC barrel jack instead of a USB port), but I
do not know what is reported in the no-battery condition.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The constant is not used (leftover from previous patch versions
that never got merged).
Reported-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The status packet for tablets which can use a wireless module contains a
bit that is set if the battery is charging. This bit will be 0 if either
a battery is not present or if the battery has reached full charge. Note
that the charging circuit may continue to charge the battery for a short
time after reaching "100%".
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Calls the wacom_status_irq function to report battery status for the
Intuos Pro and Intuos5 (in addition to the already-reporting Intuos
and last-generation Bamboo).
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
If a wireless adapter (which contains the charging circuitry) is
detected as being attached to the tablet then create a new battery
interface and update its status as data is reported. Also destroy the
battery if the adapter goes away.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Tablets like the Intuos, Intuos Pro, and Bamboo have a connector for an
optional wireless module that can be connected on the fly. The presence
(or absence) of this module is indicated in a status report recieved
from the tablet. This patch adds a workqueue function that will create
or destroy a power_supply object at runtime to match the current state
of the WACOM_QUIRK_BATTERY flag.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Has the 'wacom_notify_battery' function take on the job of detecting if
updating the power supply is necessary to remove multiple
nearly-identical 'if' blocks.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In addition to the touchswitch state for "Intuos", these packets are
also sent by the Intuos Pro, Intuos5, and last-generation Bamboo
tablets when using a wired connection. They contain, among other
things, information about the optional wireless module and battery
charge state (to be supported in subsuquent patches).
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Touchpads that have only one button are called clickpads and should
be advertised as such by the kernel.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In commit 08177f4 (HID: uclogic: merge hid-huion driver in hid-uclogic)
HID_HUION depends explicitely on USB_HID because it contained quite some
USB-isms.
Now that hid-uclogic is the new home of Huion tablets, we need to also
add the dependency on USB_HID to this driver.
Reported-by: Jiri Kosina <jkosina@suse.cz>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This hack is only needed for Huion tablets. It does not seem to have
any effect on the other tablets handled by this device right now, but
it's better to check for the product id sooner than discovering that
we have messed up one tablet later.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Nikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some Huion tablets present 2 HID Pen interfaces. Only one is used, so
we can drop the unused one.
Reviewed-by: Nikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
NO_EMPTY_INPUT is useful when MULTI_INPUT is set. It prevents to create
empty input nodes that user space does not know what to do with.
It does not seem to be required at the moment, this is just a preventive
patch. This check is only made during the plug of the device, so it does
not hurt to have it.
Reviewed-by: Nikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We append "Pen", "Pad", "Mouse", "Keyboard", "Consumer Control" or
"System Control" suffix to the appropriate input node to match what
the Wacom driver does and be more convenient for the user to know
which one is which.
Reviewed-by: Nikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Merge the hid-huion driver into hid-uclogic as all the devices supported
by hid-huion are in fact UC-Logic devices.
Signed-off-by: Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Based on a patch from: Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com>
Most of the tablets handled by hid-uclogic already use MULTI_INPUT.
For the ones which are not quirked in usbhid/hidquirks, they have a
custom report descriptor which contains only one report per HID
interface. For those tablets HID_QUIRK_MULTI_INPUT is transparent.
According to https://github.com/DIGImend/tablets, the only problematic
tablet currently handled by hid-uclogic is the TWHA60 v3. This tablet
presents different report descriptors from the ones currently quirked.
This is not a problem per se, given that this tablet is not supported
currently in this version (it needs the same command as a Huion to
start forwarding events).
Reviewed-by: Nikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
touch_down is a flag to indicate if there are touches on tablet
or not. Since one set of touch events may be posted over more
than one data packet/touch frame, and pen may come in proximity
while touch events are partially sent, counting all touch events
for the set reflects the actual status of touch_down.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
If pen comes in proximity while touch is down, we force touch up
before sending pen events. Otherwise, there can be unfinished
touch events compete with pen events. This idea has been fully
implemented for Tablet PCs. But other tablets that support both
pen and touch are not fully considered.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The stylus of this device works just fine out of the box.
The touch is seen by default as a mouse with relative events and some
gestures.
The wireless and the wired version have slightly different firmwares, but
the debug mode 2 on the feature 2 is common to the 2 devices. In this mode,
all the reports are emitted through the debug interface (pen, raw touch
and mouse emulation), so we have to re-route manually the events.
We keep the Pen interface as a HID_GENERIC one because it works, and only
parse the raw touches while discarding the mouse emulation & gestures.
Switching the default in raw mode allows us to have a consistent user
experience accross all the multitouch touchpads (and enable the touch part
of the devices).
Note that the buttons of this devices are reported through the touch
interface. There is no 'Pad' interface. It seemed more natural to have
the BTN_LEFT and BTN_RIGHT reported with the touch because they are
placed under the touch interface and it looks like they belong to the
touch part.
Tested-by: Josep Sanchez Ferreres <josep.sanchez.ferreres@est.fib.upc.edu>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Bamboo PAD in debug mode needs to re-route events from the debug
interface to the Pen interface. This can be easily done with
hid_input_report(), but that means that we need to keep a reference to
the various hid_devices.
There should be only one touch and one pen interface per physical tablet,
so there is no need to keep a list of hid-devices, plain pointers are
sufficient.
Tested-by: Josep Sanchez Ferreres <josep.sanchez.ferreres@est.fib.upc.edu>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
These 2 are left over from the USB dependency cleaning, so there is
no need to keep them.
[jkosina@suse.cz: fix filename]
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
A touchpad may have firmware based palm detection code enabled which
suppresses 2D data from being reported when the firmware believes a palm is
on the touchpad. This functionality is meant to be used in mouse mode without
a driver. When a driver is present, the driver can do a better job of
determining if a contact is a palm. If this gesture is enabled on a touchpad
operating in rmi mode then the firmware will not properly clear the palm detect
interrupt, causing the touchpad to interrupt indefinately. This patch disables
the palm detect gesture when the touchpad is operating in rmi mode.
Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When a finger is lifted from a Synaptics touchpad the firmware will continue
to interrupts for up to a second. These additional interrupts are know and
dribble interrupts. Since the data read from the touchpad does not change
the input subsystem only reports a single event. This makes the servicing of
dribble interrupts on Linux unnecessary. This patch simply disables dribble
interupts when configuring the touchpad.
Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The HID over I2C specification allows to have the interrupt for a HID
device to be GPIO instead of directly connected to the IO-APIC.
Add support for this so that when the driver does not find proper interrupt
number from the I2C client structure we check if it has ACPI GpioInt()
resource listed in _CRS. If it is found we convert it to an interrupt
number and use it instead.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Lenovo Thinkpad 10 has wacom digitizer connected as a I2C-HID device. Add
generic support for this.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This commit exposes in sysfs the HID country code that is stored in the country
member of hid_device structure. It identifies the country code of localized
hardware.
For example some keyboards use it to exhibit the language of the key layout. It
helps the upper layer to identify the localized hardware and setup the correct
language to use.
For USB HID devices the country code comes for the HID descriptor and for
Bluetooth HID devices it is the HIDCountryCode attribute from the SDP database.
Signed-off-by: Olivier Gay <ogay@logitech.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Microsoft Natural Wireless Ergonomic Keyboard 7000 has special My
Favorites 1..5 keys which are handled through a vendor-defined usage
page (0xff05).
Apply MS_ERGONOMY quirks handling to USB PID 0x071d (Microsoft Microsoft
2.4GHz Transceiver V1.0) so that the My Favorites 1..5 keys are reported
as KEY_F14..18 events.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=52841
Signed-off-by: Jakub Sitnicki <jsitnicki@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Current API only allows setting one offset in the field. This API
is extended to set multiple offsets in the field report.
Also update parameters in the users of this API.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some hid sensor feature report can contain more than one reports.
This API can now support receiving multiple values from the feature
report.
Also update the parameters in the users of this API.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add additional flag to read in async mode. In this mode the caller will get
reply via registered callback for capture_sample. Callbacks can be registered
using sensor_hub_register_callback function. The usage id parameter of the
capture_sample can be matched with the usage id of the requested attribute.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Section 4.2.5 of HID Sensor hub specification allows two methods
defining sensor devices.
- Each sensor device by its own collection
- A top level application collection object, including multiple
sensors.
In the first method, each sensor can be in its own sensor application
collection without a physical collection.
In the second method there is a usage id for collection type, which
is defined as an application collection, with multiple physical
collections in it. It is possible to define fusion sensor with this
and may have its own handler. If there is a callback registered
for the collection type, then forward all reports for sensors in
its collection to this handler.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Current implementation only allows one outstanding synchronous read.
This is a performance hit when user mode is requesting raw reads
of sensor attributes on multiple sensors together.
This change changes the mutex lock to per hid sensor hub device instead
of global lock. Although request to hid sensor hub is serialized, there
can be multiple outstanding read requests pending for responses via
hid reports.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
d1c7e29e8d27 (HID: i2c-hid: prevent buffer overflow in early IRQ)
changed hid_get_input() to read ihid->bufsize bytes, which can be
more than wMaxInputLength. This is the case with the Dell XPS 13
9343, and it is causing events to be missed. In some cases the
missed events are releases, which can cause the cursor to jump or
freeze, among other problems. Limit the number of bytes read to
min(wMaxInputLength, ihid->bufsize) to prevent such problems.
Fixes: d1c7e29e8d27 "HID: i2c-hid: prevent buffer overflow in early IRQ"
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
