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... ;-)
>
> --
> 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
>
--
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
