Created attachment 1879628 [details] HP Laptop 15s-fq4020TU Spec Description of problem: I just installed F36 on my HP Laptop (15s-fq4020TU) ProdID: 50R86PA#ABG. This is a brand new HP laptop purchased March 27,2022. In anaconda the keyboard didn't respond for about 2 minutes and then suddenly started working. The install went fine. This is a dual boot system and I was able to boot Windows or Fedora. When I boot Fedora and it asks for the encryption key, sometimes the keyboard doesn't work. I have to sometimes boot 5 or 6 times for the keyboard to work so that I can enter the encryption key. Sometimes if I wait 5 minutes the keyboard comes alive. I have also found when coming out of a suspend the keyboard is dead, but if I wait 5 minutes it comes alive. If I suspend the laptop several times I can get the keyboard working. This looks like a keyboard driver problem, but couldn't find a component for that. Version-Release number of selected component (if applicable): How reproducible: This is a very reproducible problem. Additional info: Windows 11 doesn't have a problem with the keyboard. Once the keyboard is working, it is working with no further problems.
Created attachment 1879797 [details] lsusb, dmesg listings The keyboard shows up several times in the dmesg listing
I have similar problems with HP Laptop 15s-fq2xxx/87FE, BIOS F.07 12/01/2020 Always after boot or hibernate the keyboard wakes up at ramdom times. its been like this since new, I mash the keys till it responds it can take minutes.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
still here in F39.
It turns out that adding i8042.nopnp to the kernel solves this issue for me so far :-) why it took three years for me to find & try this info is another question.
> It turns out that adding i8042.nopnp to the kernel solves this issue for me so far :-) why it took three years for me to find & try this info is another question. That is good news, lets wait a couple more days and see if this really fixes things. If this really fixes things, can you then please run the following command (as a normal user, not as root) : grep . /sys/class/dmi/id/* 2>/dev/null And copy and paste the output of that command here? Then I can write a patch for the kernel to make i8042.nopnp the default on your laptop model.
Glad to hear this problem may be fixed. Here are my details. [dan@laptop ~]$ grep . /sys/class/dmi/id/* 2>/dev/null /sys/class/dmi/id/bios_date:03/21/2022 /sys/class/dmi/id/bios_release:15.21 /sys/class/dmi/id/bios_vendor:AMI /sys/class/dmi/id/bios_version:F.21 /sys/class/dmi/id/board_asset_tag:Base Board Asset Tag /sys/class/dmi/id/board_name:89BC /sys/class/dmi/id/board_vendor:HP /sys/class/dmi/id/board_version:57.53 /sys/class/dmi/id/chassis_type:10 /sys/class/dmi/id/chassis_vendor:HP /sys/class/dmi/id/chassis_version:Chassis Version /sys/class/dmi/id/ec_firmware_release:57.53 /sys/class/dmi/id/modalias:dmi:bvnAMI:bvrF.21:bd03/21/2022:br15.21:efr57.53:svnHP:pnHPLaptop15s-fq4xxx:pvr:rvnHP:rn89BC:rvr57.53:cvnHP:ct10:cvrChassisVersion:sku50R86PA#ABG: /sys/class/dmi/id/product_family:103C_5335KV HP Notebook /sys/class/dmi/id/product_name:HP Laptop 15s-fq4xxx /sys/class/dmi/id/product_sku:50R86PA#ABG /sys/class/dmi/id/sys_vendor:HP /sys/class/dmi/id/uevent:MODALIAS=dmi:bvnAMI:bvrF.21:bd03/21/2022:br15.21:efr57.53:svnHP:pnHPLaptop15s-fq4xxx:pvr:rvnHP:rn89BC:rvr57.53:cvnHP:ct10:cvrChassisVersion:sku50R86PA#ABG: [dan@laptop ~]$
Ok this setup gets me 100% boot & sleep wake up availability but I loose my capslock LED which I'll accept. i8042.nopnp i8042.dumbkbd /sys/class/dmi/id/bios_date:12/01/2020 /sys/class/dmi/id/bios_release:15.7 /sys/class/dmi/id/bios_vendor:AMI /sys/class/dmi/id/bios_version:F.07 /sys/class/dmi/id/board_asset_tag:Base Board Asset Tag /sys/class/dmi/id/board_name:87FE /sys/class/dmi/id/board_vendor:HP /sys/class/dmi/id/board_version:57.15 /sys/class/dmi/id/chassis_type:10 /sys/class/dmi/id/chassis_vendor:HP /sys/class/dmi/id/chassis_version:Chassis Version /sys/class/dmi/id/ec_firmware_release:57.15 /sys/class/dmi/id/modalias:dmi:bvnAMI:bvrF.07:bd12/01/2020:br15.7:efr57.15:svnHP:pnHPLaptop15s-fq2xxx:pvr:rvnHP:rn87FE:rvr57.15:cvnHP:ct10:cvrChassisVersion:sku30A26EA#AB : /sys/class/dmi/id/product_family:103C_5335KV HP Notebook /sys/class/dmi/id/product_name:HP Laptop 15s-fq2xxx /sys/class/dmi/id/product_sku:30A26EA#ABU /sys/class/dmi/id/sys_vendor:HP /sys/class/dmi/id/uevent:MODALIAS=dmi:bvnAMI:bvrF.07:bd12/01/2020:br15.7:efr57.15:svnHP:pnHPLaptop15s-fq2xxx:pvr:rvnHP:rn87FE:rvr57.15:cvnHP:ct10:cvrChassisVersion:sku30A6EA#ABU:
Thank you both for the DMI strings. Dan so I take it that things work 100% for you with just the nopnp option? Dex, can you try using the following on the commandline instead ? : i8042.nopnp i8042.nomux And if that does not help try: i8042.nopnp i8042.nomux i8042.reset i8042.noloop This will hopefully fix things without needing the dumbkbd option.
OK, Here is what I have tried. i8042.nopnp i8042.nopnp i8042,dumpkbd i8042.nopnp i8042.nomux i8042.nopnp i8042.nomux i8042.reset i8042.noloop Nothing seems to work
(In reply to Dan from comment #11) > OK, Here is what I have tried. > i8042.nopnp > i8042.nopnp i8042,dumpkbd > i8042.nopnp i8042.nomux > i8042.nopnp i8042.nomux i8042.reset i8042.noloop > > Nothing seems to work What happens if you just try "i8042.nomux" ? Also note that at least above you made 2 typos in i8042.dumbkbd there needs to be a . in between not a , and it is dumb not dump. Unfortunately the dmesg log which you have attached is truncated and thus not really useful. Please reboot the machine (to make sure that the begin of boot is still in the ringbuffer) and then run: "dmesg > dmesg.txt" and attach the generated dmesg.txt file here.
I tried just i8042.nomux but it didn't fix the problem. Good news: I tried i8042.nopnp i8042.dumbkbd again and it works great. I must have mistyped i8042.dumbkbd on the boot command line as well before.
> Good news: I tried i8042.nopnp i8042.dumbkbd again and it works great. I must have mistyped i8042.dumbkbd on the boot command line as well before. That is good news and thank you for testing. As dex mentioned that breaks the capslock LED. I guess we could live with that, but I hope we can find a better solution. dumbkbd disables all writes to the kbd, including setting of the LEDs. I doubt the actual setting of a LED is the issue . dumbkd really only influences the atkbd driver. I have written a quick hack for the atkbd driver to skip probing (as it does with dumbkbd) while keeping the LED functionality. I hope that this way we can fix things without breaking the capslock LED. I have started a Fedora kernel test build with my quick hack added: https://koji.fedoraproject.org/koji/taskinfo?taskID=106491356 Note this is still building atm, it should be finished in a couple of hours. Please give it a test-run when it is done building. Please test both with and without i8042.nopnp . Note the patched kernel replaces i8042.dumbkbd so please do no use that (and please check that the capslock LED works). Also please test things still work ok after a suspend/resume with this patched kernel. Here are some instructions for installing a kernel directly from koji (Fedora's buildsystem): https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
Note the test kernel has finished building and is available for download now.
I'm getting this error [sudo] password for dan: error: Failed dependencies: systemd >= 254-1 is needed by kernel-debug-uki-virt-6.5.4-200.rhbz2086156.fc38.x86_64 systemd >= 254-1 is needed by kernel-uki-virt-6.5.4-200.rhbz2086156.fc38.x86_64 [dan@laptop keyboard-kernel]$ I have all the latest updates and just rebooted on latest kernel
(In reply to Dan from comment #16) > I'm getting this error > > [sudo] password for dan: > error: Failed dependencies: > systemd >= 254-1 is needed by > kernel-debug-uki-virt-6.5.4-200.rhbz2086156.fc38.x86_64 > systemd >= 254-1 is needed by > kernel-uki-virt-6.5.4-200.rhbz2086156.fc38.x86_64 > [dan@laptop keyboard-kernel]$ > > I have all the latest updates and just rebooted on latest kernel Note you don't need to install all of the packages, as explained in: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt You only need the kernel-core-<version>.x86_64.rpm and kernel-modules-<version>.x86_64.rpm files. The uki support is new and I guess this only works in f39/rawhide .
Good News your patched kernel works great with and without i8042.nopnp. I must have tried 20 suspend/resume and works great. There is a minor issue the the caps lock key. Every second suspend/resume the caps lock key comes on and I didn't press it. The caps lock must be pressed twice in order for the LED to go out. The caps lock keys works otherwise as expected. This is true with and without i8042.nopnp. Thank you. Thank you. Thank you
Created attachment 1990153 [details] grub error
I cant seem to load this test kernel
Sorry ignore that... I have secure boot. re-doing... :-)
> There is a minor issue the the caps lock key. Every second suspend/resume the caps lock key comes on and I didn't press it. The caps lock must be pressed twice in order for the LED to go out. The caps lock keys works otherwise as expected. This is true with and without i8042.nopnp. Ok, so I assume that when the capslock key LED is on after suspend resume, things still behave as if capslock is off, right. IOW when you type normally you still type lowercase I assume ? This would also explain why you need to press capslock twice to turn the LED off, the capslock state is a software state tracked by Linux, so the first time you press it Linux changes its internal state to "capslock on" and tells the keyboard to turn the LED on (which is a no-op since it is already on). Then on the second press Linux changes its internal state to capslock off and tells the keyboard to turn the LED off, which actually turns the LED off. This should be easy enough to remedy by patching the kernel to restore the LED state even when modern s2idle suspend is used (currently it only restores the LED state for old style S3 suspend). But first I would like to focus on getting my current hack turned into a proper patch, which can be submitted upstream. I'm going to have to ask for some patience from the both of you as we figure out how to resolve this properly. I hope to be able to fix this without needing to add a model specific quirk to the kernel, but that means that I'll be throwing test kernels at you until we have something that works. Also I'll be travelling for work next week, so I might be a bit slow with responding next week. In the mean time you can keep using i8042.dumbkbd with normal kernels (I expect that i8042.pnp is not needed with normal kernels either, only i8042.dumbkbd should be enough).
You are correct, after suspend/resume and the caps lock LED is on, it is displaying lower case. Pressing the caps lock key it changes to displaying upper case and the the LED stays on. Pressing the caps lock key again the LED goes off and we are in lower case. I would be glad to test any additional test kernels.
Created attachment 1990211 [details] [PATCH] atkbd skip probe HACK for HP pavilion laptops rhbz#2086156 Dan, dex this is mostly a note to myself / for documentation purposes: For future reference, this is the test patch / hack from the first test kernel which mostly fixes the problem. Except for the capslock LED issue on resume. I suspect that the capslock LED issues comes from me missing that I needed to also disable a second set of atkbd_probe() and atkbd_activate() calls in atkbd_reconnect() which runs on resume. Note that arguably atkbd_reconnect() should not run at all on resume() on s2idle systems. i8042.c has the following in its resume() function: ``` /* * If platform firmware was not going to be involved in suspend, we did * not restore the controller state to whatever it had been at boot * time, so we do not need to do anything. */ if (!pm_suspend_via_firmware()) return 0; ``` So i8042.c deliberately does not touch the PS/2 controller on s2idle resume, yet the serio core will still call atkbd_reconnect() on resume, which I suspect is the cause of a lot of recent PS/2 laptop keyboard issues which we have been seeing.
Created attachment 1990227 [details] [PATCH] Input: atkbd - add atkbd_deactivate_fixup for HP laptop 15s-fq* laptops Dan, dex, Here is a new test-kernel with the attached patch which disables part of the atkbd-probe path (1) using an existing quirk mechanism for issues on some "LG Electronics" laptops. Hopefully this disables the part which confuses your keyboards; with some luck this will also help with the capslock LED being on after suspend/resume issue: https://koji.fedoraproject.org/koji/taskinfo?taskID=106585715 Note this is still building atm, it should be finished in a couple of hours. Please give it a test-run when it is done building (install instructions: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt) . Regards, Hans 1) Which was completely disabled in the previous test kernel
Note the second test kernel has finished building and is available for download now.
Bad news, this new test kernel behaves exactly like the original problem. With or without i8042.nopnp there is long delay before the keyboard becomes active. There are no problems with the caps lock key.
Yep I concur.
> Bad news, this new test kernel behaves exactly like the original problem. With or without i8042.nopnp there is long delay before the keyboard becomes active. There are no problems with the caps lock key. Ok, so now we know that the ATKBD_CMD_RESET_DIS command is not the issue. I was hoping that it was because a) there already is a quirk to disable it on some laptops b) it is a relatively recent addition to the atkbd driver. Doing a kernel build per command is going to be a very slow and tedious process, so instead I've written a patch to add a new atkbd.skip_writes parameter which takes an integer value which gets interpreted as a bit-field which each bit disabling (skipping) a specific write. I am working on starting a kernel test-build with the patch adding the atkbd.skip_writes parameter, but the hotel wifi is slow with uploading the sources so I'll add a separate comment with the build once the upload is done and the build has started. After installing this, start with adding: "atkbd.skip_writes=0x3f" to the kernel commandline for the bz2086156_3 kernel and then test with that (verify with "cat /proc/cmdline"). I expect that to fix things in the same way as my first test kernel fixed things. Once it is confirmed that atkbd.skip_writes=0x3f works, it is time to re-enable various writes 1 by 1 and find the write(s) which cause trouble. To do this replace 0x3f with the following values, trying one value at a time and write down for each value of the kbd works immediately after boot or not: 0x1f 0x2d (not writing the activate command also requires not writing the de-activate command) 0x37 0x3b 0x3d 0x3e Then once you get back with the results from there I'll give you a minimal skip_writes value to pass, and then we will see from there. Note if you know binary / hex counting feel free to try and construct a minimal value yourself after the tests and test that right away.
New test kernel with the atkb.skip_writes parameter is available here now: https://koji.fedoraproject.org/koji/taskinfo?taskID=106641443 Note it is already done building this time, so you can download it right away.
Created attachment 1990364 [details] [PATCH] Input: atkbd - add skip_writes module parameter This is the patch used in the last (3th) test kernel.
It seems in my tests so far that the lsb is responsible for boot delay: 0x0f 00001111 no delay 0x0e 00001110 delay 0x1f 00011111 no delay 0x1e 00011110 delay 0x2f 00101111 no delay 0x2e 00101110 delay 0x3f 00111111 no delay 0x3e 00111110 delay
My results are a different from dex. 0x3f - Works - caps lock ok 0x1f - Works - caps lock ok 0x2d - Works - caps lock ok 0x37 - Works - caps lock ok 0x3b - Works - caps lock ok 0x3d - Works - caps lock ok 0x3e - delay after suspend/resume (original problem) - caps lock ok With all my testing I had no problems with the caps lock key.
Dan, dex, Thank you for testing. Just to confirm the results, can you both try with "atkbd.skip_writes=0x01", I expect that to fix the issue by skipping the ATKBD_CMD_GETID command which your laptop seems to not like.
This works great and no caps lock key problems. Congratulations Hans.
Yep 0x01 no delay, caps lock is good.
Thank you for confirming that "atkbd.skip_writes=0x01" fixes things. I have prepared a new patch series which should hopefully be acceptable upstream. Here is another Fedora test kernel build with the patch series intended for upstream added: https://koji.fedoraproject.org/koji/taskinfo?taskID=107055263 Note this is still building atm, should be done in a couple of hours. Please give this a try and let me know if this latest bz2086156_4 test-kernel works out of the box.
Created attachment 1992031 [details] [PATCH 1/3] Input: atkbd - add skip_commands module parameter Here are the patches from the latest test-kernel.
Created attachment 1992032 [details] [PATCH 2/3] Input: atkbd - drop atkbd_skip_deactivate flag
Created attachment 1992033 [details] [PATCH 3/3] Input: atkbd - set skip_commands = ATKBD_SKIP_GETID for
Works perfectly out of the box. Many many thanks for your attention to fixing this defect.
(In reply to Dan from comment #41) > Works perfectly out of the box. Many many thanks for your attention to > fixing this defect. Thank you for testing I have submitted the patches for this upstream now: https://lore.kernel.org/linux-input/20231005201544.26983-1-hdegoede@redhat.com/
Yep tested & working no delays caps lock good.
I have posted a new, more generic approach at fixing this upstream: https://lore.kernel.org/linux-input/20231106155429.5377-1-hdegoede@redhat.com/
Hans, would you like me to test this change? I tried kernel-6.5.9-200.fc38.x86_64 but it still has the problem. Any idea what kernel will have your change?
> Hans, would you like me to test this change? The code flow with the new patch is exactly the same as before, so I don't believe that retesting on your laptop is necessary. Since posting the original series I've learned that a lot more laptop models are affected (at least 10 different models from HP and Lenovo) and I realized that the workaround is harmless for machines which do not need it. So the new patch simply enables the workaround everywhere leading to a much simpler and smaller patch and this means it should fix this issue once and for all on all laptops. > I tried kernel-6.5.9-200.fc38.x86_64 but it still has the problem. Yes that unfortunately is expected. For now you may want to use the "i8042.dumbkbd" workaround, assuming you don't care much about the capslock LED working. > Any idea what kernel will have your change? Dmitry the input system maintainer unfortunately does not have a lot of time to review patches lately, so nothing has happened yet wrt the patches. I would like to get the new simple fix upstream soon. So if nothing has happened in say a week from now I'll try pinging Dmitry and then we'll see from there.
Hans, I tried kernel-6.6.9-200.fc39.x86_64 and still doesn't have your change. Any idea what future kernel will have your change?
Hi Dan, Sorry about this taking so long. Good news the fix for this has landed in 6.7 final. If you want you can grab it from koji and give it a test run: https://koji.fedoraproject.org/koji/buildinfo?buildID=2342369 Install instructions: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt. Note since this is actually an official build you don't need to disable secure boot for it.
Hi Hans, This is great news. I tried 6.7 final and it works with no problems. Thank you Hans
(In reply to Dan from comment #49) > This is great news. I tried 6.7 final and it works with no problems. > Thank you Hans You're welcome and thank you for all the testing and for your patience with resolving this bug. Since you have confirmed that this is fixed in rawhide now lets close this. An official 6.7.y kernel update for F38 / F39 should happen in a couple of weeks from now.
Works for me 6.7.4 F39 Thanks for coming off topic, 6.7.x also returned a mute LED I never knew I had :-) life is good. oh wait I still have an out of tree wifi driver rtl8821ce :-( Thanks again.