Hi, On Thu, May 17, 2018 at 7:05 AM, wereturtle <wereturtledev@xxxxxxxxx> wrote: > Hi Benjamin, > >> Why do always people want to blacklist those drivers when they have a > good chance to make their device working? > > My apologies. I wasn't very clear. My previous dmesg and other > outputs were done without anything blacklisted. I only did > blacklisting in an entirely separate endeavor based on several things > I'd read that were workarounds for older Elantech touchpads. Well, no worries. It's more of a general rant against all of those blogpost that suggest to blacklist drivers when there is no good reasons behind it. And generally, if you blacklist a driver it should be temporary until a fix is found, so not reporting it is even worse. (again, this is not against you). > > The good news is, I managed to get Kernel 4.17 RC 5 up and running > last night. The bad news is, the touchpad was still not detected. > Here is the /proc/version info: > > Linux version 4.17.0-041700rc5-generic (kernel@tangerine) (gcc version > 7.3.0 (Ubuntu 7.3.0-18ubuntu2)) #201805132030 SMP Mon May 14 00:32:50 > UTC 2018 > > dmesg and acpidump output are attached in the zip file > "kernel_4.17_RC5_report.zip" at the bottom comment of the Launchpad > bug report here: > > https://bugs.launchpad.net/ubuntu/cosmic/+source/linux/+bug/1770862 Well we definitively made some progress: [ 12.348035] i2c_hid i2c-ELAN1201:00: i2c-ELAN1201:00 supply vdd not found, using dummy regulator [ 12.348208] i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration [ 12.348367] i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration [ 12.348525] i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration [ 12.348681] i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration [ 12.348683] i2c_hid i2c-ELAN1201:00: hid_descr_cmd failed I am not sure why this didn't appeared in the other dmesg attached to the bug report, but at least now the ACPI table is properly parsed and i2c-hid tries to setup the touchpad. The issue seems to be in the i2c_designware driver, so adding Hans (sorry Hans, I couldn't think at anybody else who could have an idea of why this i2c adapter fails) and the linux-i2c ml. For the record, the ELAN1201 touchpad in the DSDT is described as: ------------------- Scope (_SB.PCI0.I2C1) { Device (ETPD) { Name (SBFB, ResourceTemplate () { I2cSerialBusV2 (0x004C, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.PCI0.I2C1", 0x00, ResourceConsumer, _Y34, Exclusive, ) }) Name (SBFI, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) { 0x0000005F, } }) CreateWordField (SBFB, \_SB.PCI0.I2C1.ETPD._Y34._ADR, BADR) // _ADR: Address Name (_ADR, One) // _ADR: Address Name (ETPH, Package (0x17) { "ELAN1200", "ELAN1201", "ELAN1203", "ELAN1200", "ELAN1201", "ELAN1300", "ELAN1301", "ELAN1300", "ELAN1301", "ELAN1000", "ELAN1200", "ELAN1200", "ELAN1200", "ELAN1200", "ELAN1200", "ELAN1203", "ELAN1203", "ELAN1201", "ELAN1300", "ELAN1300", "ELAN1200", "ELAN1300", "ELAN1201" }) Name (FTPH, Package (0x05) { "FTE1001", "FTE1200", "FTE1200", "FTE1300", "FTE1300" }) Method (_HID, 0, NotSerialized) // _HID: Hardware ID { If ((TPDI & 0x04)) { BADR = 0x15 Return (DerefOf (ETPH [TPHI])) } If ((TPDI & 0x10)) { BADR = 0x15 Return (DerefOf (FTPH [TPHI])) } Return ("ELAN1000") } Name (_CID, "PNP0C50" /* HID Protocol Device (I2C bus) */) // _CID: Compatible ID Name (_UID, One) // _UID: Unique ID Name (_S0W, 0x03) // _S0W: S0 Device Wake State Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If ((Arg0 == ToUUID ("3cdff6f7-4267-4555-ad05-b30a3d8938de") /* HID I2C Device */)) { If ((Arg2 == Zero)) { If ((Arg1 == One)) { Return (Buffer (One) { 0x03 // . }) } Else { Return (Buffer (One) { 0x00 // . }) } } If ((Arg2 == One)) { Return (One) } } Else { Return (Buffer (One) { 0x00 // . }) } } Method (_STA, 0, NotSerialized) // _STA: Status { If (((TPIF != One) || (DSYN && One))) { Return (Zero) } Return (0x0F) } Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Return (ConcatenateResTemplate (SBFB, SBFI)) } } } ------------------- So nothing scary, the interrupt is a plain interrupt, not a GPIO. I guess the issue lies in i2c-designware and the AMD implementation... Cheers, Benjamin > > Thank you for your help! > > On Wed, May 16, 2018 at 2:58 AM, Benjamin Tissoires > <benjamin.tissoires@xxxxxxxxx> wrote: >> Hi, >> >> On Tue, May 15, 2018 at 5:58 AM, Were Turtle <wereturtledev@xxxxxxxxx> wrote: >>> [1.] One line summary of the problem: >>> ASUS GU501GM Elantech touchpad not detected >>> >>> [2.] Full description of the problem/report: >>> The touchpad on the new ASUS GU501GM (the junior Zephyrus M that is a >>> Best Buy exclusive) does not seem to be detected whatsoever with >>> "xinput list". Windows 10 device manager shows the touchpad as >>> ELAN:1201, HID_DEVICE:00FF1006. I've tried various combinations of >>> i8042.* kernel parameters, as well as psmouse.proto=bare and different >>> combinations for acpi_osi, but to no avail. I've also tried >>> blacklisting i2c_hid and hid_multitouch. I've tried the mainstream >> >> Why do always people want to blacklist those drivers when they have a >> good chance to make their device working? >> >> There are multiple reports of issues with recent Asus laptops. For instance: >> https://www.spinics.net/lists/linux-input/msg56193.html >> https://bugzilla.redhat.com/show_bug.cgi?id=1510649 >> >> and others are related to ELAN1200 devices that are not enumerated >> correctly by i2c-hid: >> https://bugzilla.redhat.com/show_bug.cgi?id=1543769 >> >> The reason in the latter case is because of the IRQ pins that are not >> correctly mapped IIRC. It should have been fixed in a v4.17-rc kernel >> though. >> >> Could you provide a full dmesg without any blacklisted driver so we >> see if there is an error somewhere? >> >> Also could you provide the output of acpidump as root so we have a >> better idea on how the touchpad is declared in the DSDT. >> >> Cheers, >> Benjamin >> >>> kernel 4.16.7, also to no avail. The latest release candidates (#4 and >>> #5) for 4.17 and 4.16.8 would not let me start X, though I noticed no >>> touchpad miracle while I was in the SDDM login screen (I'm on Kubuntu >>> 18.04). (Sorry, I am too inexperienced to figure out why X won't >>> start on newer mainline kernels. I was sure to uninstall the nvidia >>> drivers before installing them.) >>> >>> [3.] Keywords (i.e., modules, networking, kernel): >>> >>> [4.] Kernel version (from /proc/version): >>> >>> Linux version 4.16.7-041607-lowlatency (kernel@tangerine) (gcc version >>> 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #201805021131 SMP PREEMPT Wed May 2 >>> 15:44:57 UTC 2018 >>> >>> [5.] Output of Oops.. message >>> N/A >>> >>> [6.] A small shell script or example program which triggers the >>> problem (if possible) >>> N/A >>> >>> [X.] Other notes, patches, fixes, workarounds: >>> Please see all the "xinput list", dmesg, devices, and Xorg.0.log >>> outputs attached at >>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1770862 >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-input" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
