Hi Bastien,
Can you give a try to the attached patch (it goes on top of the previous patch).
It would be great if you could play a little with mtdiag (or any other
multitouch application) and tell me if there is any problem.
Thanks,
Benjamin
On Mon, Feb 7, 2011 at 18:11, Benjamin Tissoires
<benjamin.tissoires@xxxxxxxxx> wrote:
> On Mon, Feb 7, 2011 at 18:04, Bastien Nocera <hadess@xxxxxxxxxx> wrote:
>> On Mon, 2011-02-07 at 17:51 +0100, Benjamin Tissoires wrote:
>>> Hi Bastien,
>>>
>>> On Sat, Feb 5, 2011 at 17:10, Bastien Nocera <hadess@xxxxxxxxxx> wrote:
>>> > On Wed, 2011-02-02 at 14:20 +0100, Benjamin Tissoires wrote:
>>> >> With the patch this time.... ;)
>>> >>
>>> >> On Wed, Feb 2, 2011 at 14:18, Benjamin Tissoires
>>> >> <benjamin.tissoires@xxxxxxxxx> wrote:
>>> >> > On Wed, Feb 2, 2011 at 13:42, Bastien Nocera <hadess@xxxxxxxxxx> wrote:
>>> >> >> On Tue, 2011-02-01 at 14:25 +0100, Benjamin Tissoires wrote:
>>> >> >> <snip>
>>> >> >>> First pass:
>>> >> >>> - please get the branch multitouch of jiri's tree (at
>>> >> >>> http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=shortlog;h=refs/heads/multitouch)
>>> >> >>> - then apply the attached patch (git am
>>> >> >>> 0001-hid-multitouch-Introduce-Elo-TouchSystems-2515-Intel.patch)
>>> >> >>> - get your config from your current kernel (check that hid-multitouch
>>> >> >>> is enabled as a module)
>>> >> >>> - compile, install, reboot
>>> >> >>
>>> >> >> That's where I hit a problem. It seems that the kernel on which that
>>> >> >> branch is based has broken cgroups support (it panics on startup).
>>> >> >>
>>> >> >> Would your patch, or a patchset be available to apply to the close to
>>> >> >> Linus tree Fedora rawhide kernel?
>>> >> >
>>> >> > Hi Bastien,
>>> >> >
>>> >> > Sorry for that. Attached a new version that bumps a Linus' 2.6.38-rc2
>>> >> > or 2.6.38-rc3 to Jiri's tree and applies the patch above.
>>> >> >
>>> >> > If it's still not working, I'll send you the files directly ;)
>>> >
>>> > The instructions didn't quite work (the PCI ID seems to be in
>>> > upper-case, and the tail command wasn't producing any output). I used
>>> > good ol' 'cat' instead. Attached is what it produced.
>>>
>>> oops... When you say "the PCI ID seems to be in upper-case", you means
>>> the path of the events file, or you had to modify the patch?
>>
>> The sysfs path needed upper-case, yes. I did not change the patch.
>
> ok, so my patch is clean.... yes!
>
>>
>>> >
>>> > The cursor actually follows the touch, but it seems I need to press
>>> > quite hard to make it work.
>>>
>>> Is this the same with a Windows system? I don't think we made any
>>> assumption on the pressure.
>>
>> I have no idea. I booted Windows once on this machine, when I actually
>> got it. I can certainly check there though.
>>
>>> > Touch with 2 fingers doesn't do anything
>>> > different from single finger.
>>>
>>> This is quite normal: Linux is not ready for multitouch right now ;)
>>> Only the kernel is ready. People are working on x.org' XInput 2.1 to
>>> enable multitouch in X.org, and the toolkits are following this
>>> development.
>>>
>>> If you want to give a try, you can download our mt-diagnostic software
>>> at: http://lii-enac.fr/en/architecture/linux-input/mtdiag.html .
>>
>> That's alright. I know of the efforts, I stupidly thought that this
>> would behave the same way as the MacBook touchpads (eg. give me access
>> to a right-click).
>
> You won't have the right click out of the box for now. Peter Hutterer
> submitted last week patches to enable right click simulation with long
> press. It works well for absolute device, but you need a development
> tree of Xorg... So, we will have to wait for it too. :(
>
>>
>>> >
>>> > Let me know if you want me to test anything else. I'll try not to take
>>> > as long to do the testing next time, but we were working on our first
>>> > GNOME 3 test day.
>>>
>>> Well, the device does not sends much relevant informations: we have to
>>> rebuild some informations, so the final patch will be really close to
>>> the one I sent last week. Once I made it, I'll ask you to test it
>>> before submitting it for 2.6.38 (if it's still possible).
>>
>> Sure thing. I'll look for it in my mail.
>>
>> Still interested in me trying out Windows for that "need to press hard"
>> touch?
>
> Sure, but I don't know if we will be able to solve it (I did not found
> anything in the reports descriptors that add such feature).
>
> Cheers,
> Benjamin
>
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index a721710..3b73c88 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -70,6 +70,7 @@ struct mt_class {
#define MT_CLS_DUAL_INRANGE_CONTACTID 2
#define MT_CLS_DUAL_INRANGE_CONTACTNUMBER 3
#define MT_CLS_CYPRESS 4
+#define MT_CLS_DUAL_NSMU_CONTACTID 5
/*
* these device-dependent functions determine what slot corresponds
@@ -119,6 +120,10 @@ struct mt_class mt_classes[] = {
.quirks = MT_QUIRK_NOT_SEEN_MEANS_UP |
MT_QUIRK_CYPRESS,
.maxcontacts = 10 },
+ { .name = MT_CLS_DUAL_NSMU_CONTACTID,
+ .quirks = MT_QUIRK_NOT_SEEN_MEANS_UP |
+ MT_QUIRK_SLOT_IS_CONTACTID,
+ .maxcontacts = 2 },
{ }
};
@@ -467,7 +472,7 @@ static const struct hid_device_id mt_devices[] = {
USB_DEVICE_ID_CYPRESS_TRUETOUCH) },
/* Elo TouchSystems IntelliTouch Plus panel */
- { .driver_data = MT_CLS_DEFAULT,
+ { .driver_data = MT_CLS_DUAL_NSMU_CONTACTID,
HID_USB_DEVICE(USB_VENDOR_ID_ELO,
USB_DEVICE_ID_ELO_TS2515) },
