linux-kernel - [PATCH 0/7] HID: multitouch: support of hybrid finger/pen devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1361984127-912-1-git-send-email-benjamin.tissoires@redhat.com>
Date:	Wed, 27 Feb 2013 17:55:20 +0100
From:	Benjamin Tissoires <benjamin.tissoires@...hat.com>
To:	Benjamin Tissoires <benjamin.tissoires@...il.com>,
	Henrik Rydberg <rydberg@...omail.se>,
	Jiri Kosina <jkosina@...e.cz>,
	Stephane Chatty <chatty@...c.fr>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH 0/7] HID: multitouch: support of hybrid finger/pen devices

Hi guys,

Here is the support of hybrid devices presenting pen and touch at the same time.
I don't think it's possible to split the handling of the different reports by
several hid drivers unless deepest changes in the HID core subsystem.
The main problem is the control of the underlaying transport layer of the hid
device. For instance, if two drivers (let's say hid-multitouch and hid-generic)
handle the same device, and one of them is removed, then we should not call
hid_hw_stop at this point, but only when the second is also removed.

The other big problem lies with hid drivers that fix the hid report descriptors.
We can not split the hid device before we get the fix, so those drivers should
have a special behavior.

To sum up, I think does not make sense to do such deep changes, and to take such
a risk of breaking existing devices.

So the solution consists in relying inconditionaly to the quirk MULTI_INPUT for
hid-multitouch. Before registering the input device in hid-input, we can test if
it has been populated, and if not, then we simply don't register it. In order to
prevent a regression for drivers that do not fill the input device, we need to
add an other quirk.

Cheers,
Benjamin

Benjamin Tissoires (7):
  HID: input: don't register unmapped input devices
  HID: multitouch: breaks out touch handling in specific functions
  HID: multitouch: do not map usage from non used reports
  HID: multitouch: add handling for pen in dual-sensors device
  HID: multitouch: manually send sync event for pen input report
  HID: multitouch: append " Pen" to the name of the stylus input
  HID: multitouch: force BTN_STYLUS for pen devices

 drivers/hid/hid-input.c      |  77 ++++++++++++++++++++++
 drivers/hid/hid-multitouch.c | 151 ++++++++++++++++++++++++++++++++++++-------
 include/linux/hid.h          |   1 +
 3 files changed, 207 insertions(+), 22 deletions(-)

-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/