Question about psmouse alps driver patches
I submitted normalized patches to Canonical Ubuntu in October for the alps psmouse touchpad. The thread is long and confusing at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238 Since then, I have maintained a psmouse dlkm that provides alps support for a number of new systems, primarily from Dell. Recently, I have been asked by several people to submit the patches to linux-input to merge into the upstream kernel. I am looking for advice on how to proceed. The big problems are: 1) The alps touchpads seem to be mutating relatively quickly with several unrecognized signatures appearing over the last few months after I built my patches. 2) A number of people have submitted a patch for a particular alps touchpad signature, which will need to be reconciled and rolled-up into a single driver. See the Jan 20 3-part submission by cerne...@gmail.com. His patches look good, and clean up the code a good bit, but target a touchpad signature also reverse-engineered by bgarami.f...@gmail.com. I integrated the bgarami fixes into my patches but the patches from cerne...@gmail.com are radically different. 3) I built the patches against the 3.2 kernel. My understanding is they do not even compile against the kernel head - something like 3.5.x. I feel bad submitting the patches I have. They are big and rough because several of us reverse-engineered the ALPS interfaces but did not try to figure them out. It will take a lot of merge+test work to reconcile the patch submissions for the various alps target platforms. What do you suggest I do (e.g. submit a patch for only the new protocol I can test?) -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ACPI and the psmouse alps driver
While I'm thinking of it, in the my last alps driver dkms, I put in an ACPI interface to uniquely detect the touchpad type. After spending a good couple of days figuring out the ACPI spec and this mysterious _HID (hardware id) and _CID (compatibility id) as it relates to how ALPS identifies its touchpads, I can confirm Linus' quote "ACPI is a complete design disaster in every way. But we're kind of stuck with it." Some ALPS touchpads have different _HID values. Some have the same _HID but different behavior. As far as I can tell ACPI has varying degrees of usefulness based on the h/w manufacturer. The ALPS MS Windows drivers appear to use ACPI to figure out if the touchpad is, in fact, from ALPS and then a complicated series of proprietary retrievals to figure out the behavior. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/25] HID: multitouch: add support for Nexio 42" panel
This device is the worst device I saw. It keeps TipSwitch and InRange
at 1 for fingers that are not touching the panel.
The solution is to rely on the field ContactCount, which is accurate
as the correct information are packed at the begining of the frame.
Unfortunately, CountactCount is most of the time at the end of the report.
The solution is to pick it when we have the whole report in raw_event.
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-ids.h| 3 ++
drivers/hid/hid-multitouch.c | 91
2 files changed, 78 insertions(+), 16 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index dad56aa..0935012 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -597,6 +597,9 @@
#define USB_VENDOR_ID_NEC 0x073e
#define USB_DEVICE_ID_NEC_USB_GAME_PAD 0x0301
+#define USB_VENDOR_ID_NEXIO0x1870
+#define USB_DEVICE_ID_NEXIO_MULTITOUCH_420 0x010d
+
#define USB_VENDOR_ID_NEXTWINDOW 0x1926
#define USB_DEVICE_ID_NEXTWINDOW_TOUCHSCREEN 0x0003
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 46d8136..c4acdd0 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -32,6 +32,8 @@
#include
#include
#include
+#include
+#include
#include "usbhid/usbhid.h"
@@ -54,6 +56,7 @@ MODULE_LICENSE("GPL");
#define MT_QUIRK_NO_AREA (1 << 9)
#define MT_QUIRK_IGNORE_DUPLICATES (1 << 10)
#define MT_QUIRK_HOVERING (1 << 11)
+#define MT_QUIRK_CONTACT_CNT_ACCURATE (1 << 12)
struct mt_slot {
__s32 x, y, cx, cy, p, w, h;
@@ -83,6 +86,10 @@ struct mt_device {
struct mt_class mtclass;/* our mt device class */
struct mt_fields *fields; /* temporary placeholder for storing the
multitouch fields */
+ struct hid_field *contactcount; /* the hid_field contact count that
+ will be picked in mt_raw_event */
+ __s8 contactcount_index;/* the index of the usage contact count
+ in its hid_field. */
unsigned last_field_index; /* last field index of the report */
unsigned last_slot_field; /* the last field of a slot */
__s8 inputmode; /* InputMode HID feature, -1 if non-existent */
@@ -111,6 +118,7 @@ struct mt_device {
#define MT_CLS_DUAL_INRANGE_CONTACTNUMBER 0x0007
#define MT_CLS_DUAL_NSMU_CONTACTID 0x0008
#define MT_CLS_INRANGE_CONTACTNUMBER 0x0009
+#define MT_CLS_ALWAYS_TRUE 0x000a
/* vendor specific classes */
#define MT_CLS_3M 0x0101
@@ -170,6 +178,9 @@ static struct mt_class mt_classes[] = {
{ .name = MT_CLS_INRANGE_CONTACTNUMBER,
.quirks = MT_QUIRK_VALID_IS_INRANGE |
MT_QUIRK_SLOT_IS_CONTACTNUMBER },
+ { .name = MT_CLS_ALWAYS_TRUE,
+ .quirks = MT_QUIRK_ALWAYS_VALID |
+ MT_QUIRK_CONTACT_CNT_ACCURATE },
/*
* vendor specific classes
@@ -250,6 +261,9 @@ static ssize_t mt_set_quirks(struct device *dev,
td->mtclass.quirks = val;
+ if (!td->contactcount)
+ td->mtclass.quirks &= ~MT_QUIRK_CONTACT_CNT_ACCURATE;
+
return count;
}
@@ -264,24 +278,26 @@ static struct attribute_group mt_attribute_group = {
.attrs = sysfs_attrs
};
+static int mt_find_usage_index(struct hid_field *field, struct hid_usage
*usage)
+{
+ int i;
+ for (i = 0; i < field->maxusage; i++) {
+ if (field->usage[i].hid == usage->hid)
+ return i;
+ }
+ return -1;
+}
+
static void mt_feature_mapping(struct hid_device *hdev,
struct hid_field *field, struct hid_usage *usage)
{
struct mt_device *td = hid_get_drvdata(hdev);
- int i;
switch (usage->hid) {
case HID_DG_INPUTMODE:
td->inputmode = field->report->id;
- td->inputmode_index = 0; /* has to be updated below */
-
- for (i=0; i < field->maxusage; i++) {
- if (field->usage[i].hid == usage->hid) {
- td->inputmode_index = i;
- break;
- }
- }
-
+ td->inputmode_index = mt_find_usage_index(field, usage);
+ /* inputmode_index can't be set at -1 */
break;
case HID_DG_CONTACTMAX:
td->maxcontact_report_id = field->report->id;
@@ -459,6 +475,10 @@ static int mt_input_mapping(struct hid_device *hdev,
struct hid_input *hi,
td->last_field_index = field->index;
return 1;
case HID_DG_CONTACTCOUNT:
+ td->contactcount = field;
+
[input:synaptics-rmi4 25/25] WARNING: drivers/input/built-in.o(.init.text+0x2c11): Section mismatch in reference from the function rmi_bus_init() to the function .exit.text:rmi_unregister_f01_handler(
tree: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git synaptics-rmi4 head: 6c8adf701fb9e00e16fd3aa330995c4863c4fd9a commit: 6c8adf701fb9e00e16fd3aa330995c4863c4fd9a [25/25] Input: RMI4 - correct a few function names to fix build config: make ARCH=i386 allyesconfig All warnings: >> WARNING: drivers/input/built-in.o(.init.text+0x2c11): Section mismatch in >> reference from the function rmi_bus_init() to the function >> .exit.text:rmi_unregister_f01_handler() The function __init rmi_bus_init() references a function __exit rmi_unregister_f01_handler(). This is often seen when error handling in the init function uses functionality in the exit path. The fix is often to remove the __exit annotation of rmi_unregister_f01_handler() so it may be used outside an exit section. --- 0-DAY kernel build testing backend Open Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Input: twl6040-vibra cleanups (devm_* conversion, system wq)
Hi Peter, On Thu, Jan 24, 2013 at 12:44:29PM +0100, Peter Ujfalusi wrote: > Hi Dmitry, > > On 01/14/2013 04:34 PM, Peter Ujfalusi wrote: > > Hi Dmitry, > > > > Changes since v2: > > - twl4030-vibra patches are left out (they have been applied) > > - Do not use devm_input_allocate_device() in twl6040-vibra > > Do you want me to resend this two patch for 3.9? No, I queued them for 3.9. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
