On Wed, Jun 08, 2011 at 01:31:26PM +0200, Benjamin Tissoires wrote:
> Hi Chih-Wei and Cascardo,
>
> Sorry for coming late in the discussion, but I think I can add some ideas to it.
>
> Most of the time, when we (the multitouch guys) saw a device that
> sends ABS_Z and ABS_RX, and that the problem is worked around by
> adding the MULTI_INPUT quirk, that means to us that the device is a
> multitouch Win7 compatible one. So hid-multitouch must be able to
> handle it.
>
> Chih-Wei, if you are running android-x86 2.6.38 kernel, then removing
> the quirk should tell the generic hid layer not to handle it.
> Then adding it to the list of the devices handled by hid-multitouch
> should do the job: insert in mt_device the following
>
>
> + /* TouchPack touchscreen */
> + { .driver_data = MT_CLS_DEFAULT,
> + HID_USB_DEVICE(USB_VENDOR_ID_TOUCHPACK,
> + USB_DEVICE_ID_TOUCHPACK_RTS) },
> +
>
> For a proper kernel integration, we'll also need to add it to the
> hid_have_special_driver list in hid-core, but android-x86 kernel
> doesn't need it currently.
>
> On Wed, Jun 8, 2011 at 12:33, Chih-Wei Huang <cwhuang@xxxxxxxxxxxxxxx> wrote:
> > 2011/6/3 Thadeu Lima de Souza Cascardo <cascardo@xxxxxxxxxxxxxx>:
> >> You should use the device capabilities, like what events it does
> >> generate. If it does generate X and Y axis events, that's the right
> >> device.
> >
> > Did you mean ABS_X and ABS_Y? Actually it is.
> > The android framework detects the touch device by:
> >
> > Â Â// Is this an old style single-touch driver?
> > Â Â if (test_bit(BTN_TOUCH, key_bitmask)
> > Â Â Â Â Â Â && test_bit(ABS_X, abs_bitmask) && test_bit(ABS_Y, abs_bitmask)) {
> > Â Â Â Â device->classes |= CLASS_TOUCHSCREEN;
> > Â Â }
> >
> > However, the output of getevent -p shows
> >
> > add device 2: /dev/input/event7
> > Âname: Â Â "HID TOUCH HID Touch Panel"
> > Âevents:
> > Â ÂSYN (0000): 0000 Â0001 Â0003 Â0004
> > Â ÂKEY (0001): 0110 Â0111 Â0112
> > Â ÂABS (0003): 0000 Âvalue 1428, min 0, max 4095, fuzz 0 flat 0
> > Â Â Â Â Â Â Â Â0001 Âvalue 1066, min 0, max 4095, fuzz 0 flat 0
> > Â ÂMSC (0004): 0004
> >
> > add device 3: /dev/input/event6
> > Âname: Â Â "HID TOUCH HID Touch Panel"
> > Âevents:
> > Â ÂSYN (0000): 0000 Â0001 Â0003 Â0004
> > Â ÂKEY (0001): 0140 Â014a Â014b
> > Â ÂABS (0003): 0000 Âvalue 0, min 0, max 4095, fuzz 0 flat 0
> > Â Â Â Â Â Â Â Â0001 Âvalue 0, min 0, max 4095, fuzz 0 flat 0
> > Â ÂMSC (0004): 0004
> >
> > Only event6 supports BTN_TOUCH, so it is detected
> > as the touch device. However, that's wrong --
> > event7 is the right touch device.
> >
> > By removing the check test_bit(BTN_TOUCH, key_bitmask),
> > event7 is correctly detected and touchscreen now works.
> >
> > But I still have questions:
> >
> > * Is it intended to NOT support BTN_TOUCH in event7?
> > * Why two devices are detected by the kernel,
> > Âwhile there is only one touchscreen?
>
> That's the MULTI_INPUT quirk purpose, when the generic hid layer is
> not able to understand the report descriptors, one way to handle the
> different collections (i.e. touches) that contains the same fields is
> to split the device in several ones, one per touch.
>
> Cheers,
> Benjamin
>
> PS: Chih-Wei and Cascardo, if you need a patch instead of my awful
> English, don't hesitate to ask... ;-)
>
Thanks, Benjamin. That clarifies a lot and points what the real fix
should be for this device.
Chih-Wei, could you send us the results of your tests? I don't have the
device available right now. I could get it next week, perhaps, if my
client still gets it.
Regards,
Cascardo.
>
> >
> > --
> > Chih-Wei
> > Android-x86 project
> > http://www.android-x86.org
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-input" in
> > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at Âhttp://vger.kernel.org/majordomo-info.html
> >
Attachment:
signature.asc
Description: Digital signature
