Bug 199911
Created attachment 276785 [details]
Files collected during investigation
Investigation done by alkersan ----------------------------------- The touchpad of the Razer Blade 15 (2018) laptop is unresponsive after boot. After shallow investigation of hardware identifiers, the touchpad seems to be present the USB and I2C buses. The USB part is visible as a HID device and includes a mouse interface, but it probably handles just the keys of the laptop, including the keyboard, media/function buttons and RGB backlight programming. The detailed output of lsusb is attached. It has an ID [1532:0233] where 1532 stands for Razer Inc. and 0233 is a yet unknown device. Similarly to 0232, which Openrazer project identifies as a keybard of the previous 2017 Blade laptop (https://github.com/openrazer/openrazer/blob/master/driver/razerkbd_driver.h#L143). Thus a USB HID part is probably out of interest for now. The i2c interface is presumably responsible for the touch positioning. It's mentioned in the dmesg.log surrounded with the vdd supply and interrupt errors of the so called i2c-1A582000 device. The i2c bus tree and the i2cdetect output is attached. Another interesting detail lies in the touchpad behavior in the Windows OS. The laptop is bundled with a plenty of drivers and is fully functional from the factory. But after the clean Windows installation - touchpad is unresponsive also. The required driver to enable the touchpad is an Intel Serial IO Driver (http://drivers.razersupport.com//index.php?_m=downloads&_a=viewdownload&downloaditemid=2878&nav=0,350,765,766). It's comprised of 4 parts: GPIO, I2C, SPI and UART. Only GPIO and I2C are required for the touchpad to become responsive without reboot (INF files of these drivers are attached). Right after installation Windows detects the touchpad as an I2C HID Device and HID-Complaint touch pad (the device manager screenshots are attached). Both devices has a id 1A58:2000, appeared previosly in the kernel log. Created attachment 276789 [details]
dmesg
Created attachment 276791 [details]
i2cdetect
Created attachment 276793 [details]
i2c_hw_id
Created attachment 276795 [details]
windows_gpio2_inf
Created attachment 276797 [details]
windows_i2c_inf
Created attachment 276799 [details]
lsusb
Created attachment 276801 [details]
touchpad_hw_id
Created attachment 277029 [details]
acpi dump
Can you also attach content of /sys/kernel/debug/pinctrl/INT3450:00/pins and /sys/kernel/debug/pinctrl/INT3450:00/gpio-ranges? Created attachment 277051 [details]
pins
Created attachment 277053 [details]
gpio-ranges
added pins and gpio-ranges Created attachment 277055 [details]
Add more debugging to gpiolib-acpi.c
Can you try the attached patch and then attach dmesg again? It should print the GPIO number we get from the BIOS.
Created attachment 277057 [details]
dmesg_with gpiolib-acpi_patch
pin = 100 This pin is configured by BIOS as GPIO direct interrupt to IOAPIC (SCI mode). So, there is coupled GpioInt() and Interrupt() resources. If I read DSDT correctly the IRQ resource, which must be used, depends on the setting of some internal variable. My understanding that, since the pin is configured to generate SCI, the driver should respect BIOS settings. Okay, more investigation on the message "flag is output". It seems that in the driver we missed the fact of IRQ to pin translation in one case. That's why we are actually talking to hadrware pin 100 (ACPI 129) instead of pin 79 (ACPI 100). And that pin is indeed configured as output. But I need to confirm this, because it's early morning and I even managed to send a patch to mailing list (related to this, but not fixing) with a completely wrong commit message. Need some sleep for sure. Take the bug as it seems to be related to our GPIO/pinctrl driver. Let me know if you need me to try out anything. (In reply to jamir from comment #21) > Let me know if you need me to try out anything. Can you add to the top of gpiochip_lock_as_irq() the following hack and try to boot again (we need dmesg with 'ignore_loglevel' added to the kernel command line): if (offset == 100) offset = 79; Created attachment 277159 [details]
dmesg with overriding pin 100 with 79
the touchpad is still not functional I have attached the dmesg after the change. The error code is different this time though - i2c_hid: probe of i2c-1A582000:00 failed with error -1 instead of -22 Created attachment 277217 [details]
Skip ACPI check in pintctrl driver
Can you try the attached patch and see if anything changes? Then attach dmesg again.
Created attachment 277227 [details]
dmesg_skip_acpi_check_pinctrl
(In reply to jamir from comment #27) > Created attachment 277227 [details] > dmesg_skip_acpi_check_pinctrl Thanks, it looks like we missed to ask you to apply both - patch from comment #22, AND - patch from comment #26 together and try. Sorry it takes more effort than we assumed. gpiochip_lock_as_irq() doesn't exist in gpiolib-acpi.c anymore on rc3. Do you know where this function moved to? I see a call from the gpiolib-acpi. found it I think its in gpiolib.c Created attachment 277229 [details]
dmesg with 22 and 26 - works
Wow, the touchpad is working!!!
Touchpad mouse movement functional.
Touchpad left mouse button functional.
Touchpad right mouse button functional.
Touchpad 2 finger scroll functional.
Touchpad tap to click, not functional, don't see a setting on gnome settings to enable that.
There are two issues at once that’s why two hacks. But to see picture better, can you please attach cat /proc/interrupt output after just boot, and after a bit so events, like touching, doing some gestures? Also attach a pins file again with driver loaded. All above from _working_ case, thanks! Can these patches be backported to 4.17 or are there other things in 4.18 that are necessary for the fix? Created attachment 277261 [details]
Interrupts after boot
Created attachment 277263 [details]
Interrupts after mouse events
Created attachment 277265 [details]
Pins with driver loaded
(In reply to Andy Shevchenko from comment #32) > There are two issues at once that’s why two hacks. But to see picture > better, can you please attach cat /proc/interrupt output after just boot, > and after a bit so events, like touching, doing some gestures? > Also attach a pins file again with driver loaded. > > All above from _working_ case, thanks! done. More observations: I see lockups sometimes when restarting just before X starts (I have seen it now 4 times). I have to hold the power button and reboot and then the next time it detects the touchpad fine. When it is locks up I see "supply vdd not found, using dummy regulator" message. When I enable wayland in GDM (custom.conf) and gnome shell I see the option "tap to click" and enabling it enables the tap to click. I was xorg for two reasons mutter/clutter caps the refresh rate to 60. and open broadcasting app doesn't record wayland composited desktop (shows black screen). one more data point. The lockup only seems to occur when I reboot the laptop. If I shutdown and power it back on I've been able to successfully start the OS like 7 times in a row without lockup. So I think the touchpad locking is most likely not related and for that you should file another bugzilla entry.
Regarding the touchpad interrupt via GPIO we have two issues:
- BIOS has configured the pin incorrectly to be owned by ACPI. Regardless it
seems that we can just skip checking for that bit in Linux driver as well
because interrupts still work (we may want to log something to dmesg about
this, though).
- We do not map hwirq correctly in gpiochip_lock_as_irq() when
get_direction() is called.
We will work a proper fix for the two but it may take some time as I will be on vacation next 3 weeks.
Sounds good. Summon Hans WRT https://bugzilla.redhat.com/show_bug.cgi?id=1543769#c117 Created attachment 277483 [details] Translation fix for gpiochip_lock_as_irq() @jamir, can you, please, test this patch instead of one in comment #22 (you still need another one from comment #26!)? Created attachment 277485 [details]
dmesg after translation fix
The touchpad is functional after the translation fix.
dmesg captured with only patch applied to the pinctrl-intel.c.
Started with a clean tree without the below hack.
if (offset == 100)
offset = 79;
Let me understand, you applied the only translation patch _without_ one from comment #26 and everything still works? I applied the translation and skipping ACPI check both. Just to be sure. You only have one patch applied and it is the translation from from Andy in comment #43? You don't have the patch in comment #26 applied? Created attachment 277507 [details]
Patch file used to test.
I am attaching the patch file I used to test.
(In reply to jamir from comment #48) > Created attachment 277507 [details] > Patch file used to test. > > I am attaching the patch file I used to test. Thanks for your patience! Now it's clear. The translation patch has been sent to upstream today (we expect maintainer take it soon). The ACPI hack needs to be thought about a bit longer. We are waiting for some elaboration internally from other team. Hello Andy Shevchenko said in a thread on redhat bugtracker that this could maybe also the solution for my problem: The Hardware is different: ASUS GL703GE Laptop if you need more data i will be pleased to submit logfiles or whatever needet. i could also open a teamviewer session or something like that if this helps resolving the problem on my hardware. in windows and bios the touchpad works but not on linux, not on debian, not on fedora, not on ubuntu... (In reply to Marc Landolt from comment #50) > if you need more data i will be pleased to submit logfiles or whatever > needet. Provide the same set of data we asked from @jamir, i.e. gpio-ranges, pins, and /proc/interrupts files. Meanwhile try to apply just one patch @jamir attached in comment #48. Created attachment 277509 [details]
Hardware ID
Created attachment 277511 [details]
dmesg from ASUS GL703GE
with modifications
Created attachment 277513 [details]
dmesg from ASUS GL703GE
without modifications
Created attachment 277515 [details]
i2cdetect from ASUS GL703GE
how to generate the gpio-ranges file? Created attachment 277517 [details]
/proc/interrupts from ASUS GL703GE
Created attachment 277519 [details]
inteltool from ASUS GL703GE
(In reply to Marc Landolt from comment #56) > how to generate the gpio-ranges file? It’s under /sys/kernel/debug/pinctrl/INT3450:00/ There also most important one called pins. You need to mount debugged before looking for them. Created attachment 277527 [details]
gpio pins from GL703GE
Created attachment 277529 [details]
gpio ranges from GL703GE
the 4.18.rc6 with the patch you said is compiled now, boots but no touchpad [ 13.206001] idma64 idma64.0: Found Intel integrated DMA 64-bit [ 13.209068] cannonlake-pinctrl INT3450:00: pin 225 for irq (hwirq=297) [ 13.209126] i2c_hid i2c-ELAN1200:00: i2c-ELAN1200:00 supply vdd not found, using dummy regulator [ 13.210398] gpio gpiochip0: (INT3450:00): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ [ 13.210424] cannonlake-pinctrl INT3450:00: unable to lock HW IRQ 225 for IRQ [ 13.210440] genirq: Failed to request resources for ELAN1200:00 (irq 138) on irqchip intel-gpio [ 13.210468] i2c_hid i2c-ELAN1200:00: Could not register for ELAN1200:00 interrupt, irq = 138, ret = -22 [ 13.210486] i2c_hid: probe of i2c-ELAN1200:00 failed with error -22 [ 13.212565] mei_me 0000:00:16.0: enabling device (0000 -> 0002) (In reply to Marc Landolt from comment #62) > the 4.18.rc6 with the patch you said is compiled now, boots but no touchpad > > [ 13.206001] idma64 idma64.0: Found Intel integrated DMA 64-bit > [ 13.209068] cannonlake-pinctrl INT3450:00: pin 225 for irq (hwirq=297) > [ 13.209126] i2c_hid i2c-ELAN1200:00: i2c-ELAN1200:00 supply vdd not > found, using dummy regulator > [ 13.210398] gpio gpiochip0: (INT3450:00): gpiochip_lock_as_irq: tried to > flag a GPIO set as output for IRQ > [ 13.210424] cannonlake-pinctrl INT3450:00: unable to lock HW IRQ 225 for > IRQ > [ 13.210440] genirq: Failed to request resources for ELAN1200:00 (irq 138) > on irqchip intel-gpio > [ 13.210468] i2c_hid i2c-ELAN1200:00: Could not register for ELAN1200:00 > interrupt, irq = 138, ret = -22 > [ 13.210486] i2c_hid: probe of i2c-ELAN1200:00 failed with error -22 > [ 13.212565] mei_me 0000:00:16.0: enabling device (0000 -> 0002) Thanks. What we need is the output file of `acpidump -o table.dat` and output of the command `grep -H 15 /sys/bus/acpi/devices/*/status`. Also, please, check BIOS settings: if anything has choice between linux and windows, choose windows. Created attachment 277531 [details]
acpidump -o table.dat from GL703GE
Created attachment 277533 [details]
grep -H 15 /sys/bus/acpi/devices/*/status from GL703GE
Created attachment 277553 [details]
Fix community ordering for H variant
Another patch for Cannonlake PCH-H.
(In reply to Marc Landolt from comment #64) > Created attachment 277531 [details] > acpidump -o table.dat from GL703GE Thanks, that is helpful. Can you test another patch from comment #66 (on top of the one from comment #48) and share the - output of `cat /proc/interrupts /proc/iomem` - *gpio-ranges* and *pins* files ? @jamir, if you can test that patch as well to see it doesn't break your case. Thanks! (In reply to Andy Shevchenko from comment #66) > Created attachment 277553 [details] > Fix community ordering for H variant > > Another patch for Cannonlake PCH-H. Yay, GREAT, Andy you're a Genius, the Touchpad is working :) After Downloading Kernel 4.18.RC6, patching with https://bugzilla.kernel.org/attachment.cgi?id=277507&action=diff and https://bugzilla.kernel.org/attachment.cgi?id=277553&action=diff it's working. -Tap to click works -2 Finger scroll works (only Natural Scrolling, always on) -2 Finger right click works -left mouse button works -right mouse button does not work but with 2 finger click it works -Edge Scrolling does not work -it disconects from time to time (rmmod -r hid-multitouch && modprobe hid-multitouch helps) shall I test other patches and do you still need the outputs from Comment 67 (interrupts, iomem, ranges, pins? With kind regards and many thanks so far Marc Landolt (In reply to Marc Landolt from comment #68) > (In reply to Andy Shevchenko from comment #66) > > Created attachment 277553 [details] > > Fix community ordering for H variant > > > > Another patch for Cannonlake PCH-H. > > Yay, GREAT, Andy you're a Genius, the Touchpad is working :) Sorry it wasn't working from the day 1. > shall I test other patches Nothing to test for now. There are three problems in your case and one of them doesn't clear yet (in a sense of root cause). That's, we are discussing internally and will come up with workaround / solution later on. > and do you still need the outputs from Comment 67 > (interrupts, iomem, ranges, pins? Yes, please. Created attachment 277555 [details]
Interrupts after working patch from ASUS GL703GE
Created attachment 277557 [details]
iomem after working patch from ASUS GL703GE
Created attachment 277559 [details]
gpio-pins after working patch from ASUS GL703GE
Created attachment 277561 [details]
gpio-ranges after working patch from ASUS GL703GE
There are still some issues, I guess it are the same issues that are also on the GL503VS and maybe in a different part of the kernel (not sure): Problems: -random lockups -disconnection (workaround rmmod && insmod hid-multitouch) -the physical button (the whole touchpad) is not debounced, if you click once it does multiple clicks (workaround: use tap to click) False Acused Problems: -non-natural 2 finger scrolling works after reboot please tell me if i shall test other things on my GL703GE... (In reply to Marc Landolt from comment #74) > please tell me if i shall test other things on my GL703GE... Marc, this bug is solely about GPIO issue. As Mika stated in comment #40, please create another one, or find if it's already created against HID subsystem. Check what @jamir has, it perhaps similar to what you are esperiencing. ok, I did not find jamir's but so I opened one here: https://bugzilla.kernel.org/show_bug.cgi?id=200663 thank you for your help :) (In reply to Andy Shevchenko from comment #49) > (In reply to jamir from comment #48) > > Created attachment 277507 [details] > > Patch file used to test. > > > > I am attaching the patch file I used to test. > > Thanks for your patience! Now it's clear. > > The translation patch has been sent to upstream today (we expect maintainer > take it soon). The ACPI hack needs to be thought about a bit longer. We are > waiting for some elaboration internally from other team. This patch also fixes the touchscreen (and pen) and touchpad (only works after a hibernation) on the newly released hp zbook studio x360 I have an almost-identical problem with a Tong Fang GK5CN5Z laptop (branded as a PC Specialist Recoil II) The symptoms appear very similar, but using the patches here the touchpad still does not work, although the error message changes. I got a very similar "cannonlake-pinctrl" "pin x cannot be used as IRQ" message. I installed 4.18_rc8 and applied the patches here, but I now get a different error and the device still does not show up. I see: [ 6.813578] usbhid 1-6:1.0: couldn't find an input interrupt endpoint and [ 20.468857] i2c_hid i2c-UNIW0001:00: failed to reset device. ... [ 39.741876] i2c_hid i2c-UNIW0001:00: can't add hid device: -61 Not sure what further information is required, but I'll attach the full dmesg output. Created attachment 277765 [details]
post-patch dmesg output for GK5CN5Z
To me this looks like a different issue (HID reset does not get through). Can you attach /proc/interrupts and /sys/kernel/debug/gpio here just that we can check whether it is related to GPIO at all? OK, I shall add these. I'll also add the dmesg from before the patch for reference... The error line is: [ 15.386072] cannonlake-pinctrl INT3450:00: pin 208 cannot be used as IRQ Created attachment 277783 [details]
pre-patch dmesg output for GK5CN5Z
Created attachment 277785 [details]
/proc/interrupts on GK5CN5Z
Created attachment 277787 [details]
/sys/kernel/debug/gpio on GK5CN5Z
If it helps, I tried using the laptop buttons to enable/disable the touchpad. Nothing happens, but dmesg says this: [ 254.890450] i801_smbus 0000:00:1f.4: BIOS is accessing SMBus registers [ 254.890459] i801_smbus 0000:00:1f.4: Driver SMBus register access inhibited (In reply to Simon Detheridge from comment #81) > OK, I shall add these. I'll also add the dmesg from before the patch for > reference... The error line is: > > [ 15.386072] cannonlake-pinctrl INT3450:00: pin 208 cannot be used as IRQ Can you attach /sys/kernel/debug/pinctrl/INT3450:00/pins for *patched* version? P.S. For now it looks like the GPIO problem gone, but please attach the file to make us sure. If it's the case, you would need to create another bug regarding to HID device communication issue. Created attachment 277791 [details]
/sys/kernel/debug/pinctrl/INT3450:00/pins on GK5CN5Z post-patch
Sure, here's the output
(In reply to Simon Detheridge from comment #87) > Created attachment 277791 [details] > /sys/kernel/debug/pinctrl/INT3450:00/pins on GK5CN5Z post-patch > > Sure, here's the output Thanks. I don't see any issues with GPIO now. Raised as bug #200787 - if there's anything else I should add to that let me know, I'm not really sure what I'm doing with this. I'm facing the same exact problem as Simon with the Tong Fang GK5CN5Z model on Ubuntu 18.04. Is there any update concerning the fix? Thanks! @Jon are you comfortable building your own kernel? It would be good to know if your experience is the same as mine in bug #200787 once the patches from this bug are applied. (In reply to Marc Landolt from comment #68) > (In reply to Andy Shevchenko from comment #66) > > Created attachment 277553 [details] > > Fix community ordering for H variant > > > > Another patch for Cannonlake PCH-H. > > Yay, GREAT, Andy you're a Genius, the Touchpad is working :) > > After Downloading Kernel 4.18.RC6, patching with > https://bugzilla.kernel.org/attachment.cgi?id=277507&action=diff and > https://bugzilla.kernel.org/attachment.cgi?id=277553&action=diff it's > working. > > -Tap to click works > -2 Finger scroll works (only Natural Scrolling, always on) > -2 Finger right click works > -left mouse button works > -right mouse button does not work but with 2 finger click it works > -Edge Scrolling does not work > -it disconects from time to time (rmmod -r hid-multitouch && modprobe > hid-multitouch helps) > > shall I test other patches and do you still need the outputs from Comment 67 > (interrupts, iomem, ranges, pins? > > With kind regards and many thanks so far > Marc Landolt For me on Asus FX504 laptop with ELAN1200 touchpad tap to click doesn't work. If your touchpad works in general (the device can be used somehow) and does not fail with "GPIO can't be used as IRQ" error, it is most probably not related to this bug. Please file a separate bug about it. @Simon: Thanks for the info, you did lots of hard work. I had a look on the other ticket too. I've never compiled by own kernel, so I have not tried the patch. I'm a bit surprised to see that we need a separate ticket for "Razer Blade 15" and "Recoil II" given that both of them are actually "Tong Fang GK5CN5". I also don't undertand why the above patch "works" on Razer does not on Recoil. That's my understanding from your messages, can you confirm? If you do find a patch that more-or-less works for Recoil, please give me a shout. I'll try to test it on my side too. I just want to avoid compiling my own kernel given that I have no idea what I'm doing without expecting any positive outcome from that. On the other hand, if you want someone else to confirm something on a similar system, I'm more than happy to do it. Just be descriptive of what you want me to do. (I know how to code but never hacked the kernel) Also FYI, Razer says they are working into bringing a Linux Driver for the touchpad here: https://insider.razer.com/index.php?threads/razer-blade-15-ubuntu-18-04-trackpad-not-working.35999/#post-447134 Not sure what's the progress with that and whether this will cover not only Razers but any Tong Fang GK5CN5 based laptop. I would love an update if anyone from Razer is on the thread. Cheers! :) Razer released a recently 1.05 BIOS update that fixes the touchpad problem. Created attachment 278089 [details]
dsdt_before_after
Adding DSDT for Razer Blade 15 2018 before and after the 1.05 update.
I'm facing the same problem on a Recoil II which is a similar but not identical model to Razers' (both are based on TongFang models). @Simon: I also read your details on Bug #200787. The two problems seem related so I tried the patches listed here for the pinctrl module (did not recompile the entire kernel, just the module) but that did not work unfortunately. Shameless plug: I appreciate that debugging drivers is not the most pleasant coding exercise, so the hero who will solve the problem on the GK5CN5Z model can claim this bounty: https://www.bountysource.com/issues/62633122-touchpad-on-tong-fang-gk5cn5z It's not much but others are welcome to pitch in. :) @Mika Westerberg Well that was a mistake on my part. I forgot to put 30-touchpad.conf for enabling tap to click. Hope the patch would improve a little to fix random disconnects and make it in mainline kernel. (In reply to Andy Shevchenko from comment #69) > (In reply to Marc Landolt from comment #68) > > (In reply to Andy Shevchenko from comment #66) > > > Created attachment 277553 [details] > > > Fix community ordering for H variant > > > > > > Another patch for Cannonlake PCH-H. > > > > Yay, GREAT, Andy you're a Genius, the Touchpad is working :) > > Sorry it wasn't working from the day 1. > > > shall I test other patches > > Nothing to test for now. There are three problems in your case and one of > them doesn't clear yet (in a sense of root cause). That's, we are discussing > internally and will come up with workaround / solution later on. > > > and do you still need the outputs from Comment 67 > > (interrupts, iomem, ranges, pins? > > Yes, please. helly Andy Shevchenko, the patch you wrote for me does not work on Kernel 4.19-rc2 anymore, so the touchpad does not work in kernel 4.19-rc2 because i can not apply https://bugzilla.kernel.org/attachment.cgi?id=277507&action=diff since someone has changed something in pinctrl-intel.c, so the patch works only with 4.18-rc6. my question is, this fix did not went into mainline? with kind regards Marc Landolt (In reply to Marc Landolt from comment #100) > the patch you wrote for me does not work on Kernel 4.19-rc2 anymore, so the > touchpad does not work in kernel 4.19-rc2 because i can not apply > https://bugzilla.kernel.org/attachment.cgi?id=277507&action=diff since > someone has changed something in pinctrl-intel.c, so the patch works only > with 4.18-rc6. my question is, this fix did not went into mainline? To be clear, there are three patches, two of which are part of v4.19-rc1. The only piece is missed in upstream is pin ownership check W/A, that is effectively is a middle of the attachment #277507 [details]. Hello Andy i added now lines 1016, 1021 and 1022 from https://bugzilla.kernel.org/attachment.cgi?id=277507&action=diff to the /drivers/pinctrl/intel/pinctrl-intel.c from kernel 4.19-rc2 and now the touchpad works again, i guess if (intel_pad_acpi_mode(pctrl, pin)) evaluates to false and then it returns and does not do the rest of the function. But I'm not a C Coder, i know very little about C or Kernel things. I will now test the things you said in thread and tell you the results in the thread https://bugzilla.kernel.org/show_bug.cgi?id=200663#c6 with kind regards Marc Landolt I'm Using Asus Fx504GD (Elan1200) should to apply these patch? Someone suggest me this link, so i'm a little confuse. I patched and boot correctly but in xinput it's still doesn't recognized my touchpad, and also my mouse (Mouse worked well on preview kernel). any new about this bug? tongfang gk5cn6z @Hieu Cao you could try the additional patch from Bug #200787 - if your touchpad is connected the same ways as mine then it could be the problem. @trave5 yes, I managed to get it working, see above (In reply to Simon Detheridge from comment #106) > @Hieu Cao you could try the additional patch from Bug #200787 - if your > touchpad is connected the same ways as mine then it could be the problem. I'm glad to hear this sound. Today I'll try to install a Linux again on my computer (I already remove it and replaced by windows). Does it work the same thing on virtual machine? Because I still not getting how to manage dual boot effectly. @Hieu Cao - I don't know for sure that the patch will fix your problem in this case, I just figured it might be worth a shot. It may not be worth reformatting your computer for though. You shouldn't need any of this stuff for Linux on a VM, as your hypervisor will be virtualising your mouse pointer anyway, so it won't be seeing the gpio directly. (In reply to Simon Detheridge from comment #108) > @Hieu Cao - I don't know for sure that the patch will fix your problem in > this case, I just figured it might be worth a shot. It may not be worth > reformatting your computer for though. > > You shouldn't need any of this stuff for Linux on a VM, as your hypervisor > will be virtualising your mouse pointer anyway, so it won't be seeing the > gpio directly. Thank for your advice. I kinda love to use Arch and I3wm. It friendly but now I using the Windows it becomes harder for me, I can not do anything without mouse or touchpad. And the Cli on Windows it does not have a friendly command :( I think I should waiting when this project is complete for a stable patch. (In reply to Hieu Cao from comment #103) > I'm Using Asus Fx504GD (Elan1200) should to apply these patch? > Someone suggest me this link, so i'm a little confuse. Hello Hieu i can not tell for Fx504GD, for GL703GE you need to add these 3 lines from https://bugzilla.kernel.org/show_bug.cgi?id=199911#c102 i mentioned, otherwise the touchpad does not work at all... if the Fx504GD has the same hardware as GL703GE then you have at least a functioning touchpad except that it crashes sometimes and then you need to rmmod and insmod hid-multitouch that it works again... Try to kindly ask Andy Shevchenko he helped me to make my touchpad working. He Patched a lot, but this 3 lines i mentioned went not to mainline and without this 3 lines my touchpad does not work with kind regards Marc Landolt (In reply to Marc Landolt from comment #110) > (In reply to Hieu Cao from comment #103) > > I'm Using Asus Fx504GD (Elan1200) should to apply these patch? > > Someone suggest me this link, so i'm a little confuse. > > Hello Hieu > > i can not tell for Fx504GD, for GL703GE you need to add these 3 lines from > https://bugzilla.kernel.org/show_bug.cgi?id=199911#c102 i mentioned, > otherwise the touchpad does not work at all... > > if the Fx504GD has the same hardware as GL703GE then you have at least a > functioning touchpad except that it crashes sometimes and then you need to > rmmod and insmod hid-multitouch that it works again... > > Try to kindly ask Andy Shevchenko he helped me to make my touchpad working. > He Patched a lot, but this 3 lines i mentioned went not to mainline and > without this 3 lines my touchpad does not work > > with kind regards > Marc Landolt I trying to install arch and patch it again, but now I got an error when try to patch it. https://pastebin.com/1aRfSJy4 It look like the new kernel I download from kernel.org was add these patch. What I need to do now? Or these patch are not compatible with the newest kernel? Opps, my bad. I copied wrong patch so right now the patch is applied well. After i patched 2 patch, And I search in the direction (/drivers/pinctrl/intel/pinctrl-intel.c) these patch there. What i need to do now? 3 lines you said to add to the /drivers/pinctrl/intel/pinctrl-intel.c it already there. You only need this workaround:
+#if 0
if (intel_pad_acpi_mode(pctrl, pin)) {
dev_warn(pctrl->dev, "pin %u cannot be used as IRQ\n", pin);
return -EPERM;
}
+#endif
if you see "pin x cannot be used as IRQ" in your dmesg. If there is no such message then the hack is not needed. I think someone in this bug mentioned that with new BIOS this particular issue went away so I'm assuming the new BIOS corrects the pin ownership from ACPI to driver.
(In reply to Mika Westerberg from comment #115) > You only need this workaround: > > +#if 0 > if (intel_pad_acpi_mode(pctrl, pin)) { > dev_warn(pctrl->dev, "pin %u cannot be used as IRQ\n", pin); > return -EPERM; > } > +#endif > > if you see "pin x cannot be used as IRQ" in your dmesg. If there is no such > message then the hack is not needed. I think someone in this bug mentioned > that with new BIOS this particular issue went away so I'm assuming the new > BIOS corrects the pin ownership from ACPI to driver. Sorry but I'm still confuse. Does I need to patch 2 patch obove or just add only those code to the kernel source? When you run "dmesg" command and there is a line saying something like "pin x cannot be used as IRQ" then you need to do the above hack. Otherwise it is not needed. Hope this makes it more clear :) The other two patches are already included in v4.19-rc1 so there is no need to re-apply them (assuming you are running v4.19-rcX). (In reply to Mika Westerberg from comment #118 #117) I understood, thanks for your reply. I gonna try when I have time, and will update the result. @Mika @Mika Westerberq When I copied that hack above it look weird. Only that code have a + before #. Should I delete it? Hi, I have a similar problem on HP Zbook Studio G5. I tried the two patches from comment 68 on 4.18.rc6. It did not solve my problem. As suggested, I opened a new report bug 201175. @Marc Landolt I also tried 4 patch on your other topic and it still not detected my touch pad @Mika Westerberg I'm tried to patch 2 (on kernel 4.18.8) without your code hack. But when I run dmesg | grep IRQ it doesn't have any pin error. But in the original (current running kernel 4.18.8) without any patch. I saw the error you mentioned [hieuc@archlinux ~]$ dmesg | grep IRQ [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] NR_IRQS: 20736, nr_irqs: 2048, preallocated irqs: 16 [ 0.003333] DMAR-IR: Enabled IRQ remapping in x2apic mode [ 0.619217] ACPI: PCI Interrupt Link [LNKA] (IRQs) *0 [ 0.619268] ACPI: PCI Interrupt Link [LNKB] (IRQs) *1 [ 0.619317] ACPI: PCI Interrupt Link [LNKC] (IRQs) *0 [ 0.619365] ACPI: PCI Interrupt Link [LNKD] (IRQs) *0 [ 0.619414] ACPI: PCI Interrupt Link [LNKE] (IRQs) *0 [ 0.619462] ACPI: PCI Interrupt Link [LNKF] (IRQs) *0 [ 0.619510] ACPI: PCI Interrupt Link [LNKG] (IRQs) *0 [ 0.619558] ACPI: PCI Interrupt Link [LNKH] (IRQs) *0 [ 0.644183] PCI: Using ACPI for IRQ routing [ 0.730824] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0 [ 0.891547] pcieport 0000:00:1d.0: AER enabled with IRQ 122 [ 0.997281] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 3.600805] cannonlake-pinctrl INT3450:00: pin 225 cannot be used as IRQ [ 3.602284] cannonlake-pinctrl INT3450:00: pin 225 cannot be used as IRQ [ 3.674377] r8169 0000:02:00.0 eth0: RTL8168h/8111h, 4c:ed:fb:2c:e0:82, XID 54100800, IRQ 137 Hi, Yes, the '+' should be deleted. Could you try v4.19-rcX instead of v4.18.8 because it should include the two patches already. Then if you still see the "cannot be used as IRQ" error, you should apply the hack patch (otherwise it is not needed). I think I know what is my problem. May I patched the new kernel without any config except the name local and also I didn't install an xf86-input-libinput package. So that why my custom kernel kinda weird, it takes 4-5 minutes to compile, it worked not properly. Yesterday I have read the wiki page, and I realized that I can use the current config to a custom kernel's config: `zcat /procs/config.gz > .config. Then I compile it took more than 30 minutes (I guess because I slept). So after school, I will try to apply my custom kernel again. I hope it will detected my touchpad driver. If it still not detected, I'll try the newest kernel along your advice. Thanks Opps! I tried both kernel but it can not boot into arch with error: device UUID, mount: /new_root can't find UUID I also run this command on the default kernel (mkinitcpio -p linux then update-grub) but it still not working https://ibb.co/hE4R9z OMG! After few weeks I fixed this. Thanks @Mika Westerberg @Marc Landolt @Thank you who created the patch My problem exactly I compiled kernel wrong way. To make it work properly I have to use the current kernel's config. Also thanks everyone here to give me the ideas to not give up. (In reply to Marc Landolt from comment #74) > There are still some issues, I guess it are the same issues that are also on > the GL503VS and maybe in a different part of the kernel (not sure): > > Problems: > -random lockups > -disconnection (workaround rmmod && insmod hid-multitouch) > -the physical button (the whole touchpad) is not debounced, if you click > once it does multiple clicks (workaround: use tap to click) > > False Acused Problems: > -non-natural 2 finger scrolling works after reboot > > please tell me if i shall test other things on my GL703GE... Can you give me the detail of disconnection fix? (Where I add rmmod and insmod hid-multitouch (In reply to Hieu Cao from comment #127) > (In reply to Marc Landolt from comment #74) > > There are still some issues, I guess it are the same issues that are also > on > > the GL503VS and maybe in a different part of the kernel (not sure): > > > > Problems: > > -random lockups > > -disconnection (workaround rmmod && insmod hid-multitouch) > > -the physical button (the whole touchpad) is not debounced, if you click > > once it does multiple clicks (workaround: use tap to click) > > > > False Acused Problems: > > -non-natural 2 finger scrolling works after reboot > > > > please tell me if i shall test other things on my GL703GE... > > Can you give me the detail of disconnection fix? (Where I add rmmod and > insmod hid-multitouch its just a workaround if you do a rmmod hid-multitouch && modprobe hid-multitouch then it starts working again, this problem is not fixed yet, i opened the following thread for this problem: https://bugzilla.kernel.org/show_bug.cgi?id=200663 I'm not sure if this is better commented here or bug #200787... With 4.19_rc4, plus my patch to fix the gpp-e pin numbers, I'm still getting: cannonlake-pinctrl INT3450:00: pin 210 cannot be used as IRQ @Mika Westerberg mentioned a new BIOS, but my manufacturer doesn't currently have a BIOS update available, so I currently still need the hack. I wonder if there's another less hacky solution to this, given that I know pin 210 *can* be used as an IRQ, and I suspect that there will be a number of devices in the wild which don't have an updated BIOS that fixes the ACPI issue? Just wanted to echo Simon's point on this. Applying the fixes of this ticket + Simon's pin patch gets the touchpad working. BIOS update is not currently available, let alone that most manufacturers don't have Linux users in mind... I would love to see a proper fix for that in the Kernel because compiling a custom kernel is quite difficult for the average user. I couldn't have done it myself without the help of Simon. Yes, we are working on it. Sorry that it takes so long but we need to get the right people in Intel involved to confirm whether the assertion in the driver is correct or not. Once we know that we can decide what is the proper fix. marvellous :) (In reply to Marc Landolt from comment #128) > (In reply to Hieu Cao from comment #127) > > (In reply to Marc Landolt from comment #74) > > > There are still some issues, I guess it are the same issues that are also > > on > > > the GL503VS and maybe in a different part of the kernel (not sure): > > > > > > Problems: > > > -random lockups > > > -disconnection (workaround rmmod && insmod hid-multitouch) > > > -the physical button (the whole touchpad) is not debounced, if you click > > > once it does multiple clicks (workaround: use tap to click) > > > > > > False Acused Problems: > > > -non-natural 2 finger scrolling works after reboot > > > > > > please tell me if i shall test other things on my GL703GE... > > > > Can you give me the detail of disconnection fix? (Where I add rmmod and > > insmod hid-multitouch > > its just a workaround > > if you do a rmmod hid-multitouch && modprobe hid-multitouch then it starts > working again, this problem is not fixed yet, i opened the following thread > for this problem: https://bugzilla.kernel.org/show_bug.cgi?id=200663 Thanks, this workaround is worked for me. Created attachment 278693 [details]
Fix CNL-H HOSTSW_OWN offset
Simon et al. Could you try the attached patch and see if the "pin X cannot be used as IRQ" problem goes away?
Created attachment 278737 [details] pinctrl-intel-Fix-pin-translation-when-requesting-IR.patch Hi Mika, I can confirm that your latest patch in comment #134 enables the touchpad of the HP Zbook mWS x360 that was buggy before. However, after applying the changes in the 'fixes' branch of the pinctrl tree, I realized that when requesting the IRQ, we are making twice the transposition from hwirq to pin. I wrote a patch (attached) that fixes it, and I'd like to get your feedback before submitting it too. With v4.19-rc4, the 2 patches that are on 'fixes' on pinctrl, and this one, the HP zbook I have here finally have both touchpad and touchscreen working without warnings in the dmesg. (for references, the hwirq of the touchscreen is 77 that gets translatesd to 64, and the hwirq of the touchpad was around 250 and gets translated to 205 IIRC) Hi Benjamin, Hmm I don't see where we could do the translation twice. i2c-hid calls directly to irqchip so it should be using the non-translated numbers which then get translated in intel_gpio_irq_reqres() and the like to the appropriate pin numbers. Maybe I'm missing something. Do you have possibility to add some debugging to the driver so that it prints out all the numbers (GPIO offset, hwirq and pin number)? Also what is the error you are seeing after applying the last patch? Thanks! Actually you are right. The commit 55aedef50d4d810670916d9fce4a40d5da2079e7 ("pinctrl: intel: Do pin translation when lock IRQ") was added because gpiolib core calls ->get_direction() and that did not handle the translation properly. After the commit 96147db1e1dff83679e71ac92193cbcab761a14c ("pinctrl: intel: Do pin translation in other GPIO operations as well") we do translation so the previous commit is not needed and in fact it should not operate on pins in the first place (only with the GPIO numbers).
So I think the right fix for the issue you are seeing now is to revert 55aedef50d4d810670916d9fce4a40d5da2079e7 (basically your patch but also do the same for intel_gpio_irq_relres()).
Created attachment 278739 [details] dmesg on th HP zBook x360, withoutgpio translation fixes > Hmm I don't see where we could do the translation twice. i2c-hid calls > directly to irqchip so it should be using the non-translated numbers which > then get translated in intel_gpio_irq_reqres() and the like to the > appropriate pin numbers. Maybe I'm missing something. I have put the backtrace in the attached dmesg: - i2c_hid_probe() - request_threaded_irq() - intel_gpio_irq_reqres() -> translation from hwirq 77 to 64 - gpiochip_lock_as_irq() - gpiod_get_direction() -> translation from hwirq 64 to 51 -> failure to get direction: [ 11.360372] gpio gpiochip0: (INT3450:00): gpiochip_lock_as_irq: cannot get GPIO direction > Do you have possibility to add some debugging to the driver so that it prints out all the numbers (GPIO offset, hwirq and pin number)? sure. The attached dmesg has the following diff: --- diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c index ec8dafc..c08d464 100644 --- a/drivers/pinctrl/intel/pinctrl-intel.c +++ b/drivers/pinctrl/intel/pinctrl-intel.c @@ -783,6 +783,12 @@ static int intel_gpio_to_pin(struct intel_pinctrl *pctrl, unsigned offset, *community = comm; if (padgrp) *padgrp = pgrp; + + pr_err("%s: converting offset %d to %d", + __func__, offset, pin); + + if (offset == 64 || offset == 205) + dump_stack(); return pin; } --- > Also what is the error you are seeing after applying the last patch? [ 11.360372] gpio gpiochip0: (INT3450:00): gpiochip_lock_as_irq: cannot get GPIO direction [ 11.360446] cannonlake-pinctrl INT3450:00: unable to lock HW IRQ 64 for IRQ [ 11.360508] genirq: Failed to request resources for WCOM48A0:00 (irq 203) on irqchip intel-gpio [ 11.360661] i2c_hid i2c-WCOM48A0:00: Could not register for WCOM48A0:00 interrupt, irq = 203, ret = -22 [ 11.363790] i2c_hid: probe of i2c-WCOM48A0:00 failed with error -22 Note that this only occurs for the touchscreen. The touchpad works fine, but if you look carefully at the logs, you'll see that the get_direction() gets called with pin 168 instead of 205 (with hwirq being 258). So I guess here the touchpad works by luck because pin 168 is an actual GPIO while 51 is not. (In reply to Mika Westerberg from comment #137) > Actually you are right. The commit 55aedef50d4d810670916d9fce4a40d5da2079e7 > ("pinctrl: intel: Do pin translation when lock IRQ") was added because > gpiolib core calls ->get_direction() and that did not handle the translation > properly. After the commit 96147db1e1dff83679e71ac92193cbcab761a14c > ("pinctrl: intel: Do pin translation in other GPIO operations as well") we > do translation so the previous commit is not needed and in fact it should > not operate on pins in the first place (only with the GPIO numbers). I should have spotted that I was altering the behavior of this patch, indeed. > > So I think the right fix for the issue you are seeing now is to revert > 55aedef50d4d810670916d9fce4a40d5da2079e7 (basically your patch but also do > the same for intel_gpio_irq_relres()). Just tested and I can confirm that reverting 55aedef50, adding your "pinctrl: intel: Do pin translation in other GPIO operations as well" and the patch in comment #134 works great on the HP. Thanks for checking! Do you want to submit the revert or should I? (In reply to Mika Westerberg from comment #140) > Thanks for checking! Do you want to submit the revert or should I? Please do. I think it'll get faster this way. You can add my reported-and-tested-by on it (or anything similar that helps the process). OK, just sent them out with you Cc'd. (In reply to Benjamin Tissoires from comment #141) > (In reply to Mika Westerberg from comment #140) > > Thanks for checking! Do you want to submit the revert or should I? > > Please do. I think it'll get faster this way. You can add my > reported-and-tested-by on it (or anything similar that helps the process). Hi Benjamin, Can i ask which patch you apply to which kernel to get the HP 360 touchpad working? is it from comment #134 or #135 or both ? and 4.19.rc? I want to give a try on my zbook studio G5, thank you (In reply to Bo from comment #143) > Can i ask which patch you apply to which kernel to get the HP 360 touchpad > working? is it from comment #134 or #135 or both ? and 4.19.rc? I have: - v4.19-rc4 - 8e2aac333785f91ff74e219a1e78e6bdc1ef2c41 ("pinctrl: cannonlake: Fix gpio base for GPP-E") - 96147db1e1dff83679e71ac92193cbcab761a14c ("pinctrl: intel: Do pin translation in other GPIO operations as well") - the 2 patches from https://patchwork.ozlabs.org/project/linux-gpio/list/?series=67208 8e2aac33378 and 96147db1e1dff are in v4.19-rc5, so you basically only need the 2 patches from Mika that has been sent today. > I want to give a try on my zbook studio G5, thank you Cool, please report, I am also interested in the results. Created attachment 278751 [details]
pinctrl: cannonlake: Fix HOSTSW_OWN register offset of H variant
Created attachment 278753 [details]
Revert "pinctrl: intel: Do pin translation when lock IRQ"
Attached the two patches that should be applied on top of v4.19-rc5. Hi Benjamin and Mika, Thanks for the information. I compiled 4.19-rc5 with the two patches. Unfortunately my touchpad is still not responding upon boot. I have a similar problem as Comment 77, namely the touchpad only works after a hibernation. i attach the dmesg Created attachment 278755 [details]
dmesg_hp_zbook_studio_g5
Bo, the 2 patches are now in v4.19-rc6. According to your dmesg, you have the same pin number that I have on the x360. I am a little bit worried that it doesn't work for you. Could you try booting a vanilla v4.19-rc6 and report if your touchpad is still failing? (In reply to Benjamin Tissoires from comment #150) > Bo, the 2 patches are now in v4.19-rc6. > According to your dmesg, you have the same pin number that I have on the > x360. I am a little bit worried that it doesn't work for you. > > Could you try booting a vanilla v4.19-rc6 and report if your touchpad is > still failing? Hi Benjamin, I was on vacation and the laptop is no longer at my hand. Sorry I cannot test at this moment. Will report as long as i get the laptop back, which might take some time. thanks for the help. I am also trying to get the touchscreen working on my zBook x360. The touchpad worked ootb with kernel 4.18.12, but I can't get the touchscreen to work and dont know where to get started. On all kernel versions I tried I ran xinput --list and xinput test while using the touchscreen, without success. Beside 4.18.12 (which shipped with Fedora 29 Beta) i tried the latest 4.19.0-0.rc8 unmodified kernel, and I tried compiling the latest stable 4.18.14 with the patch "pinctrl-intel-translation-fix.patch" that is attached on this bug, as Benjamin Tissoires and gschramm pointed out that this works. Nothing of this seemed to have any effect, could someone give me a hint? - It seems like some of these patches are obsolete, which of them would still be necessary on 4.19.0-0.rc8 ? Or, which kernel version with which patches applied can be confirmed to work to make the kernel recognize the touchscreen? - Where else can I get started with debugging beside running xinput to see what fails, or if the touchscreen is recognized? Are there other relevant os/userspace factors beside the kernel that I need to take into account? I'd appreciate any help! Accordingly to comments 144-147 I compiled the kernel from v4.19-rc5 branch and applied the two patches that were attached by Mika 2018-09-25. Contrary to what Bo posted in 148, my Touchpad still works as it used to do with the other kernels(except some 4.15 kernel that shipped with a latest ubuntu live stick I tried). Touchscreen still doesn't work. Hi Janus, Do you still see the message "GPIO can't be used as IRQ" when you boot the system? If not, it may be another issue and in that case I suggest you to file a bug against input subsystem/HID instead. dmesg | grep -i "GPIO" does not return anything, neither does dmesg --level=err I guess my issue is not directly related then. Janus, IIRC, lat time I checked, CONFIG_PINCTRL_CANNONLAKE was not set in the default configuration of Fedora kernels. Can you double check? If CONFIG_PINCTRL_CANNONLAKE is not set, the device will not show up at all in the dmesg. (In reply to Benjamin Tissoires from comment #156) > Janus, IIRC, lat time I checked, CONFIG_PINCTRL_CANNONLAKE was not set in > the default configuration of Fedora kernels. Can you double check? > > If CONFIG_PINCTRL_CANNONLAKE is not set, the device will not show up at all > in the dmesg. This sounds like something which we need to fix in the Fedora kernels. Benjamin, can you ask the Fedora kernel team to enable this ? @Benjamin, That seems to be right, the config file includes the comment "# CONFIG_PINCTRL_CANNONLAKE is not set". This is also the case for their latest 4.19-0-0.rc8 vanilla kernel they provide in the repos. When compiling myself I took over that configuration. Will enable it and give feedback after compilation finished! (Hope I'm not going beyond the scope of this bug too far) (In reply to Hans de Goede from comment #157) > This sounds like something which we need to fix in the Fedora kernels. > Benjamin, can you ask the Fedora kernel team to enable this ? done: https://bugzilla.redhat.com/show_bug.cgi?id=1641057 I'll ping Laura if she doesn't take it in the next few days. (In reply to janus.reith from comment #158) > (Hope I'm not going beyond the scope of this bug too far) No worries, it's better to understand why the fix is not working for you, and hopefully, the problem is just in the config file. Touchreen works now! I built the kernel using the same setup I tried before, v4.19-rc5 with the two patches, now with CONFIG_PINCTRL_CANNONLAKE enabled. I might be wrong, but it seems like the touchpad cursor speed seems to be faster? It already worked before, including multitouch gestures. Just to clarify: If I compile the latest 4.19-0-0.rc8, will I still need the two patches? (In reply to janus.reith from comment #160) > I might be wrong, but it seems like the touchpad cursor speed seems to be > faster? It already worked before, including multitouch gestures. That's possible. Haven't paid much attention to this as the test setup I have is not my primary machine. > > Just to clarify: If I compile the latest 4.19-0-0.rc8, will I still need the > two patches? IIRC, you should be good with a vanilla 4.19-rc8, yes. So no need for extra patches. I have compiled the 4.19-rc8 kernel today (using the mainline kernel package in Arch User Repository) on my HP ZBOOK G5 x360. And I can confirm the touchpad works way smoother (faster) now. This might be because libinput is now recognizing it, but I haven't been able to confirm this yet. I didn't need any patches, so the touchscreen, pen and touchpad now work out of the box. The only issue I still have is that GDM seems to have a problem starting with the new kernel (keep having a blinking cursor till I press the power button and then it goes to sleep, after sleep GDM works fine. When I replaced GDM with Lightdm everything worked fine without going to sleep first. Hello, Touchpad on my HP Zbook Studio G5 works great under the new 4.19 stable release. Thanks for the effort. (In reply to Marc Landolt from comment #68) > (In reply to Andy Shevchenko from comment #66) > > Created attachment 277553 [details] > > Fix community ordering for H variant > > > > Another patch for Cannonlake PCH-H. > > Yay, GREAT, Andy you're a Genius, the Touchpad is working :) > > After Downloading Kernel 4.18.RC6, patching with > https://bugzilla.kernel.org/attachment.cgi?id=277507&action=diff and > https://bugzilla.kernel.org/attachment.cgi?id=277553&action=diff it's > working. > > -Tap to click works > -2 Finger scroll works (only Natural Scrolling, always on) > -2 Finger right click works > -left mouse button works > -right mouse button does not work but with 2 finger click it works > -Edge Scrolling does not work > -it disconects from time to time (rmmod -r hid-multitouch && modprobe > hid-multitouch helps) > > shall I test other patches and do you still need the outputs from Comment 67 > (interrupts, iomem, ranges, pins? > > With kind regards and many thanks so far > Marc Landolt Thanks @Marc! The same solution worked for GL503-GE ;-) Cheers! Hi everyone. Any news here, does the the disconnecting randomly has been fix? (In reply to Hieu Cao from comment #165) > Hi everyone. > Any news here, does the the disconnecting randomly has been fix? Hello Hieu Cao on my GL703GE it's not randomly but when you put the palm or 5 or more fingers on it. i opened another bug but not assigned yet and i did not hear from any solution so far: https://bugzilla.kernel.org/show_bug.cgi?id=200663 With kind regards Marc Thanks Marc Landolt I'll following that bug, I hope it will be fix in the future. This bug has been fixed in v4.20. It worked on v4.20 automatically. Few days ago, but I also uninstalled it either. Because the annoyning of disconnecting. I wonder if it fixed the disconnecting? I just want to make sure that to reinstall linux again. (In reply to Andy Shevchenko from comment #168) > This bug has been fixed in v4.20. Does it fix the disconnecting problem? (In reply to Hieu Cao from comment #169) > It worked on v4.20 automatically. Few days ago, but I also uninstalled it > either. Because the annoyning of disconnecting. I wonder if it fixed the > disconnecting? I just want to make sure that to reinstall linux again. > > (In reply to Andy Shevchenko from comment #168) > > This bug has been fixed in v4.20. > Does it fix the disconnecting problem? in my case (Asus GL703GE) it does not. Disconnection Problem persists, but you can take now a 4.20 Kernal without patch and the Touchpad will work except if you put 5 Fingers or the Palm on it (on GL703GE) with kind regards Marc Landolt This problem is not completely resolved: touchpad is not full functional after waking from suspend. This has been confirmed by multiple users as reported in #201175. |
Razer Blade 15 2018 touchpad support [1532:0233] Bus 001 Device 005: ID 1532:0233 Razer USA, Ltd Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1532 Razer USA, Ltd idProduct 0x0233 bcdDevice 2.00 iManufacturer 1 Razer iProduct 2 Razer Blade iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0054 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 61 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 159 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 2 Mouse iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 94 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0000 (Bus Powered)