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?
--
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
