Created attachment 292197 [details] Dmesg output of kernel 5.8.4 The Goodix touchscreen of my Lenovo Ideapad D330-10IGM stopped working after updating to kernel 5.7. Dmesg output of kernel 5.6.15: [ 4.823660] Goodix-TS i2c-GDIX1002:00: i2c-GDIX1002:00 supply AVDD28 not found, using dummy regulator [ 4.823699] Goodix-TS i2c-GDIX1002:00: i2c-GDIX1002:00 supply VDDIO not found, using dummy regulator [ 4.824163] Goodix-TS i2c-GDIX1002:00: ID 927, version: 105b [ 4.828777] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/0000:00:16.3/i2c_designware.1/i2c-1/i2c-GDIX1002:00/input/input7 Dmesg output of kernel 5.8.4: [ 5.102921] Goodix-TS i2c-GDIX1002:00: supply AVDD28 not found, using dummy regulator [ 5.102945] Goodix-TS i2c-GDIX1002:00: supply VDDIO not found, using dummy regulator [ 5.189183] Goodix-TS: probe of i2c-GDIX1002:00 failed with error -22 Looked the same with kernel 5.7.x.
Created attachment 292199 [details] Dmesg output of kernel 5.6.15
Created attachment 292223 [details] Dmesg Kernel 5.7 Can confirm the problem, since kernel 5.7 the touchscreen of my Lenovo D330-10IGM doesn't work anymore. Works fine with 5.6, I tried today the kernel 5.8 but unfortunately with the same problem. I also always get the error -22 with Kernel 5.7 and 5.8.
Seeing the same on 5.10 and 5.11 on my GPD P2Max
I can confirm this as well -- touchscreen works with Ubuntu mainline-crack kernel 5.6.19, but breaks with 5.7 on a GPD P2 Max.
I recently tried 5.12 and then 5.13, seems to be fixed. I didn't try 5.9-5.11.
(In reply to alan.loewe from comment #5) > I recently tried 5.12 and then 5.13, seems to be fixed. I didn't try > 5.9-5.11. Hmm, perhaps we're looking at different issues (that were a result of the same patchset). In any case, I've bisected the issue I'm facing to commit a7d4b171660cadd0b410be132759267731da11bb: "Input: goodix - add support for getting IRQ + reset GPIOs on Cherry Trail devices" Seems like it puts the touchscreen in a bad state. I've worked around it for now on 5.13.14 by compiling the goodix module (without these changes) separately and installing it. (Alternatively, you can blacklist the module and load it manually after boot)
That commit is referenced to be fixed by the following commits, which are basically the same: https://github.com/torvalds/linux/commit/921daeeca91bda2dfb57fcba9f69ff368083be4b https://github.com/torvalds/linux/commit/a0bf06dc51dbbc5ad182b1bcf4d879db8d297c5e Seems to be device-specific, maybe yours is another special case.
(In reply to alan.loewe from comment #7) > That commit is referenced to be fixed by the following commits, which are > basically the same: > https://github.com/torvalds/linux/commit/ > 921daeeca91bda2dfb57fcba9f69ff368083be4b > https://github.com/torvalds/linux/commit/ > a0bf06dc51dbbc5ad182b1bcf4d879db8d297c5e > > Seems to be device-specific, maybe yours is another special case. Thanks, seems like that could be it! I've got something preventing me from using a kernel > 5.13 atm, but I'll check it out and confirm when I can
I shortly got my hopes up, but after installing 5.14.1 using the mainline PPA on my Ubuntu 21.04 install on GPD P2Max there is still no joy: # uname -a Linux microvanes 5.14.1-051401-generic #202109030936 SMP Fri Sep 3 09:45:45 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 21.04 Release: 21.04 Codename: hirsute # dmesg ... [ 118.488484] Goodix-TS i2c-GDIX1002:00: supply AVDD28 not found, using dummy regulator [ 118.488517] Goodix-TS i2c-GDIX1002:00: supply VDDIO not found, using dummy regulator [ 118.488764] Goodix-TS i2c-GDIX1002:00: i2c test failed attempt 1: -121 [ 118.514333] Goodix-TS i2c-GDIX1002:00: i2c test failed attempt 2: -121 [ 118.642391] Goodix-TS i2c-GDIX1002:00: i2c test failed attempt 1: -121 [ 118.670323] Goodix-TS i2c-GDIX1002:00: i2c test failed attempt 2: -121 [ 118.698229] Goodix-TS i2c-GDIX1002:00: I2C communication failure: -121 [ 118.711202] Goodix-TS: probe of i2c-GDIX1002:00 failed with error -121
(In reply to Zhongfu Li from comment #6) > In any case, I've bisected the issue I'm facing to commit > a7d4b171660cadd0b410be132759267731da11bb: I just tried building the goodix module from a commit preceding this one but it would not work. Which commit ID are you building the module from?
(In reply to Alex R from comment #10) > I just tried building the goodix module from a commit preceding this one but > it would not work. Which commit ID are you building the module from? If you're loading the newly-built module after boot (instead of at boot), did you remember to blacklist the old goodix module like I mentioned in comment #6? The breaking change appears to put the touchscreen controller in a bad state or something, so you need to prevent that from happening
(In reply to Zhongfu Li from comment #11) > did you remember to blacklist the old goodix module like I mentioned in > comment #6? The breaking change appears to put the touchscreen controller in > a bad state or something, so you need to prevent that from happening Thank you, that worked for me (I did not pay attention to blacklist it).
Hello, I just stumbled over this bug while doing a duckduckgo search about some other Goodix touchscreen issue. I'm the author of the patches which seem to be causing problems on your laptops; and I'm sorry to hear that these patches are causing problems for you. I wish that one of you would have dropped me an email about this as soon as you figured out my patches were to blame. Anyways lets see if we can get to the bottom of this. Can each of you please create an acpidump of your machine, by running: sudo acpidump -o acpidump.lenovo-ideapad-d330 or sudo acpidump -o acpidump.gpd-p2-max-2019 (the -o just sets the filename, having the right filename makes it easy for me to see which is which; and there is a new 2022 p2-max coming) And then attach the generated acpidump.lenovo-ideapad-d330 / acpidump.gpd-p2-max-2019 file here. Please also run the following command as root from a terminal (e.g. after "sudo su -"): for i in /sys/kernel/debug/pinctrl/*/pins; do echo $i >> pins.txt; cat $i >> pins.txt; done Both after a boot where the touchscreen is working and after a boot where it does not work. Please rename the generated pins.txt to pins-working.txt resp. pins-non-working.txt after running this (and before the other run) and then attach both here. Regards, Hans
Created attachment 299877 [details] acpidump for GPD P2 Max (2019)
Created attachment 299879 [details] dump of GPD P2 Max (2019) GPIO pins with non-functional touchscreen on 5.11.0, with goodix module loaded
Created attachment 299881 [details] dump of GPD P2 Max (2019) GPIO pins with functional touchscreen on 5.11.0, with (old) goodix module loaded
(In reply to Hans de Goede from comment #13) > Hello, > > I just stumbled over this bug while doing a duckduckgo search about some > other Goodix touchscreen issue. > > I'm the author of the patches which seem to be causing problems on your > laptops; and I'm sorry to hear that these patches are causing problems for > you. I wish that one of you would have dropped me an email about this as > soon as you figured out my patches were to blame. > > Anyways lets see if we can get to the bottom of this. > > Can each of you please create an acpidump of your machine, by running: > > sudo acpidump -o acpidump.lenovo-ideapad-d330 > > or > > sudo acpidump -o acpidump.gpd-p2-max-2019 > > (the -o just sets the filename, having the right filename makes it easy for > me to see which is which; and there is a new 2022 p2-max coming) > > And then attach the generated acpidump.lenovo-ideapad-d330 / > acpidump.gpd-p2-max-2019 file here. > > > Please also run the following command as root from a terminal (e.g. after > "sudo su -"): > > for i in /sys/kernel/debug/pinctrl/*/pins; do echo $i >> pins.txt; cat $i >> > pins.txt; done > > Both after a boot where the touchscreen is working and after a boot where it > does not work. Please rename the generated pins.txt to pins-working.txt > resp. pins-non-working.txt after running this (and before the other run) and > then attach both here. > > Regards, > > Hans Hello Hans, Apologies -- for some reason, it slipped my mind to cc you. My bad. In any case, I've attached the files you've requested. For the second pin state dump (with functional touchscreen), I built the goodix module from goodix.c as of commit 1921dacef72d5c1fd6a63bfffba3997f34935e7f (ie the parent commit of a7d4b171660cadd0b410be132759267731da11bb) Hope this helps!
Zhongfu Li, Thank you for the quick response and for the acpidump + logs. The acpi dump pretty much immediately makes clear what is going on here; and makes me wish (as I've wished before) that GPD would hire better people to do their firmware for them. GPD makes pretty nice hardware but the firmware tends to have issues. The problem here is this (from the ACPI DSDT): Device (TCS1) { Name (_ADR, Zero) // _ADR: Address Name (_HID, "GDIX1002") // _HID: Hardware ID ... Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (WBUF, ResourceTemplate () { I2cSerialBusV2 (0x0014, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.PCI0.I2C3", 0x00, ResourceConsumer, , Exclusive, ) GpioInt (Edge, ActiveLow, Shared, PullDefault, 0x0000, "\\_SB.GPO0", 0x00, ResourceConsumer, , ) { // Pin list 0x0015 } GpioIo (Shared, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO0", 0x00, ResourceConsumer, , ) { // Pin list 0x0019 } }) Return (WBUF) /* \_SB_.PCI0.I2C3.TCS1._CRS.WBUF */ } Note that both the GpioInt entry (for the IRQ of the touchscreen) as well as the GpioIo entry (for the *reset* line of the touchscreen) point to the same "\\_SB.GPO0" pin 0x0019 GPIO, which of course cannot be right. I guess that when the Linux drivers requests the reset line, the GPIO which really is used for the IRQ gets reconfigured as an output breaking things. What is new compared to older hw with Goodix touchscreens is that the _PS0 and _PS3 methods seem to actually turn the device on/off now. So Linux using this is no longer necessary. I guess that the Windows drivers likely know this and don't use the resources because of this. On older hw Linux does need to turn the device on/off itself, which is what my patches do. I could make the driver detect this specific DSDT bug. But I think it might be better to limit the use of the GPIOs to certain CPU generations. I will prepare a patch for this.
(In reply to Hans de Goede from comment #18) > Zhongfu Li, > > Thank you for the quick response and for the acpidump + logs. The acpi dump > pretty much immediately makes clear what is going on here; and makes me wish > (as I've wished before) that GPD would hire better people to do their > firmware for them. GPD makes pretty nice hardware but the firmware tends to > have issues. > > The problem here is this (from the ACPI DSDT): > > Device (TCS1) > { > Name (_ADR, Zero) // _ADR: Address > Name (_HID, "GDIX1002") // _HID: Hardware ID > ... > Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings > { > Name (WBUF, ResourceTemplate () > { > I2cSerialBusV2 (0x0014, ControllerInitiated, 0x00061A80, > AddressingMode7Bit, "\\_SB.PCI0.I2C3", > 0x00, ResourceConsumer, , Exclusive, > ) > GpioInt (Edge, ActiveLow, Shared, PullDefault, 0x0000, > "\\_SB.GPO0", 0x00, ResourceConsumer, , > ) > { // Pin list > 0x0015 > } > GpioIo (Shared, PullDefault, 0x0000, 0x0000, > IoRestrictionOutputOnly, > "\\_SB.GPO0", 0x00, ResourceConsumer, , > ) > { // Pin list > 0x0019 > } > }) > Return (WBUF) /* \_SB_.PCI0.I2C3.TCS1._CRS.WBUF */ > } > > Note that both the GpioInt entry (for the IRQ of the touchscreen) as well as > the GpioIo entry (for the *reset* line of the touchscreen) point to the same > "\\_SB.GPO0" pin 0x0019 GPIO, which of course cannot be right. > > I guess that when the Linux drivers requests the reset line, the GPIO which > really is used for the IRQ gets reconfigured as an output breaking things. > > What is new compared to older hw with Goodix touchscreens is that the _PS0 > and _PS3 methods seem to actually turn the device on/off now. So Linux using > this is no longer necessary. I guess that the Windows drivers likely know > this and don't use the resources because of this. > > On older hw Linux does need to turn the device on/off itself, which is what > my patches do. > > I could make the driver detect this specific DSDT bug. But I think it might > be better to limit the use of the GPIOs to certain CPU generations. > > I will prepare a patch for this. Ah, that makes sense. Thanks for your help -- I greatly appreciate it!
Ugh, I just realized that my initial analysis of the problem is wrong: 1. I copy and pasted from the wrong DSDT, from another device which I was using for comparison. The P2 max DSDT does appear to have both pins at the same GPIO, but ... 2. This is one of those DSDTs where the resource table is generic and then later gets patched with different pin numbers, so it is actually using 2 different pin numbers. So now I need to dig a little deeper.
Can you please boot with the in-kernel/broken goodix_ts module blacklisted (which I believe you have by default) and then do: modprobe goodix_ts dyndbg Laoding the *bad/broken* version of the kernel module (insmod is fine too, as long as you specify dyndbg as extra argument) and then do: dmesg > dmesg.txt And attach the generated dmesg.txt file here ?
Created attachment 299885 [details] dmesg of kernel 5.11.0 after `modprobe goodix dyndbg` with broken module (i've taken the liberty to redact some unique hardware identifiers, eg MAC addresses -- hope that's fine)
Created attachment 299889 [details] [PATCH] Input: goodix - Try not to touch the reset-pin on x86/ACPI devices Ok, I think I have figured out what is going on (based on the pinctrl dumps). Can you give the attached patch a try with the upstream/mainline version of goodix.c please ?
Note this patch probably only helps on the GPD P2 max, if a D330 owner can provide an acpidump that would be greatly appreciated. Also please provide dmesg output after manually loading the upstream version of the module on a D330 like this: sudo modprobe goodix_ts dyndbg (on a system where the module is blacklisted so that it has not been loaded before)
Created attachment 299897 [details] ACPI dumps and pins of multiple D330 devices (kernel 5.13.13)
I attached acpidumps and pins from a number of D330 devices (it's a digital signage project). They might be interesting, because they are not all the same (also some of those with same file size differ). I can only confirm #00 to be working. There are reports that hint that some might not work. Due to the pandemic I couldn't verify that yet, but I'll try to do so this week. I tried to reproduce the non-working state with 5.10.83 LTS, which is conveniently provided by the distribution, but it works. I can try an older kernel, if it helps. Do you need this and the modprobe also in non-working state? Or is it also helpful when it works?
Hi Alan, Thank you for the dumps. For the pins what I really need is from 1 device: 1. Time the pins.txt in a working config (either new kernel with manually build older driver, or old kernel is fine) + 2. Another pins.txt from the same device with the new non-working kernel + driver. Also please clearly mark which is which :) As for the dmesg with dyndbg added as modprobe / insmod extra argument, that needs to be from a non working kernel + driver. Thank you, Hans
So a quick peek at the D330 DSDT shows that it has empty INTI / INTO / INTS ACPI functions under the GDIX1002 ACPI device. That should not be an issue because Linux prefers to use raw GPIO access and those are listed. But I expect that the -22 / -EINVAL error is coming from a request to try and get one of the 2 GPIOs, the output of the non working version of the driver + dyndbg should show this. This makes me realize that I need to change the error logging to not require using dyndbg when there are actually errors.
(In reply to Hans de Goede from comment #23) > Created attachment 299889 [details] > [PATCH] Input: goodix - Try not to touch the reset-pin on x86/ACPI devices > > Ok, I think I have figured out what is going on (based on the pinctrl > dumps). Can you give the attached patch a try with the upstream/mainline > version of goodix.c please ? I can confirm this works -- and will also allow for a successful probe of the touchscreen after loading and unloading a non-working version of the goodix module, unlike before. Thanks!
(In reply to Zhongfu Li from comment #29) > I can confirm this works -- and will also allow for a successful probe of > the touchscreen after loading and unloading a non-working version of the > goodix module, unlike before. Thanks! Great, thank you I have submitted this upstream now: https://lore.kernel.org/linux-input/20211206091116.44466-1-hdegoede@redhat.com/T/#u Alan, there is a chance that this fixes your problem too (say 50/50% chance) if you can give this patch a try on a D330 that would be great.
I can confirm that the goodix touchscreen now finally works as expected on my GPD P2 Max using mainline kernel 5.16. Thx!
(In reply to Martin from comment #31) > I can confirm that the goodix touchscreen now finally works as expected on > my GPD P2 Max using mainline kernel 5.16. Thx! You're welcome. Alan, I would really like to also fix things on the D330, if you can make some time to run the requested tests / provide the requested logs that would be great.
On my GPDWIN3 the driver stopps working. It's loaded on boot. If i rmmod it and modprobe goodix_ts again, input is working.
(In reply to DocMAX from comment #33) > On my GPDWIN3 the driver stopps working. It's loaded on boot. If i rmmod it > and modprobe goodix_ts again, input is working. Your bug report is a little bit low on details, so I have lots of questions: 1. Stops working *when* ? At random times / after a suspend resume ? / never works after boot until you do the rmmod + modprobe ? 2. Is this a new problem, or is this also present with older kernels? 3. Have you tried the patch which fixes things for GPD P2? : https://lore.kernel.org/linux-input/20211206091116.44466-1-hdegoede@redhat.com/T/#u
(In reply to Hans de Goede from comment #34) > (In reply to DocMAX from comment #33) > > On my GPDWIN3 the driver stopps working. It's loaded on boot. If i rmmod it > > and modprobe goodix_ts again, input is working. > > Your bug report is a little bit low on details, so I have lots of questions: > > 1. Stops working *when* ? At random times / after a suspend resume ? / never > works after boot until you do the rmmod + modprobe ? > > 2. Is this a new problem, or is this also present with older kernels? > > 3. Have you tried the patch which fixes things for GPD P2? : > https://lore.kernel.org/linux-input/20211206091116.44466-1-hdegoede@redhat. > com/T/#u On my GPD WIN 2, on boot, the touch screen does not work at all, dmesg show alot of i2c errors with code -121. When modprobe -r and modprobe the module again, the touchscreen will work. This happens to all kernels version I've tried: 5.4 (ubuntu 20.04), 5.13 (install from linux-generic-hwe-20.04) and 5.16 (compiled from source). The 5.16 kernel contained the patch for GPD P2 you mentioned above. On kernel 5.16, after suspend resume, the touchscreen continue to work. I did not test suspend/ resume on other kernels. Please let me know if you need to get any additional debugging info.
A bit update on suspend/ resume. If I just choose suspend from the menu and then resume right away, the touchscreen continues to work. However, leaving the win 2 closed for a certain amount of time (8 hours-ish, I'm not even sure if the machine went into suspend state or not), then the touchscreen stopped working.
I am having this same issue on an Aya Neo Next using 5.12 Kernel, I have also tried 5.16 and the issue persists. its the same error from the post about in the dmesg. The Goodix touchscreen of my Lenovo Ideapad D330-10IGM stopped working after updating to kernel 5.7. Dmesg output of kernel 5.6.15: [ 4.823660] Goodix-TS i2c-GDIX1002:00: i2c-GDIX1002:00 supply AVDD28 not found, using dummy regulator [ 4.823699] Goodix-TS i2c-GDIX1002:00: i2c-GDIX1002:00 supply VDDIO not found, using dummy regulator [ 4.824163] Goodix-TS i2c-GDIX1002:00: ID 927, version: 105b [ 4.828777] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/0000:00:16.3/i2c_designware.1/i2c-1/i2c-GDIX1002:00/input/input7 Dmesg output of kernel 5.8.4: [ 5.102921] Goodix-TS i2c-GDIX1002:00: supply AVDD28 not found, using dummy regulator [ 5.102945] Goodix-TS i2c-GDIX1002:00: supply VDDIO not found, using dummy regulator [ 5.189183] Goodix-TS: probe of i2c-GDIX1002:00 failed with error -22 Dropping back to 5.0 with Ubuntu 19 made touch screen work, but then I lose the mediatek wifi6/bt module drivers. So either I need to sort this out or rebuild 5.6 with the drivers that we need to get this working.
Steve, Thank you for reaching out, If I understand things correctly you are having issues with the Goodix touchscreen no longer working on 2 devices: 1. Aya Neo Next 2. Lenovo Ideapad D330-10IGM Correct? The confirmed fix for the breakage of the touchscreen on the GPD P2 Max has landed in the 5.17 kernel only. So if possible please try with a 5.17 kernel. Also please, for each device (so do the entire set of info gathering commands twice) do the following to gather more info: 1. Run the following command: sudo acpidump -o acpidump.lenovo-ideapad-d330 resp. sudo acpidump -o acpidump.aya-neo-next 2. Boot a *working* kernel and then run as root (after "sudo su -"): rmmod goodix modprobe goodix dyndbg dmesg > dmesg.lenovo-ideapad-d330.working for i in /sys/kernel/debug/pinctrl/*/pins; do echo $i >> pins.txt; cat $i >> > pins.txt; mv pins.txt pins.lenovo-ideapad-d330.working resp. rmmod goodix modprobe goodix dyndbg dmesg > dmesg.aya-neo-next.working for i in /sys/kernel/debug/pinctrl/*/pins; do echo $i >> pins.txt; cat $i >> > pins.txt; mv pins.txt pins.aya-neo-next.working 3. Boot a *non* working kernel and then run as root (after "sudo su -"): rmmod goodix modprobe goodix dyndbg dmesg > dmesg.lenovo-ideapad-d330.non-working for i in /sys/kernel/debug/pinctrl/*/pins; do echo $i >> pins.txt; cat $i >> > pins.txt; mv pins.txt pins.lenovo-ideapad-d330.non-working resp. rmmod goodix modprobe goodix dyndbg dmesg > dmesg.aya-neo-next.non-working for i in /sys/kernel/debug/pinctrl/*/pins; do echo $i >> pins.txt; cat $i >> > pins.txt; mv pins.txt pins.aya-neo-next.non-working And attach the generated acpidump.*, dmesg.* and pins.* files here.
(In reply to Hans de Goede from comment #38) Hello, I'm having same issue on Aya Neo Next.
Created attachment 301210 [details] aya neo next acpidump
Created attachment 301211 [details] aya neo next kernel log, non working
Created attachment 301212 [details] aya neo next kernel log, working
Created attachment 301213 [details] aya neo next pins, non working
Created attachment 301214 [details] aya neo next pins, working I can only supply files and logs from Aya Neo Next. I'll take over from Steve on this machine, asked him about it too. Working files are from Ubuntu 20.04, Non-working are from Arch Linux. It's not working on 5.19-rc1 kernel too, and all other kernels after 5.10 that I could test. Sorry if I'm doing something wrong, it's my first time using Bugzilla
It looks like the for loop for the pins somehow got mangled, here is what I tried to ask for as debuginfo for the pins: for i in /sys/kernel/debug/pinctrl/*/pins; do echo $i >> pins.txt; cat $i >> pins.txt; done And then do this for both a non-working and a working kernel.
Ah I see you already have done this correctly (or so it seems) thanks. Unfortunately it seems that on an AMD system there is no useful info there. Can you also do: cat /sys/kernel/debug/gpio > gpio.txt In both a working and non-working case please?
Created attachment 301215 [details] aya neo next gpios, non working
Created attachment 301216 [details] aya neo next gpios, working
(In reply to Hans de Goede from comment #46) > Ah I see you already have done this correctly (or so it seems) thanks. > > Unfortunately it seems that on an AMD system there is no useful info there. > > Can you also do: > > cat /sys/kernel/debug/gpio > gpio.txt > > In both a working and non-working case please? Just did it.
Created attachment 301218 [details] [PATCH] Input: goodix - call acpi_device_fix_up_power() in some cases Ok, I think I know what is going on. For a quick test, on a 5.18 or 5.19 kernel try doing: sudo rmmod goodix_ts sudo modprobe goodix_ts I expect that will actually make the touchscreen work, although it is possible that the first failed probe has confused the hw to a point where this does not help. So regardless of the outcome please also try building a 5.18 or 5.19 kernel with this patch attached. I expect this to fix things for you.
Created attachment 301219 [details] [PATCH] drm: panel-orientation-quirks: Add quirk for the Aya Neo Next Pro Unrelated I saw that you are passing fbcon=rotate:1 on the kernel commandline. I assume that you are doing this because the device is using a portrait screen in a landscape clamshell-enclosure like the AYA NEO 2021 ? And you need this to get the text-console to show the right way up ? Note that the kernel has a quirk table for this and using this will not only fix thefbcon, but also let drm/kms clients like plymouth(bootsplash) and GNOME know about the screen being mounted 90 degree rotated and will make them adjust for this automatically. Assuming I got the reason for the fbcon=rotate:1 kernel commandline option right, please give the attached patch a try (together with dropping fbcon=rotate:1 from the kernel cmdline) and let me know if this works, so that I can submit it upstream. If the patch does not work, please check the output of: cat /sys/class/dmi/id/sys_vendor cat /sys/class/dmi/id/product_name versus the strings the patch is checking for I might have made a mistake there since figuring out these strings from dmesg is not 100% foolproof.
Yes, doing a quick rmmod and modprobe goodix_ts does make the touchscreen work. And this patch fixes it properly \o/ Feel free to include this: Tested-by: Maya Matuszczyk <maccraft123mc@gmail.com> Nitpick about commit message: http://lists.infradead.org/pipermail/linux-rockchip/2022-June/032441.html Huge thanks! I spent so much time on this bug
(In reply to Hans de Goede from comment #51) > Created attachment 301219 [details] > [PATCH] drm: panel-orientation-quirks: Add quirk for the Aya Neo Next Pro > > Unrelated I saw that you are passing fbcon=rotate:1 on the kernel > commandline. > > I assume that you are doing this because the device is using a portrait > screen in a landscape clamshell-enclosure like the AYA NEO 2021 ? And you > need this to get the text-console to show the right way up ? Yes, that is correct. > > Note that the kernel has a quirk table for this and using this will not only > fix thefbcon, but also let drm/kms clients like plymouth(bootsplash) and > GNOME know about the screen being mounted 90 degree rotated and will make > them adjust for this automatically. > > Assuming I got the reason for the fbcon=rotate:1 kernel commandline option > right, please give the attached patch a try (together with dropping > fbcon=rotate:1 from the kernel cmdline) and let me know if this works, so > that I can submit it upstream. > > If the patch does not work, please check the output of: > > cat /sys/class/dmi/id/sys_vendor > cat /sys/class/dmi/id/product_name > > versus the strings the patch is checking for I might have made a mistake > there since figuring out these strings from dmesg is not 100% foolproof. I already did and submitted upstream https://patchwork.freedesktop.org/patch/489171/ There's an amdgpu(?) bug that's preventing rotation with this patch /after/ amdgpufb takes over from efifb/simplefb, working on it too now. If it's related to Aya Neo Next, It's on my todo list or I'm already done working on it ;)
(In reply to Maya Matuszczyk from comment #53) > I already did and submitted upstream > https://patchwork.freedesktop.org/patch/489171/ I've replied to this pointing out a way to avoid the need for having 6 extra entries in the dmi_system_id table. > There's an amdgpu(?) bug that's preventing rotation with this patch /after/ > amdgpufb takes over from efifb/simplefb, working on it too now. Hmm, generally this is handled in the drm fbdev emulation core which is shared, so this should work. Assuming the panel is eDP, I wonder what the output of: cat /sys/class/drm/card0-eDP-1/modes is after the amdgpu driver has loaded? (stating the obvious: you may need to adjust the path to match the actual connector of the panel under /sys/class/drm). Maybe the panel is higher res then 1280x800 and 1280x800 is only used by the efifb, where as amdgpu switches it to its native mode? Oh wait. I see I think, this does need GPU driver support, e.g. the i915 driver calls drm_connector_set_panel_orientation_with_quirk for eDP and DSI panels. Even though I wrote this I forgot this needs to be handled inside the driver because the core does not know if something is the builtin panel or an external panel and we only want to call this on internal panels. So see for example: [hans@shalem linux]$ ack drm_connector_set_panel_orientation_with_quirk drivers/gpu/drm/i915/ drivers/gpu/drm/i915/display/intel_dp.c 5119: drm_connector_set_panel_orientation_with_quirk(&connector->base, drivers/gpu/drm/i915/display/vlv_dsi.c 1681: drm_connector_set_panel_orientation_with_quirk(&connector->base, drivers/gpu/drm/i915/display/icl_dsi.c 1984: drm_connector_set_panel_orientation_with_quirk(&connector->base, And then you need to do the same in e.g. the eDP handling in amdgpu. Let me know if you need help with this.
(In reply to Hans de Goede from comment #54) > Assuming the panel is eDP, I wonder what the output of: > > cat /sys/class/drm/card0-eDP-1/modes > > is after the amdgpu driver has loaded? > (stating the obvious: you may need to adjust the path to match the actual > connector of the panel under /sys/class/drm). 800x1280 720x1280 720x1152 768x1024 600x960 800x600 600x800 640x480 efifb is set to native mode, otherwise drm panel quirk wouldn't work > > Maybe the panel is higher res then 1280x800 and 1280x800 is only used by the > efifb, where as amdgpu switches it to its native mode? > > Oh wait. I see I think, this does need GPU driver support, e.g. the i915 > driver calls drm_connector_set_panel_orientation_with_quirk for eDP and DSI > panels. Even though I wrote this I forgot this needs to be handled inside > the driver because the core does not know if something is the builtin panel > or an external panel and we only want to call this on internal panels. > > So see for example: > > [hans@shalem linux]$ ack drm_connector_set_panel_orientation_with_quirk > drivers/gpu/drm/i915/ > drivers/gpu/drm/i915/display/intel_dp.c > 5119: drm_connector_set_panel_orientation_with_quirk(&connector->base, > > drivers/gpu/drm/i915/display/vlv_dsi.c > 1681: drm_connector_set_panel_orientation_with_quirk(&connector->base, > > drivers/gpu/drm/i915/display/icl_dsi.c > 1984: drm_connector_set_panel_orientation_with_quirk(&connector->base, > > And then you need to do the same in e.g. the eDP handling in amdgpu. Let me > know if you need help with this. I guess I could use some help but I probably can figure it out on my own. It looks like amdgpu driver /does/ make use of drm panel quirks [macc24@ayaneo linux]$ git grep drm_connector_set_panel_orientation drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c: drm_connector_set_panel_orientation_with_quirk(connector,
(In reply to Maya Matuszczyk from comment #55) > It looks like amdgpu driver /does/ make use of drm panel quirks > [macc24@ayaneo linux]$ git grep drm_connector_set_panel_orientation > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c: > drm_connector_set_panel_orientation_with_quirk(connector, So the amdgpu driver has 2 code paths for the display engines: 1. directly programming the hw under drivers/gpu/drm/amd/display/amdgpu_dm/ 2. through the video BIOS under drivers/gpu/drm/amd/amdgpu/atombios*.c And your dmesg does contain something about atombios, so maybe those are the paths being hit. There is a amdgpu_atombios_dp_get_panel_mode() inside drivers/gpu/drm/amd/amdgpu/atombios_dp.c which gets called from drivers/gpu/drm/amd/amdgpu/atombios_encoders.c and either that function or its call-site seems like possibly a good place to call drm_connector_set_panel_orientation_with_quirk(). Note for starters you could just add a: pr_info("atombios code path hit\n"); there, to see if that is indeed the code path which is being hit on your device.
I'm having the same problem, I am trying to get a goodix digitzer to work on my Raspberry Pi Compute Module 4. I have a similar digitizer that was built on 8 inch size and that works perfectly fine however when I hookup the 10 inch version I get the same error as Martin. # OS INFO Linux version 5.15.32-v8+ (dom@buildbot) (aarch64-linux-gnu-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1538 SMP PREEMPT Thu Mar 31 19:40:39 BST 2022 # dmesg logs [ 1851.768125] Goodix-TS 6-005d: supply AVDD28 not found, using dummy regulator [ 1851.768413] Goodix-TS 6-005d: supply VDDIO not found, using dummy regulator [ 1851.872886] Goodix-TS 6-005d: i2c test failed attempt 1: -121 [ 1851.902540] Goodix-TS 6-005d: i2c test failed attempt 2: -121 [ 1851.930314] Goodix-TS 6-005d: I2C communication failure: -121 [ 1851.932343] Goodix-TS: probe of 6-005d failed with error -121 Any guidance would be appreciated
(In reply to mtahafiroz from comment #57) > I'm having the same problem, I am trying to get a goodix digitzer to work on > my Raspberry Pi Compute Module 4. I have a similar digitizer that was built > on 8 inch size and that works perfectly fine however when I hookup the 10 > inch version I get the same error as Martin. This bug is about issues with Goodix touchscreens on ACPI/x86 devices where we need to deal with the reset and interrupt GPIOs being described/handled in various different ways on different ACPI/x86 devices. On a Raspberry Pi I expect the touchscreen to be described in devicetree. If the devicetree description accurately matches the actual hw and all your wiring is correctly connected then things should just work. Error -121 means that the I2C client is not acking any requests to it. This might be caused by: 1. The I2C wires not being connected properly (or by missing pull-ups on the I2C wires) or the I2C settings not being correct inside the devicetree. 2. The address of the chip not being programmed correctly during the reset of the chip, which relies on the reset and interrupt lines being connected properly and the GPIO settings being correct in devicetree.
@mtahafiroz Btw please do not report issues with vendor kernels here. This should be reported here instead: https://github.com/raspberrypi/linux
(In reply to Hans de Goede from comment #58) > (In reply to mtahafiroz from comment #57) > > I'm having the same problem, I am trying to get a goodix digitzer to work > on > > my Raspberry Pi Compute Module 4. I have a similar digitizer that was built > > on 8 inch size and that works perfectly fine however when I hookup the 10 > > inch version I get the same error as Martin. > > This bug is about issues with Goodix touchscreens on ACPI/x86 devices where > we need to deal with the reset and interrupt GPIOs being described/handled > in various different ways on different ACPI/x86 devices. > > On a Raspberry Pi I expect the touchscreen to be described in devicetree. If > the devicetree description accurately matches the actual hw and all your > wiring is correctly connected then things should just work. > > Error -121 means that the I2C client is not acking any requests to it. This > might be caused by: > > 1. The I2C wires not being connected properly (or by missing pull-ups on the > I2C wires) or the I2C settings not being correct inside the devicetree. > > 2. The address of the chip not being programmed correctly during the reset > of the chip, which relies on the reset and interrupt lines being connected > properly and the GPIO settings being correct in devicetree. Appreciate the reply even though my comment wasn't valid I'm new to the kernel.