Bug 200787
|
Description
Simon Detheridge
2018-08-10 09:51:07 UTC
Created attachment 277803 [details]
output from i2cdetect -l
Created attachment 277805 [details]
lshw
Created attachment 277861 [details]
dmesg with gpio+i2c debug
I turned on gpio and i2c debugging. Here's another dmesg with this enabled, in case that helps.
Created attachment 277863 [details]
lsusb -vvv for ITE device
Also, someone suggested that my ITE USB device might be related to the touchpad. Here's the output of lsusb -vvv for that device.
That last attachment (lsusb for the ITE device) is nothing to do with the touchpad... It's the silly RGB backlight for the keyboard. I disassembled the laptop hardware and determined that the touchpad is a PCT1336QN, which is a Pixart device: http://www.pixart.com/product_data.asp?product_id=154&productclassify_id=12&productclassify2_id=50&partnumber=PCT1336QN There's a datasheet PDF there that seems very detailed, but I don't understand most of it. I found this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1526312 on the RedHat bug tracker, which describes a problem similar to mine, and how it was eventually resolved. I'm currently trying to go through the process of probing what is happening over the i2c interface on Windows, using https://github.com/bentiss/SimplePeripheralBusProbe I'm currently trying to get the probe working. If anyone has any advice or thinks I might be barking up the wrong tree, please do let me know. I managed to get two i2c traces. One from Linux and the other from Windows. The Windows trace is from when the touchpad works, and I captured it using SimplePeripheralBusProbe from the moment I enabled the i2c hid device. The Linux trace is captured from `/sys/kernel/debug/tracing/trace`, after sending '1' to `/sys/kernel/debug/tracing/events/i2c/enable`, from when I ran `modprobe i2c_hid`. From what I can see, both platforms are sending "20-00" and getting 30 bytes back, which are: 1e-00-00-01-4e-02-21-00-24-00-24-00-25-00-00-00-22-00-23-00-3a-09-36-13-4a-00-00-00-00-00 I think this is the HID descriptor. Windows is then sending "22 00 00 08" followed by "22 00 00 01", reading 36 bytes of zeros, sending "21 00" and getting a load of stuff back. Linux is then sending "22 00 00 08" followed by "22 00 00 01", but then not reading anything and carrying on sending 4-byte sequences starting with "22 00" until it times out and decides that it's been unable to reset the device. I'm not sure what to look at next. I'll attach the two traces. Created attachment 278005 [details]
i2c trace from Windows (working)
i2c trace using SimplePeripheralBusProbe on Windows (working)
Created attachment 278007 [details]
i2c trace from Linux (not working)
i2c trace from Linux (not working)
dmesg output from `modprobe i2c_hid`, corresponding to the Linux capture above: [ 1617.035630] i2c_designware i2c_designware.0: Standard-mode HCNT:LCNT = 926:1079 [ 1617.035637] i2c_designware i2c_designware.0: Fast-mode HCNT:LCNT = 191:345 [ 1617.035670] i2c_hid i2c-UNIW0001:00: probe [ 1617.035768] i2c i2c-6: master_xfer[0] R, addr=0x2c, len=1 [ 1617.035778] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 1617.035833] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 1617.035996] i2c_designware i2c_designware.0: enabled=0x1 stat=0x714 [ 1617.036059] i2c i2c-6: master_xfer[0] W, addr=0x2c, len=2 [ 1617.036064] i2c i2c-6: master_xfer[1] R, addr=0x2c, len=30 [ 1617.036070] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 2 [ 1617.036122] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 1617.036656] i2c_designware i2c_designware.0: enabled=0x1 stat=0x514 [ 1617.036744] i2c_designware i2c_designware.0: enabled=0x1 stat=0x514 [ 1617.036855] i2c_designware i2c_designware.0: enabled=0x1 stat=0x514 [ 1617.036915] i2c_designware i2c_designware.0: enabled=0x1 stat=0x514 [ 1617.037022] i2c_designware i2c_designware.0: enabled=0x1 stat=0x714 [ 1617.037087] i2c_hid i2c-UNIW0001:00: Requesting IRQ: 161 [ 1617.037296] cannonlake-pinctrl INT3450:00: pin 208 for irq (hwirq=263) [ 1617.037382] i2c i2c-6: master_xfer[0] W, addr=0x2c, len=4 [ 1617.037389] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 1617.037452] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 1617.037629] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 1617.042658] i2c i2c-6: master_xfer[0] W, addr=0x2c, len=4 [ 1617.042662] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 1617.042711] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 1617.042888] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 1622.065310] i2c_hid i2c-UNIW0001:00: failed to reset device. [ 1622.065323] i2c i2c-6: master_xfer[0] W, addr=0x2c, len=4 [ 1622.065335] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 1622.065404] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 1622.065851] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 1623.105668] i2c i2c-6: master_xfer[0] W, addr=0x2c, len=4 [ 1623.105682] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 1623.105738] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 1623.106050] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 1623.111606] i2c i2c-6: master_xfer[0] W, addr=0x2c, len=4 [ 1623.111620] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 1623.111686] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 1623.112005] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 1628.145234] i2c_hid i2c-UNIW0001:00: failed to reset device. [ 1628.145247] i2c i2c-6: master_xfer[0] W, addr=0x2c, len=4 [ 1628.145259] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 1628.145314] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 1628.145858] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 1629.185746] i2c i2c-6: master_xfer[0] W, addr=0x2c, len=4 [ 1629.185760] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 1629.185827] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 1629.186355] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 1629.191908] i2c i2c-6: master_xfer[0] W, addr=0x2c, len=4 [ 1629.191922] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 1629.191988] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 1629.192306] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 1634.225697] i2c_hid i2c-UNIW0001:00: failed to reset device. [ 1634.225710] i2c i2c-6: master_xfer[0] W, addr=0x2c, len=4 [ 1634.225723] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 1634.225788] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 1634.226327] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 1635.265679] i2c i2c-6: master_xfer[0] W, addr=0x2c, len=4 [ 1635.265693] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 1635.265771] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 1635.266299] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 1635.271741] i2c i2c-6: master_xfer[0] W, addr=0x2c, len=4 [ 1635.271755] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 1635.271821] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 1635.272139] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 1640.305626] i2c_hid i2c-UNIW0001:00: failed to reset device. [ 1640.305641] i2c i2c-6: master_xfer[0] W, addr=0x2c, len=4 [ 1640.305654] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 1640.305780] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 1640.306086] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 1641.345620] i2c_hid i2c-UNIW0001:00: can't add hid device: -61 [ 1641.345954] i2c_hid: probe of i2c-UNIW0001:00 failed with error -61 [ 1641.346029] i2c-core: driver [i2c_hid] registered Created attachment 278009 [details]
decompiled dsdt (using iasl)
Here's the decompiled dsdt (using iasl)
The touchpad seems to be referenced as 'TPAD'
Hi Simon, I spotted your thread while googling info about the specific model (I bought it recently from pc specialist). I'm not nearly as advanced as you to decompile stuff and compile custom kernels but if the kernel maintainers find it useful I can try exporting similar info from my system. Let me know, thanks. Jon, I'm puzzling a lot of this stuff out as I go so not *that* advanced! I'm hoping someone cleverer than me will show up on this bug and tell me where to go next as I'm pretty much out of ideas. I'd like to know if the patches from bug #199911 have the same effect as they do for me, but if you're not comfortable with compiling your own kernel that may have to wait for someone else to come along with the same hardware. :-) I figured out how to make i2c_hid a little more verbose, so here's an updated dmesg: [ 940.139247] i2c_designware i2c_designware.0: Standard-mode HCNT:LCNT = 926:1079 [ 940.139255] i2c_designware i2c_designware.0: Fast-mode HCNT:LCNT = 191:345 [ 940.139286] i2c_hid i2c-UNIW0001:00: probe [ 940.139391] i2c i2c-10: master_xfer[0] R, addr=0x2c, len=1 [ 940.139396] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 940.139472] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 940.139588] i2c_designware i2c_designware.0: enabled=0x1 stat=0x714 [ 940.139674] i2c_hid i2c-UNIW0001:00: Fetching the HID descriptor [ 940.139681] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: cmd=20 00 [ 940.139688] i2c i2c-10: master_xfer[0] W, addr=0x2c, len=2 [ 940.139693] i2c i2c-10: master_xfer[1] R, addr=0x2c, len=30 [ 940.139698] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 2 [ 940.139752] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 940.139974] i2c_designware i2c_designware.0: enabled=0x1 stat=0x504 [ 940.140014] i2c_designware i2c_designware.0: enabled=0x1 stat=0x504 [ 940.140072] i2c_designware i2c_designware.0: enabled=0x1 stat=0x504 [ 940.140114] i2c_designware i2c_designware.0: enabled=0x1 stat=0x504 [ 940.140173] i2c_designware i2c_designware.0: enabled=0x1 stat=0x504 [ 940.140213] i2c_designware i2c_designware.0: enabled=0x1 stat=0x504 [ 940.140252] i2c_designware i2c_designware.0: enabled=0x1 stat=0x514 [ 940.140309] i2c_designware i2c_designware.0: enabled=0x1 stat=0x514 [ 940.140349] i2c_designware i2c_designware.0: enabled=0x1 stat=0x514 [ 940.140408] i2c_designware i2c_designware.0: enabled=0x1 stat=0x514 [ 940.140448] i2c_designware i2c_designware.0: enabled=0x1 stat=0x514 [ 940.140506] i2c_designware i2c_designware.0: enabled=0x1 stat=0x514 [ 940.140546] i2c_designware i2c_designware.0: enabled=0x1 stat=0x514 [ 940.140586] i2c_designware i2c_designware.0: enabled=0x1 stat=0x514 [ 940.140643] i2c_designware i2c_designware.0: enabled=0x1 stat=0x714 [ 940.140725] i2c_hid i2c-UNIW0001:00: HID Descriptor: 1e 00 00 01 4e 02 21 00 24 00 24 00 25 00 00 00 22 00 23 00 3a 09 36 13 4a 00 00 00 00 00 [ 940.140732] i2c_hid i2c-UNIW0001:00: Requesting IRQ: 161 [ 940.140916] cannonlake-pinctrl INT3450:00: pin 208 for irq (hwirq=263) [ 940.141000] i2c_hid i2c-UNIW0001:00: entering i2c_hid_parse [ 940.141004] i2c_hid i2c-UNIW0001:00: i2c_hid_hwreset [ 940.141007] i2c_hid i2c-UNIW0001:00: i2c_hid_set_power [ 940.141011] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: cmd=22 00 00 08 [ 940.141017] i2c i2c-10: master_xfer[0] W, addr=0x2c, len=4 [ 940.141023] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 940.141077] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 940.141258] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 940.146359] i2c_hid i2c-UNIW0001:00: resetting... [ 940.146361] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: cmd=22 00 00 01 [ 940.146363] i2c i2c-10: master_xfer[0] W, addr=0x2c, len=4 [ 940.146364] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 940.146409] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 940.146579] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 940.146617] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: waiting... [ 945.201591] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: finished. [ 945.201593] i2c_hid i2c-UNIW0001:00: failed to reset device. [ 945.201594] i2c_hid i2c-UNIW0001:00: i2c_hid_set_power [ 945.201596] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: cmd=22 00 01 08 [ 945.201598] i2c i2c-10: master_xfer[0] W, addr=0x2c, len=4 [ 945.201600] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 945.201647] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 945.201835] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 946.242612] i2c_hid i2c-UNIW0001:00: i2c_hid_hwreset [ 946.242618] i2c_hid i2c-UNIW0001:00: i2c_hid_set_power [ 946.242623] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: cmd=22 00 00 08 [ 946.242631] i2c i2c-10: master_xfer[0] W, addr=0x2c, len=4 [ 946.242637] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 946.242740] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 946.242928] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 946.248485] i2c_hid i2c-UNIW0001:00: resetting... [ 946.248492] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: cmd=22 00 00 01 [ 946.248501] i2c i2c-10: master_xfer[0] W, addr=0x2c, len=4 [ 946.248508] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 946.248612] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 946.248935] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 946.249019] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: waiting... [ 951.285075] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: finished. [ 951.285077] i2c_hid i2c-UNIW0001:00: failed to reset device. [ 951.285080] i2c_hid i2c-UNIW0001:00: i2c_hid_set_power [ 951.285081] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: cmd=22 00 01 08 [ 951.285084] i2c i2c-10: master_xfer[0] W, addr=0x2c, len=4 [ 951.285088] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 951.285168] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 951.285343] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 952.325403] i2c_hid i2c-UNIW0001:00: i2c_hid_hwreset [ 952.325405] i2c_hid i2c-UNIW0001:00: i2c_hid_set_power [ 952.325407] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: cmd=22 00 00 08 [ 952.325410] i2c i2c-10: master_xfer[0] W, addr=0x2c, len=4 [ 952.325413] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 952.325494] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 952.325667] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 952.331269] i2c_hid i2c-UNIW0001:00: resetting... [ 952.331272] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: cmd=22 00 00 01 [ 952.331276] i2c i2c-10: master_xfer[0] W, addr=0x2c, len=4 [ 952.331279] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 952.331362] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 952.331758] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 952.331809] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: waiting... [ 957.368202] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: finished. [ 957.368208] i2c_hid i2c-UNIW0001:00: failed to reset device. [ 957.368213] i2c_hid i2c-UNIW0001:00: i2c_hid_set_power [ 957.368217] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: cmd=22 00 01 08 [ 957.368225] i2c i2c-10: master_xfer[0] W, addr=0x2c, len=4 [ 957.368232] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 957.368341] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 957.368530] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 958.408399] i2c_hid i2c-UNIW0001:00: i2c_hid_hwreset [ 958.408401] i2c_hid i2c-UNIW0001:00: i2c_hid_set_power [ 958.408402] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: cmd=22 00 00 08 [ 958.408404] i2c i2c-10: master_xfer[0] W, addr=0x2c, len=4 [ 958.408407] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 958.408481] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 958.408653] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 958.414307] i2c_hid i2c-UNIW0001:00: resetting... [ 958.414309] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: cmd=22 00 00 01 [ 958.414312] i2c i2c-10: master_xfer[0] W, addr=0x2c, len=4 [ 958.414315] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 958.414414] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 958.414996] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 958.415047] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: waiting... [ 963.450639] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: finished. [ 963.450641] i2c_hid i2c-UNIW0001:00: failed to reset device. [ 963.450643] i2c_hid i2c-UNIW0001:00: i2c_hid_set_power [ 963.450644] i2c_hid i2c-UNIW0001:00: __i2c_hid_command: cmd=22 00 01 08 [ 963.450647] i2c i2c-10: master_xfer[0] W, addr=0x2c, len=4 [ 963.450649] i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 1 [ 963.450695] i2c_designware i2c_designware.0: enabled=0x1 stat=0x10 [ 963.450867] i2c_designware i2c_designware.0: enabled=0x1 stat=0x710 [ 964.501160] i2c_hid i2c-UNIW0001:00: can't add hid device: -61 [ 964.501308] i2c_hid: probe of i2c-UNIW0001:00 failed with error -61 [ 964.501335] i2c-core: driver [i2c_hid] registered Apologies for spamming... I made some progress by looking through i2c-hid.c. I found that if I manually set I2C_HID_QUIRK_NO_IRQ_AFTER_RESET, I get a lot further. In fact, it now shows up as a device in `xinput`: ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Logitech Gaming Mouse G402 id=11 [slave pointer (2)] ⎜ ↳ Logitech Gaming Mouse G402 Consumer Control id=13 [slave pointer (2)] ⎜ ↳ UNIW0001:00 093A:1336 Touchpad id=16 [slave pointer (2)] However, when I touch it nothing happens. I do have an i2c trace that looks like it's got more of the stuff that the Windows one has. - It receives the full descriptor from the device. Nothing is traced when I try to use the touchpad though. I'll attach an updated trace and dmesg. Created attachment 278033 [details]
dmesg after setting I2C_HID_QUIRK_NO_IRQ_AFTER_RESET
Created attachment 278035 [details]
i2c trace after setting I2C_HID_QUIRK_NO_IRQ_AFTER_RESET
Hi Simon, I have a GK5CN6Z branded as XMG Neo with Bios N.1.03/ EC 1.29.09. I patched the Kernel according to Bug #199911. pin error fixed [ 5.084261] cannonlake-pinctrl INT3450:00: pin 208 for irq (hwirq=263) [ 5.086413] cannonlake-pinctrl INT3450:00: pin 208 for irq (hwirq=263) but no still touchpad dmesg | grep i2c_hid [ 10.212090] i2c_hid i2c-UNIW0001:00: failed to reset device. [ 16.352288] i2c_hid i2c-UNIW0001:00: failed to reset device. [ 22.499534] i2c_hid i2c-UNIW0001:00: failed to reset device. [ 28.821879] i2c_hid i2c-UNIW0001:00: failed to reset device. [ 29.938936] i2c_hid i2c-UNIW0001:00: can't add hid device: -61 [ 29.939009] i2c_hid: probe of i2c-UNIW0001:00 failed with error -61 What exactly did you do in the i2c-hid.c file ? I found the lines that included I2C_HID_QUIRK_NO_IRQ_AFTER_RESET. It looks like exceptions for certain touchpad models. Changed one of the model names to UNIW0001:00 or added a similar line with our Touchpad identifier ? i2c-hid debugging usually ends on my Laptop with the message that an error occured and because of that the device is suppressed. Don't know whether that is Bios or Suse Tumbleweed... or me being to stupid to use a hardware debugger properly. Btw thx for the work so far. Hi Simon, I've never compiled a kernel before but if there is a patch that works I'm willing to try it out. Does the patch actually work? As I said, I have the exact same model as you from the same vendor. Unfortunately I also had problems with the wifi drivers but this made it work: https://www.reddit.com/r/pop_os/comments/8k1elm/pop_os_and_killer_wireless_ac_1550_not_working/dz49xkn/ I wonder it is feasible to apply the patches in a similar fashion as above rather than recompiling the whole kernel? Thanks, Jon @Jon the patch doesn't work, it just allows the kernel to get a bit further with trying to initialise the device. I'm just debugging extra things. As Kai has confirmed the problem, I don't think that recompiling your kernel will help at this point. I didn't have trouble with the wifi but my system probably has more up-to-date tools that don't need backports. @Kai yes, I get that 'suppressed' error when turning the touchpad off and back on again using the keyboard. It's good to know that you're experiencing the same problems as me - I'm running Gentoo and configured my own kernel so it confirms that at least I'm not missing something obvious. At this point I *suspect* that the touchpad is not getting assigned an IRQ properly. What setting I2C_HID_QUIRK_NO_IRQ_AFTER_RESET does is skip a check that the device actually has an irq after resetting it. It proceeds with taking to it over i2c and getting a descriptor, but there's no working irq so it doesn't actually work. Please note that I have no real clue what I'm doing and that this is the first time I've looked at this system, and I'm not all that experienced looking at kernel code at all. Last time I did anything with irqs was adjusting jumpers on ISA cards so that my graphics card didn't share an irq with my sound card. One thing that may be worth noting: I looked at the device on Windows and it says the device is using irq 0x0400 (1024), which is does not match what it says on Linux: [ 5.086413] cannonlake-pinctrl INT3450:00: pin 208 for irq (hwirq=263) I don't know if this matters or not. I tried using the kernel-mode debugging tools on Windows to analyse the GPIO pins. When examining all of the pin banks, I only found one pin listed as active:
--- Bank [0x8] ---
msgpioclx!_GPIO_BANK_ENTRY 0xffffa183cdf9eb80 - Bank ID: 0x8
GPIO Extension: 0xffffa183cdfdc760
Pins: [0x100, 0x11f] Pin Count: 0x20
Pin Table: 0xffffa183cfda83c0
Active: Yes FState: FStateF0 Max FState: FStateF0
F1StateParameters:
TransitionLatency : 0.0us
ResidencyRequirement: 0.0us
NominalPower : 0uW
Gsiv: 0xe, Level, UnknownPolarity Irql: 0xa SyncIrql: 0xa
--- Pin [0x7] - Absolute Pin [0x107] ---
msgpioclx!_GPIO_PIN_INFORMATION_ENTRY 0xffffa183ce4bf2f0
Mode: Interrupt
Gsiv: 0x400, Mode: Level, Pol: ActiveLow
Debounce: 0, Pull Config: 3
MaskCnt: 0, ClbkCxt: 0xffffa183c9840000
This is listed as "Absolute Pin [0x107]", which is 263. Which seems to correspond to the hwirq in the line:
NT3450:00: pin 208 for irq (hwirq=263)
Pin 208 didn't seem to be listed as active.
The "Gsiv" value listed above is the irq that Windows reports the device is using (0x400) - so to my untrained eye it looks like it's using pin 263 for hwirq 1024, not 208 for 263. But maybe there's some level of abstraction on top of this...?
Created attachment 278063 [details]
windows (windbg) gpio banks/pins
I'm also affected by this, same exact model (Recoil II - GK5CN5Z). I don't think it's worth submitting again all the details given that it's an identical system (let me know if you do). Simon did an awesome job on that. I would really love to see this problem solved so I posted a $50 bounty on bountysource for anyone who solves it. It's not much but it's a start: https://www.bountysource.com/issues/62633122-touchpad-on-tong-fang-gk5cn5z Can you test ig bug #200899 has a solution for your case? No, there's no way that would work. (I tried the patch anyway.) - That's for hid-multitouch and I'm not getting anything like that far. This is much more similar to bug #199911 in that the i2c-hid device isn't getting a working IRQ so isn't coming up at all. I'm pretty sure that the problem lies with the acpi/gpio/pinctrl(-cannonlake) side of things. So I've been looking into this a little more (and updated to the latest kernel) and circling around the IRQ system. Here's what I know so far:
- Without any patches, I get a "Pin 208 cannot be used as an IRQ" error
- With the patches from bug #1999111 (skip acpi check and intel_gpio_irq_reqres) it attempts to use "pin 208 for irq (hwirq=263)" for irq 161. This then tries to reset the device, times out and ends up with "can't add hid device: -61". IRQ 161 is not there in /proc/interrupts
- If I hack my kernel to act like QUIRK_NO_IRQ_AFTER_RESET is set, it finishes setting up the device which shows up as a multitouch device, but does not work. IRQ 161 shows up in /proc/interrupts, but no amount of touchpad-mashing will generate any events (all the numbers are 0 in /proc/interrupts for that IRQ)
e.g.:
161: 0 0 0 0 0 0 0 0 0 0 0 0 intel-gpio 263 UNIW0001:00
I've tried using `libinput debug-events` and that shows up nothing.
So, I think it's that pesky irq 161 that is causing me problems. If it's any help, I've thrown some debugging stuff around and worked out that it's setting trigger type 8. I don't know what this means or if it's correct. What Windows thinks about this pin is:
Mode: Interrupt
Gsiv: 0x400, Mode: Level, Pol: ActiveLow
Debounce: 0, Pull Config: 3
MaskCnt: 0, ClbkCxt: 0xffffa183c9840000
I'm not sure how to check whether this is what Linux is trying to do or not. All I know so far is that it wants trigger mode 8. I haven't found a list of trigger modes.
So maybe:
- It's using the wrong pin number?
- It's not setting up the interrupt the right way? Right mode?
- Something I understand even less?
From what I looked at earlier, it *appears* to be speaking I2C properly.
@Simon Thanks for looking into this! I might be mistaken but overwriting the wrong pin (100 vs 79) was part of the patch submitted by Andy for issue #199911 (comment #22). This kind of makes sense since Razer Blade 15 2018 and Recoil II are based on the same Tong Fang system. BTW RBotfield has donated another $25 to the bounty of solving this bug. Hopefully more will contribute and make the fix a bit more worthwhile. :) I did notice that. I think before the patch mine was trying to use a different pin there, as well - 263 instead of 208, which it's using now. Windows is using "absolute pin" 263, but there dummy pins which means that the actual pin number is lower. I did try a cheeky if (offset == 263) offset = 208; ... as in the other patch, but it didn't do anything. I didn't really expect it to. any news about this bug? @trave5 I've been trying to do more investigation but I need some help from someone who knows about this stuff. So, no progress really. Nevertheless, I tried spraying some 'printk' statements around my kernell and will attach the dmesg result. Also, possibly more usefully, I managed to work out how to use 'xperf' on Windows to trace events/system calls. I did: - Remove the i2c controller from the task manager - start an xperf session logging anything to do with ia-LPSS(*) and hid-i2c - Rescan for device changes - Stop the xperf session. There are some familiar-looking things in there, but I'm out of my depth. Maybe this will be of use to someone. Created attachment 278557 [details]
dmesg after adding lots of 'printk's
I added a bunch of printk statements to i2c-hid and intel pinctrl, particularly focusing on interrupts. It provides more detail on the process surrounding registering the interrupt, not receiving it (there's a printk in the interrupt handler routine that doesn't show) and tearing it down again.
My kernel has the patch from the other bug applied.
Created attachment 278559 [details]
Windows LPSS+hidi2c xperf log when adding the device
Created attachment 278563 [details] Fix gpio base for GPP-E So, I have a working touchpad! ^_^ The Windows log pointed me in the right direction, in that it was trying to activate pin 7 in GPP-E, which according to pinctrl-cannonlake.c should be pin 210, not 208. Setting the gpio base for GPP-E to 256 fixes the problem, and sounds correct in that 256 is a nice round number. ;) For ref, I still needed the following patches from Bug #199911 applied as well: Skip ACPI check in pinctrl driver https://bugzilla.kernel.org/attachment.cgi?id=277217 Translation fix for gpiochip_lock_as_irq https://bugzilla.kernel.org/attachment.cgi?id=277483 Fix community ordering for H variant https://bugzilla.kernel.org/attachment.cgi?id=277553 All seems fine now... I'll submit my patch. @Simon that's awesome! Good job! Any chance you can create a backport with the driver module so that the less experienced of us who don't compile custom kernels can benefit? Not sure how much work this is though. Hopefully the patch will be accepted by the Kernel developers soon. Once the ticket is marked as resolved, don't forget to claim the bounty of this bug: https://www.bountysource.com/issues/62633122-touchpad-on-tong-fang-gk5cn5z Thanks again! Created attachment 278573 [details]
consolidated patch
This is the consolidated patch based on Andy's and Simon's changes.
I patched and compiled Kernel v4.18.8 but unfortunately the damned Nvidia 390.48 driver does not compile in the latest kernel, so I could not test it... :(
I'm trying to figure out if it's possible to create a backport of the pinctrl driver for Ubuntu 18.04's 4.15.0-34-generic kernel. Any pointers on whether this is feasible would be highly appreciated as this is the first time I mess with these things.
To try and help, I installed Ubuntu 18.04 in a VM and ran the commands below to compile a kernel... I couldn't test that it works as I'm not running it on the actual hardware, but the patches apply and it compiles so I don't see any reason why it shouldn't work. I've put the packages that I built online, so in theory you *might* just be able to install these with the dpkg command above, but otherwise I'd try the steps I've described. (I'm not sure about uploading large binaries as attachments so I've uploaded them to my webserver) http://sd.ai/ubuntu-linux/ I'm pretty sure you don't need all of those files, but you probably know which ones you need better than me as I don't use Ubuntu all that much. ... If that doesn't work for you, try building your own, like this: # Update to the latest everything, and reboot in case of any kernel updates sudo apt update sudo apt upgrade sudo reboot # Install the necessary build tools sudo apt install build-essential git libssl-dev libelf-dev gawk libudev-dev flex bison libpci-dev python asciidoc sudo apt-get build-dep linux-image-$(uname -r) # Get the kernel sources for Ubuntu (no sudo) mkdir ~/kernel cd ~/kernel git clone git://kernel.ubuntu.com/ubuntu/ubuntu-bionic.git cd ubuntu-bionic # Download and apply the patches wget -O patch1 https://bugzilla.kernel.org/attachment.cgi?id=277217 wget -O patch2 https://bugzilla.kernel.org/attachment.cgi?id=277483 wget -O patch3 https://bugzilla.kernel.org/attachment.cgi?id=277553 wget -O patch4 https://bugzilla.kernel.org/attachment.cgi?id=278563 cat patch? | patch -p1 # build the kernel - this takes a long time fakeroot debian/rules clean fakeroot debian/rules binary # This should have created some .deb packages for the new kernel in the parent directory, to install: cd .. sudo dpkg -i linux-*.deb # Then reboot sudo reboot Note: You'll probably need to do this again if you install any updates for your kernel. Make sure to remove any old .deb packages before you do that. You *should* be able to get updated code by changing to the 'ubuntu-bionic' folder that you cloned with git, and running 'git pull'. Good luck! Oh.. I needed to remove my existing kernel with sudo apt-get remove 4.15.0-34-generic to install the new one. Probably I should've bumped the version number somehow It gave me a warning when I removed the kernel, but I installed the new one so it seems fine. I'd recommend installing the linux-image*, linux-modules* and linux-headers* .deb files. @Simon Good idea, I'll try it out! I did something similar but I cloned the latest mainline kernel (and applied Ubuntu's patches) instead of cloning directly the Ubuntu repo. I went for v4.18.8 because the patches are not compatible with v4.15 (specifically the one on pinctrl-cannonlake.c). I compiled the kernel without problem but during installation I found that Nvidia's 390.48 driver does not compile with kernel 4.16 and above... There are lots of bug reports for that. Your suggestion is great because Ubuntu's v4.15 Kernel is compatible with all the patches and should also be compatible with Nvidia's drivers. Thanks a lot for your help. I'll give it a try and let you know how it went. :) @Simon The touchpad works but unfortunately there is no right click. Two finger scrolling, left click etc works fine. Do you face the same problem? At any case thanks for your help on this. I'll post my notes for the update here (based on your instructions with minor changes on packages and bumping the version): --------------- sudo apt install build-essential libssl-dev libelf-dev gawk libudev-dev flex bison libpci-dev asciidoc fakeroot kernel-wedge mkdir kernel cd kernel git clone git://kernel.ubuntu.com/ubuntu/ubuntu-bionic.git cd ubuntu-bionic nano debian.master/changelog # Change the changelog as follows. Make sure you change 34 to 034 to avoid conflicts. """ linux (4.15.0-034.37) bionic; urgency=medium """ wget -O patch1 https://bugzilla.kernel.org/attachment.cgi?id=277217 wget -O patch2 https://bugzilla.kernel.org/attachment.cgi?id=277483 wget -O patch3 https://bugzilla.kernel.org/attachment.cgi?id=277553 wget -O patch4 https://bugzilla.kernel.org/attachment.cgi?id=278563 cat patch? | patch -p1 fakeroot debian/rules clean fakeroot debian/rules binary cd .. sudo dpkg -i ./linux-headers-4.15.0-034-generic_4.15.0-034.37_amd64.deb ./linux-modules-4.15.0-034-generic_4.15.0-034.37_amd64.deb ./linux-modules-extra-4.15.0-034-generic_4.15.0-034.37_amd64.deb ./linux-image-unsigned-4.15.0-034-generic_4.15.0-034.37_amd64.deb ./linux-headers-4.15.0-034_4.15.0-034.37_all.deb ------------ To bump the version, originally I tried appending "~touchpadfix" to the version but unfortunately some script on the Ubuntu build strips it out and you end up with conflicts. Because removing the 4.15.0-34-generic can break the meta packages, I decided to monkey patch it and just append a zero infront of it. I also had to install a backport of iwlwifi for the network card. This is not related to this ticket but since other Ubuntu users might face the same issue, I post the script here: ----------- git clone https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git cd backport-iwlwifi sudo make defconfig-iwlwifi-public sed -i 's/CPTCFG_IWLMVM_VENDOR_CMDS=y/# CPTCFG_IWLMVM_VENDOR_CMDS is not set/' .config make -j4 sudo make install sudo modprobe iwlwifi ----------- Hopefully the right click will be resolved as well and your patch will be accepted on master. Again thanks a lot for your help on this. Ok this is embarrassing... The right click works fine, it's just that by default the synclient was turned RightButtonAreaLeft off... To change it run: synclient RightButtonAreaLeft=552 Or modify /usr/share/X11/xorg.conf.d/70-synaptics.conf config. Awesome! Great to know it works for you. I don't have any problems with multitouch gestures (two-finger right-click, two-finger scroll, three-finger middle-click) Is hid-multitouch loaded? I'm running a later kernel than you (and a different distro) so there could be a few things going on there. Yes, I can see the hid_multitouch module loaded on Kernel. All is working good. :) @Simon got one last question for you in case you know. Yesterday I tried fetching the compiled *.ko modules of pinctrl (7 of them) and load them manually to the kernel. I even tried replacing the standard modules in /lib/modules/kernel-version/path/to/driver. Since the version is identical it should not be an issue. That was done to avoid running on a custom compiled kernel. The system booted normally but the touchpad did not work. This kind of hints that the patch leaves outside of the pinctrl driver? Any thoughts where/how one can overwrite the necessary modules? I'm not sure I'm afraid - I don't really know how Ubuntu manages this. 'dmesg' might give you more detail, but I wouldn't be surprised if mix-and-matching binaries from different kernel builds would cause you problems... I've never tried. There's no real reason not to run the custom-compiled kernel though. It's built from the same code, with the same toolchain... Got it. it was worth asking. It's true I didn't check the dmesg but my keyboard and other inputs worked normally. And also if binary mismatch was a problem I would expect the system not to boot. Who knows! :) True about the custom kernel remark. It's just that I had to monkey patch the versioning to avoid conflicts; that's what I don't like really. Copying a bunch of compiled modules would have been a cool solution, plus you don't have to build the whole kernel which takes ages. At any case I am happy it works well now. If someone had any clue where those changes leave give us a shout! :) Hi Simon, can confirm your solution on my XMG branded Laptop. Thx for all the work. Hi Simon, Good work on this! Tried your patch and touchpad's working! A couple nvidia graphic driver issues since I'm using a different kernel version than usual (unrelated I know) but otherwise works like a charm! Don't forget to collect the bounty that myself and Vasilis placed at https://www.bountysource.com/issues/62633122-touchpad-on-tong-fang-gk5cn5z I will, thanks :) Hi Simon Thanks for you excellent work on this! I was watching but not knowing what to do to help. My system is a TongFang GK5CN6Z, which I suppose has the same touchpad component as the GK5CN5Z. I'm having trouble getting a custom kernel to boot on my Arch Linux laptop and would like to know if you can answer a few questions: (In reply to Simon Detheridge from comment #33) > So, I have a working touchpad! ^_^ > (...) > For ref, I still needed the following patches from Bug #199911 applied as > well: > > Skip ACPI check in pinctrl driver > https://bugzilla.kernel.org/attachment.cgi?id=277217 > > Translation fix for gpiochip_lock_as_irq > https://bugzilla.kernel.org/attachment.cgi?id=277483 > > Fix community ordering for H variant > https://bugzilla.kernel.org/attachment.cgi?id=277553 1) What kernel version did you test the patches with? (I've tried it with 4.18.8, but I will gladly use any other version that works) 2) What distro are you using? > > All seems fine now... I'll submit my patch. 3) Did you get it approved? How does it work, for your patches to be approved all the others must be also approved, right? Do you have any idea about the mainline version that will include the patches? Hi Simon. I can now confirm that you solution also works for the Tong Fang GK5CN6Z, with the Avell A65 or Avell 1550 branding. Note: if anyone is having a lockup during boot, it is possible that there is package missing. The patches themselves are fine. Thanks Any news about the touchpad issue? It will be released in a specific version of the Linux kernel? I've just had an email to say that the patch has been added to the stable tree, so I'm guessing it will be in 4.18.15. Just installed the latest official 4.19.0 Release Candidate v8 and it has this fix merged in there. Thanks again Simon. Awesome. :-) - Do you still need the patch from #199911 to prevent "pin cannot be used as IRQ"? On Thu, 18 Oct 2018, 21:45 , <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=200787 > > --- Comment #53 from Rhys Botfield (rhys4995@live.co.uk) --- > Just installed the latest official 4.19.0 Release Candidate v8 and it has > this > fix merged in there. Thanks again Simon. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug. Nope didn't need to do anything special. If it makes any difference I'm running Ubuntu 18.04 and just updated the kernel using UKUU, so its just a pre-compiled .deb Hi everyone, I dont know if it is related to this bug, but I installed 4.19.0 rc and the touchpad is working ok, but when computer resumes after suspend, it does not work. With 4.15 patched I dont have these problems. Is there anything I can do to help? Hi everyone, I tried multiple solutions and now that I have installed 4.19.0 kernel, but my touchpad still doesn't work. I don't know if it's because of my previous multiple attempt to solve this problem. And at this point i' m affraid that i' ll break everything. do you guys have any idea ? thanks (In reply to josevavia from comment #56) > Hi everyone, I dont know if it is related to this bug, but I installed > 4.19.0 rc and the touchpad is working ok, but when computer resumes after > suspend, it does not work. > > With 4.15 patched I dont have these problems. > > Is there anything I can do to help? I have a similar issue on kernel 4.19.11 and 4.20. After the computer resumes after suspending, the touchpad works but there is an interrupt storm. "cat /proc/interrupts" shows that intel-gpio is generating thousands of interrupts per second, and the process "irq/127-UNIW000" takes about 15% CPU constantly. Is there anything I can do to help fix this problem? I will attach /proc/interrupts and dmesg. Created attachment 280141 [details]
dmesg after resume
Created attachment 280143 [details]
/proc/interrupts after resume
Recoil II Series here - works fine for me with Ubuntu 16.04 and kernel version 4.19.19 Thanks a lot for this! I can confirm this driver works but causes complete system freeze after resume from suspend on 4.20.7-arch1-1-ARCH when running Xorg. I ended up creating a system-sleep hook that unloads the i2c_hid driver on sleep and reloads it on resume, and now it suspends/resumes perfectly. On freeze i do not get any extra output except that probing the i2c device returned a 1. If anyone can instruct me how to get some debug output out of it i will be happy to supply it. I can confirm that reloading the i2c_hid kernel module as suggested by Jay Mann also works for me to fix the interrupt storm after wakeup. I also put a systemd hook to do this automatically to temporarily work around this issue. Oh, nice catch. I've been experiencing the same thing but had been assuming that this was nvidia-driver-related as it doesn't seem to happen when I boot with just the intel gpu in use... Can anyone confirm? Anyone get pinch to zoom working in chromium or inertia scrolling? Even ctrl+scroll is not working to zoom. These features work fine with my logitech k400r wireless keyboard touchpad. Can anybody test v5.10.y and summarize if this bug is still exists? If no, I'll close this bug next week or so. |