On Sun, Feb 01, 2015 at 11:27:09AM +0800, Sebastien Bourdeauducq wrote:
> Hi,
>
> On Sunday, February 01, 2015 04:39 AM, Benjamin Tissoires wrote:
> >Mika sent a patch recently which should solve your problem.
> >Can you give a try to the following patch?
> >https://patchwork.kernel.org/patch/5709961/
>
> With this patch and IRQF_TRIGGER_LOW | IRQF_ONESHOT, I get an interrupt
> flood and the kernel disables the interrupt line. I have reverted it to
> IRQF_TRIGGER_FALLING | IRQF_ONESHOT, and the i2c_hid initialization
> completes successfully.
That shouldn't happen :-(
On all the panels I've tried, with or without GPIO, turning the
interrupt to active low works. How about Windows, have you tried if it
works there?
> The next problem is that the tablet has product ID 0x0114 and this is not
> recognized by the wacom_wac driver. I have added those entries in it:
>
> static const struct wacom_features wacom_features_0x114 =
> { "Wacom ISDv4 114", 26202, 16325, 255, 0,
> TABLETPCE, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
> ...
> #define ANY_DEVICE_WACOM(prod)
> \
> HID_DEVICE(HID_BUS_ANY, HID_GROUP_WACOM, USB_VENDOR_ID_WACOM, prod),\
> .driver_data = (kernel_ulong_t)&wacom_features_##prod
> ...
> { ANY_DEVICE_WACOM(0x114) },
>
> I am just guessing here and copied the existing entry for product ID 0x116.
> I don't know if those numbers are correct - also, should I have used the
> existing USB_DEVICE_WACOM macro instead of defining ANY_DEVICE_WACOM?
>
> After those changes, I'm able to move the mouse pointer only once (and to
> the correct position) using the stylus, after which the digitizer crashes
> and becomes inoperable until a reboot. Unloading and reloading i2c_hid
> results in a "failed to reset device" message.
>
> I have copied my DSDT entry below.
>
> Thanks,
> Sebastien
>
> Device (DIGI)
> {
> Name (_ADR, Zero) // _ADR: Address
> Name (_HID, "WCOM0008") // _HID: Hardware ID
> Name (_CID, "PNP0C50") // _CID: Compatible ID
> Name (_DDN, "Digitizer") // _DDN: DOS Device Name
> Name (_UID, One) // _UID: Unique ID
> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
> {
> Name (RBUF, ResourceTemplate ()
> {
> I2cSerialBus (0x0009, ControllerInitiated, 0x00061A80,
> AddressingMode7Bit, "\\_SB.I2C3",
> 0x00, ResourceConsumer, ,
> )
> GpioInt (Level, ActiveLow, Exclusive, PullUp, 0x0000,
> "\\_SB.GPO0", 0x00, ResourceConsumer, ,
> )
> { // Pin list
> 0x0038
> }
Yup, looks pretty much what I've seen.
Can you send output of /sys/kernel/debug/gpio when after the kernel has
disabled the interrupt?
> })
> Return (RBUF)
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
