Re: PROBLEM: ASUS GU501GM Elantech touchpad not detected

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux