Reverting the changes found in this patch fixes the issue: https://lore.kernel.org/all/20220712020058.90374-1-gch981213@gmail.com/ With that patch the AT Translated Set 2 Keyboard doesn't show up with the evtest and is not usable. Hardware: Aya Neo Air Plus AMD Ryzen 7 6800U
Could you please attach the output of "sudo dmidecode"; and having a dmesg at hand might be good as well.
Created attachment 304203 [details] dmidecode output
Created attachment 304204 [details] stock kernel dmesg
Created attachment 304205 [details] Patched kernel dmesg
Using a modified DSDT I was able to get this working on any kernel. The bios do not have proper values so a kernel workaround will most certainly be needed for this device and likely many others as well.
FWIW, this issue is currently discussed in this thread: https://lore.kernel.org/all/01ea5c8e-ed2f-7568-f6ed-896329e7b673@leemhuis.info/
At least in your situation you can see that very clearly the interrupt source override in the MADT is correct: [ 0.003333] ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 1 low edge) But your ACPI tables are incorrect (and hence the patch to the DSDT helps the issue). To me it seems this issue really boils down to the logic in the kernel of what to trust when, and there doesn't seem to be a great answer. Today it's something like this: 1) If it's extended IRQ syntax, trust the DSDT. 2) If it's legacy syntax (IRQ/IRQNoflags) mayyyybe double check what the MADT and the DSDT have agree. This is needed for a number of older buggy machines. "2" ended up causing problems for a number of Ryzen 6000 machines because they didn't have an interrupt source override in place and without this the value found in the MADT was wrong (Active high) but the value in the DSDT was right (Active Low). This is why we put in place a case to ignore all that and trust the DSDT on Ryzen systems. You're the exact opposite of this and so that's why this logic fell apart. I think what we're missing is an indication of whether an interrupt source override is actually being used or not. So it could work like this: 1) Extended IRQ syntax -> Trust DSDT 2) Legacy Syntax Does polarity and trigger match the IOAPIC configuration? A) Yes -> Done B) No: a) Interrupt Source Override -> Trust ISR b) DMI override? -> Trust DMI override c) Zen system? -> Trust DSDT d) Not Zen system -> Trust IOAPIC configuration
(In reply to Mario Limonciello (AMD) from comment #7) > At least in your situation you can see that very clearly the interrupt > source override in the MADT is correct: > > [ 0.003333] ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 1 low edge) > > But your ACPI tables are incorrect (and hence the patch to the DSDT helps > the issue). > > To me it seems this issue really boils down to the logic in the kernel of > what to trust when, and there doesn't seem to be a great answer. > > Today it's something like this: > > 1) If it's extended IRQ syntax, trust the DSDT. > 2) If it's legacy syntax (IRQ/IRQNoflags) mayyyybe double check what the > MADT and the DSDT have agree. This is needed for a number of older buggy > machines. > > "2" ended up causing problems for a number of Ryzen 6000 machines because > they didn't have an interrupt source override in place and without this the > value found in the MADT was wrong (Active high) but the value in the DSDT > was right (Active Low). > > This is why we put in place a case to ignore all that and trust the DSDT on > Ryzen systems. > > You're the exact opposite of this and so that's why this logic fell apart. > > I think what we're missing is an indication of whether an interrupt source > override is actually being used or not. So it could work like this: > > 1) Extended IRQ syntax > -> Trust DSDT > 2) Legacy Syntax > Does polarity and trigger match the IOAPIC configuration? > A) Yes > -> Done > B) No: > a) Interrupt Source Override > -> Trust ISR > b) DMI override? > -> Trust DMI override > c) Zen system? > -> Trust DSDT > d) Not Zen system > -> Trust IOAPIC configuration The GPD Win 4 also has an issue when skipping the override. A user on ChimeraOS reported that when using a patched kernel I created fixed the volume buttons for them. The usable DMI for this product is the "product_name" which is "G1618-04". GPD isn't that great at being consistent with their DMI configuration outside of product names.
Created attachment 304233 [details] potential patch v1 Can you please have a try with this patch? I expect it should help your case, but it will need a lot more testing to ensure that it's not causing regressions for other systems.
(In reply to Mario Limonciello (AMD) from comment #9) > Created attachment 304233 [details] > potential patch v1 > > Can you please have a try with this patch? I expect it should help your > case, but it will need a lot more testing to ensure that it's not causing > regressions for other systems. I can confirm that this fixes the issue on the Air Plus. I have other devices I can test later as well.
Great! Yes, please document everything you can test with this including the BIOS version if possible.
(In reply to Mario Limonciello (AMD) from comment #11) > Great! > > Yes, please document everything you can test with this including the BIOS > version if possible. Sure, it may take me a bit to collect all the information, especially if we are wanting BIOS versions as well. As of right now the tested systems have been. OneXplayer Mini 5800U: No regressions (Uses the same i8042). GPD Win 4 6800U: Fixes the volume buttons. Aya Neo Air Plus 6800U: Fixes the non-gamepad "keyboard" buttons. OneXPlayer 2 6800U: This device has issues with and without the patch (Not tested by me so I can't verify if the user followed instructions correctly) Will be testing: Aya Neo 2 Aya Neo Geek OneXPlayer 1S Intel 1195G7 Potential devices that can be tested: AOKZOE A1 GPD Win Max 2 GPD Win 2
The BIOS version (and logs) is more relevant if there is a problem. Thanks for testing what you have so far. I have an internal team at AMD testing more systems as well.
The following have been tested: Lenovo Z13 HP Pro x360 435 Lenovo L14 Gen2a Lenovo P14s Gen1 HP ProBook 635 Aero G7 HP Elitebook 445 Various pre-production laptops Everything worked, but I found a mistake in the AMDI0007 override. It shouldn't be going to level sensitive, but should be going to edge sensitive instead. I'll bump the patch and drop a new version.
Created attachment 304243 [details] potential patch (v2)
I've submitted https://lore.kernel.org/linux-acpi/20230515213822.1277-1-mario.limonciello@amd.com/T/#u for discussion on this issue.
(In reply to Mario Limonciello (AMD) from comment #17) > I've submitted > https://lore.kernel.org/linux-acpi/20230515213822.1277-1-mario. > limonciello@amd.com/T/#u for discussion on this issue. Hello, I've tried the patch on fedora 38 with AMD Ryzen 7 7735HS with Radeon Graphics but the laptop keyboard is still not working. (it's not a brand laptop either, hardware model is PCSpecialist Elimina Pro 16 M)
(In reply to Vasilis Nicolaou from comment #18) > (In reply to Mario Limonciello (AMD) from comment #17) > > I've submitted > > https://lore.kernel.org/linux-acpi/20230515213822.1277-1-mario. > > limonciello@amd.com/T/#u for discussion on this issue. > > Hello, > > I've tried the patch on fedora 38 with AMD Ryzen 7 7735HS with Radeon > Graphics but the laptop keyboard is still not working. (it's not a brand > laptop either, hardware model is PCSpecialist Elimina Pro 16 M) using patch from https://bugzilla.kernel.org/show_bug.cgi?id=217394#c10 makes the keyboard work but I get an IRQ disabled and their is a noticeable lag after each keypress
> using patch from https://bugzilla.kernel.org/show_bug.cgi?id=217394#c10 makes > the keyboard work but I get an IRQ disabled and their is a noticeable lag > after each keypress Please provide an acpidump for your system and dmesg without the patch applied.
Created attachment 304337 [details] acpi_dump_no_patch I'm attaching the acpidump output with Linux fedora 6.2.15-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 17:37:39 UTC 2023 x86_64 GNU/Linux not patched and laptop keyboard not working Thanks ------- Original Message ------- On Saturday, May 27th, 2023 at 17:37, bugzilla-daemon@kernel.org <bugzilla-daemon@kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=217394 > > --- Comment #20 from Mario Limonciello (AMD) (mario.limonciello@amd.com) --- > > > using patch from https://bugzilla.kernel.org/show_bug.cgi?id=217394#c10 > makes > > the keyboard work but I get an IRQ disabled and their is a noticeable lag > > after each keypress > > > Please provide an acpidump for your system and dmesg without the patch > applied. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.
Created attachment 304338 [details] dmesg_no_patch + attaching dmesg
Created attachment 304339 [details] linux-kernel-test.patch Update: Removing +// #ifdef CONFIG_X86 +// /* +// * IRQ override isn't needed on modern AMD Zen systems and +// * this override breaks active low IRQs on AMD Ryzen 6000 and +// * newer systems. Skip it. +// */ +// if (boot_cpu_has(X86_FEATURE_ZEN)) +// return false; +// #endif works perfectly for me, keyboard is responsive
FYI I've posted a v3 of the patch to revert the heuristic. Can you please test and leave a tag on the thread (or here) if it works now? https://lore.kernel.org/linux-acpi/20230601221151.670-1-mario.limonciello@amd.com/T/#u Ideal tag would be: Tested-by: Foo Bar <foo@bar.com> # Acme XYZ Laptop
The latest patch works for me. Tested-by: Vasilis Nicolaou # PCSpecialist Elimina Pro 16 M Laptop with AMD Ryzen 7 7735HS
Thanks, it's queued up for 6.5.
(In reply to Mario Limonciello (AMD) from comment #26) > Thanks, it's queued up for 6.5. The Asus Ally uses the i8042 for the volume buttons and comes with the same IRQ ACPI problem I have with the Aya Neo Air Plus, I haven't tested the patch yet, but in theory it should fix this handheld as well. This is technically a regression from the 5.19 kernel, any chances of a back port to stable?
> This is technically a regression from the 5.19 kernel, any chances of a back > port to stable? I'm not against it; but can we wait until it's baked in the 6.5-rc's for a few weeks? Maybe around 6.5-rc3? I'm worried about causing regressions the other way around too.
Unfortunately the dropping of: ``` #ifdef CONFIG_X86 /* * IRQ override isn't needed on modern AMD Zen systems and * this override breaks active low IRQs on AMD Ryzen 6000 and * newer systems. Skip it. */ if (boot_cpu_has(X86_FEATURE_ZEN)) return false; #endif ``` As done in commit a9c4a912b7dc ("ACPI: resource: Remove "Zen" specific match and quirks") is causing keyboard problems for quite a lot of AMD based laptop users using other models, see e.g. : https://bugzilla.redhat.com/show_bug.cgi?id=2228891 https://bugzilla.redhat.com/show_bug.cgi?id=2229165 https://bugzilla.redhat.com/show_bug.cgi?id=2229317 https://bugzilla.kernel.org/show_bug.cgi?id=217718 https://bugzilla.kernel.org/show_bug.cgi?id=217726 https://bugzilla.kernel.org/show_bug.cgi?id=217731 So I have submitted a revert upstream: https://lore.kernel.org/linux-acpi/20230808103335.95339-1-hdegoede@redhat.com/ I did add an extra patch on top: https://lore.kernel.org/linux-acpi/20230808103335.95339-4-hdegoede@redhat.com/ which should keep the behavior of a9c4a912b7dc for any laptop with a line like this in dmesg: [ 0.021867] ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 1 low edge) Note the "bus_irq 1" is important here. There will also be other INT_SRC_OVR messages with a different bus_irq! If possible please give this patch-series a try: https://lore.kernel.org/linux-acpi/20230808103335.95339-1-hdegoede@redhat.com/ With this series there should still be a line like: [ 0.410670] ACPI: IRQ 1 override to edge, low(!) in dmesg for laptops which need the override (based on the INT_SRC_OVR bus_irq 1), so this patch-series should not cause a regression on the laptop from the original reporter of this bug.
Vasilis, unfortunately the dmesg you have attached for your PCSpecialist Elimina Pro 16 M Laptop does not contain an INT_SRC_OVR log line with "bus_irq 1" in there. This means that the mentioned patch-series will cause the keyboard on your laptop to stop working again, sorry. To fix this a DMI quirk will be necessary for your model. Please run: sudo dmidecode > dmidecode.txt and then send me an email with dmidecode.txt attached at hdegoede@redhat.com. (dmidecode info can contain machine serialnumbers which some users would rather keep private. Alternatively you could edit the file remove any serial numbers and then attach it here) Once I have the DMI (vendor and productname strings mostly) info for your model I can prepare a patch to add the quirk. I see that you're a Fedora user, so I'll also build you a Fedora kernel with the patch-set + quirk-patch for easy testing.
> (dmidecode info can contain machine serialnumbers which some users would > rather keep private. Alternatively you could edit the file remove any serial > numbers and then attach it here) A privacy sensitive alternative is to run this as a user (not root!) # grep -v /sys/class/dmi/id/* That will get all the strings that you can read as a user so there should be nothing sensitive in it.
A privacy sensitive alternative is to run this as a user (not root!) # grep -v /sys/class/dmi/id/* Right the output of that is fine too.
Vasilis, Thank you for emailing me the DMI strings. I've submitted a patch upstream which should keep the kbd on your laptop working even after reverting the changes which fixed it on your laptop (while breaking many others): https://lore.kernel.org/linux-acpi/20230810090011.104770-1-hdegoede@redhat.com/ I have also started a Fedora 38 6.4.9 kernel with all the related patches added test build: https://koji.fedoraproject.org/koji/taskinfo?taskID=104626985 Note this is still building atm, it should be done building in a couple of hours. Please give this a try and collect + attach dmesg with this kernel after booting it. Here are instructions for directly installing a Fedora kernel from koji (Fedora's buildsystem): https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt Thanks & Regards, Hans
Hi all, sorry to bother, but I also have a PCSpecialist Elimina 16 Pro Laptop with AMD Ryzen 7 7735HS and it looks my keyboard will keep not working with this fix: sudo dmesg | grep INT_SRC_OVR [ 0.323984] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.323992] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) sudo dmesg | grep override [ 1.556937] ACPI: IRQ 1 override to edge, high(!) I'm using a xanmod kernel, and this fix has been backported to 6.4.11 which broke my keyboard (they had dropped the #ifdef CONFIG_X86 bit before that and it worked)
(In reply to Fulvio Esposito from comment #34) > Hi all, sorry to bother, but I also have a PCSpecialist Elimina 16 Pro > Laptop with AMD Ryzen 7 7735HS and it looks my keyboard will keep not > working with this fix: > sudo dmesg | grep INT_SRC_OVR > [ 0.323984] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > [ 0.323992] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) > sudo dmesg | grep override > [ 1.556937] ACPI: IRQ 1 override to edge, high(!) > > I'm using a xanmod kernel, and this fix has been backported to 6.4.11 which > broke my keyboard (they had dropped the #ifdef CONFIG_X86 bit before that > and it worked) Please share the output of `grep -v /sys/class/dmi/id/*` as a normal user (not root)
Here it is: ~ grep -v /sys/class/dmi/id/* /sys/class/dmi/id/bios_release:1.2 /sys/class/dmi/id/bios_vendor:American Megatrends International, LLC. /sys/class/dmi/id/bios_version:N.1.13A02 /sys/class/dmi/id/board_asset_tag:Standard /sys/class/dmi/id/board_name:GM6BGEQ grep: /sys/class/dmi/id/board_serial: Permission denied /sys/class/dmi/id/board_vendor:TongFang /sys/class/dmi/id/board_version:Standard /sys/class/dmi/id/chassis_asset_tag:Standard grep: /sys/class/dmi/id/chassis_serial: Permission denied /sys/class/dmi/id/chassis_type:10 /sys/class/dmi/id/chassis_vendor:Standard /sys/class/dmi/id/chassis_version:Standard /sys/class/dmi/id/ec_firmware_release:1.12 /sys/class/dmi/id/modalias:dmi:bvnAmericanMegatrendsInternational,LLC.:bvrN.1.13A02:bd04/21/2023:br1.2:efr1.12:svnPCSpecialist:pnGM6BGEQ:pvrStandard:rvnTongFang:rnGM6BGEQ:rvrStandard:cvnStandard:ct10:cvrStandard:sku0001: grep: /sys/class/dmi/id/power: Is a directory /sys/class/dmi/id/product_family:RMB Plus /sys/class/dmi/id/product_name:GM6BGEQ grep: /sys/class/dmi/id/product_serial: Permission denied /sys/class/dmi/id/product_sku:0001 grep: /sys/class/dmi/id/product_uuid: Permission denied /sys/class/dmi/id/product_version:Standard grep: /sys/class/dmi/id/subsystem: Is a directory /sys/class/dmi/id/sys_vendor:PCSpecialist /sys/class/dmi/id/uevent:MODALIAS=dmi:bvnAmericanMegatrendsInternational,LLC.:bvrN.1.13A02:bd04/21/2023:br1.2:efr1.12:svnPCSpecialist:pnGM6BGEQ:pvrStandard:rvnTongFang:rnGM6BGEQ:rvrStandard:cvnStandard:ct10:cvrStandard:sku0001:
Fulvio, thank you for reporting this. Based on the board_name value you seem to actually have the same laptop model as Vasilis, but for some reason on your specific model product_name is set to "GM6BGEQ" (same value as the board-name) instead of "Elimina Pro 16 M" (you both have the same BIOS version, so this difference is BIOS version independent). To make the quirk for the "Elimina Pro 16 M" also work on your specific model I have submitted a patch to change the quirk to match on board_name == "GM6BGEQ": https://lore.kernel.org/linux-acpi/20230821090927.305926-1-hdegoede@redhat.com/
(In reply to Hans de Goede from comment #37) > Fulvio, thank you for reporting this. > > Based on the board_name value you seem to actually have the same laptop > model as Vasilis, but for some reason on your specific model product_name is > set to "GM6BGEQ" (same value as the board-name) instead of "Elimina Pro 16 > M" (you both have the same BIOS version, so this difference is BIOS version > independent). > > To make the quirk for the "Elimina Pro 16 M" also work on your specific > model I have submitted a patch to change the quirk to match on board_name == > "GM6BGEQ": > > https://lore.kernel.org/linux-acpi/20230821090927.305926-1-hdegoede@redhat. > com/ Hi Hans, thank you very much. Out of curiosity, as I'm not a hardware/low-level system programmer and have no idea why laptop keyboards require special handling, is there no way to get rid of all the quirks (I know this might no be the place to ask, in that case ignore my question)?
> is there no way to get rid of all the quirks ? We are still looking into that, but it is not trivial. The quirks are more of a quick fix to make things work in the short term. Long time we do indeed want to avoid the need to add more and more of these.
Hi to all, and thank you for this in-deep focused thread. I have the exactly same issue on the elimina pro 16 (don't know if "elimina pro 16m" or "GD6BGEQ"). I'm not skilled in linux and i have a very dumb question: how can i lunch the patch? i have latest linux mint OS. I kindly ask for your help and really thank you for the effort you put into solving and sharing this issue.
(In reply to arabiuga from comment #40) > Hi to all, and thank you for this in-deep focused thread. > I have the exactly same issue on the elimina pro 16 (don't know if "elimina > pro 16m" or "GD6BGEQ"). > I'm not skilled in linux and i have a very dumb question: how can i lunch > the patch? i have latest linux mint OS. > I kindly ask for your help and really thank you for the effort you put into > solving and sharing this issue. Open Cinnamon terminal (see step 2 here: https://www.fosslinux.com/103546/the-beginners-guide-to-using-terminal-on-linux-mint.htm, it should be under "Administration" in the menu) and type in the following command grep -v /sys/class/dmi/id/* look for the line in the output containing "board_name" /sys/class/dmi/id/board_name:GM6BGEQ if it's exactly like the above, you have nothing else to do as the fix is the same as for my laptop and it's queued in the kernel sources for next release. Otherwise copy and paste the entire output of the command here.
Hi! I also have a PCSpecialist Elimina Pro AMD laptop and the keyboard didn't work. I found out that my board has a slightly different name: /sys/class/dmi/id/board_name:GM6BG0Q /sys/class/dmi/id/product_family:Elimina Pro 16 M Systems /sys/class/dmi/id/product_name:Elimina Pro 16 M I read through the messages and I tried modifying /drivers/acpi/resource.c on kernel 6.5.5 and now the keyboard works! Here is the diff of my change: ``` diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index 32cfa3f4efd3..77bfa69afbb2 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -510,6 +510,13 @@ static const struct dmi_system_id pcspecialist_laptop[] = { DMI_MATCH(DMI_BOARD_NAME, "GM6BGEQ"), }, }, + { + .ident = "PCSpecialist Elimina Pro 16 M", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "PCSpecialist"), + DMI_MATCH(DMI_BOARD_NAME, "GM6BG0Q"), + }, + }, { } }; ``` Since I don't have any experience submitting patches I kindly ask if one of you could add this for me. Also I'd like to thank you all for (indirectly) making my 5-days old computer work properly. PS: I suspect that the difference in the board name reflects the 3 possible GPUs sold by PCSpecialist for this model: nvidia 3050, 4050 and 4060.
(In reply to Francesco from comment #42) > PS: I suspect that the difference in the board name reflects the 3 possible > GPUs sold by PCSpecialist for this model: nvidia 3050, 4050 and 4060. Do you by chance know the board name of the third model?
GM6BG*Q seems to be a TongFang ODM design [1], with board name GM6BG0Q for RTX 4060, GM6BG5Q for RTX 4050 and GM6BGEQ for RTX 3050. The same design is used by other vendors [2] [3] [4] and for the last one I found a report of this keyboard issue with recent Linux kernel versions [5]. So to fix this for all vendors, these board names should be added to the TongFang section without a `DMI_SYS_VENDOR` restriction. [1] https://laptopparts4less.frl/index.php?route=product/search&filter_name=GM6BG [2] https://hyperbook.pl/en/content/14-hyperbook-drivers [3] https://www.pcw.fr/portables-inote/2813-inote-gm6bg-elimina-16-amd-ryzen-r7-7735hs-ddr5-rtx-3050-a-rtx4060nouveau.html [4] https://linux-hardware.org/?computer=97054173dc3d [5] https://bbs.archlinuxcn.org/viewtopic.php?id=13313
Francesco, thanks you for reporting this, I'll try to make time today to write a kernel patch to fix this and submit the patch upstream. Do you want to be credited for reporting this in the commit message by adding: Reported-by: Francesco <xxxxxxxxx@outlook.com> to the commit msg? Note this will expose your email address to the world since commit messages are public. August thank you for the great research. I'll do as you suggest in the patch and add Suggested-by credit for you using your usual git@august..... email.
I sent an email an hour ago to PCSpecialist asking for providing me the board names but it seems that the problem solved itself thanks to August! I'll let you know if something different comes out from PCSpecialist. (In reply to Hans de Goede from comment #45) > Do you want to be credited for reporting this in the commit message by > adding: > > Reported-by: Francesco <xxxxxxxxx@outlook.com> > > to the commit msg? Note this will expose your email address to the world > since commit messages are public. Yes I would like that, thank you very much.
Sorry for being a bit slow. I've submitted the patch adding the necessary quirks for the TongFang GM6BGEQ, GM6BG5Q and GM6BG0Q models upstream now: https://lore.kernel.org/linux-acpi/20231006123304.32686-1-hdegoede@redhat.com/
Thank you all for all the work done, this fix was very important! PS: PCSpecialist did not provide me a confirmation for the RTX4050 board GM6BG5Q, they kept confirming the name of my board (GM6BG0Q) although I was very direct and specific; from my mail (subject - Elimina Pro 16 AMD board-name question): [...] "I ask if you can confirm (from your internal inventory database) that the board name of the following is indeed correct: Elimina Pro 16 M, with Nvidia RTX 4050 - board name (or TF-Model): GM6BG5Q" [...] Anyway, I think the research done by August is exaustive and final on the matter.