[RESOLVED] On wake screen whatever key I pressed stays engaged

FW13 AMD, Fedora 39, everything up-to-date.

I have power options set so the screen blanks after five minutes when plugged in, but it doesn’t suspend. As of the last couple of days whatever key I press to wake the screen stays engaged. So if it opens to a browser, after I press space, the page it’s on will scroll to the bottom. If I click into the address bar it spaces along infinitely.

I just tested with enter and it’s doing the same.

Alt-tabbing to another app and back solves it, but it’s a bit weird this has started 100% of time I wake the screen.

Not sure I follow. Bear with me.

Plugged in, suspended. Press a key to wake the laptop, but, it stays engaged…in a suspended state? Pressing enter also leaves the laptop in a suspended state while attached to power?

If the above is correct, please download and run this as follows:

  • Unattached everything except AC power to the USB-C expansion card; no displays, mice, etc.

  • Is the behavior still happening? If so, please list which kernel you are using and then download/run the following:

sudo python3 amd_s2idle.py

Paste the results to this thread.

I haven’t explained properly, sorry.
When it’s plugged in the screen is set to go off after five minutes, but the computer is not suspended. Closing the lid does that. So this is just screen-off.

I tap a key to get the screen back and whatever key I press acts like I’m holding it down. Space, enter, and shift all doing the same at least. Presume similar for entire keyboard, but haven’t tested others yet.

Kernel: Linux 6.7.4-200.fc39.x86_64

My apologies for misunderstanding. So basically screen time out, as expected. You’re waking up the dark screen from time out, not from suspend. Got it.

Sounds like something may be up with the keyboard itself.

Let’s run through some OS related possibilities first.

  • Settings, Accessibility, is this on or off? If it’s on, make sure “Repeat keys” isn’t enabled (in case there is a bug here).

  • Before this issue presents itself, open a terminal, run journalctl -f and then with it open, allow the screen to go black and time out. Now wake the screen up and look to the terminal running journalctl -f, are we seeing anything being spammed through the logs? If so, take a photo of it with a smart phone and share it here.

  • Boot to a live USB of Fedora, repeat the behavior. Is this happening in a live environment? If so, continue to hardware.

Running though hardware possibilities.

  • If after trying everything above, the next step is to detach the keyboard and reattach it. Does the behavior continue? If it does, it would be time to get a ticket opened on this as it may be a fault with the input kit.

I just opened it up and tried reseating the input cable, but that didn’t help.

Testing again with journalctl -f. Results here, from initiating to awakening screen with spacebar:

$ journalctl -f
Feb 27 12:05:43 framework audit: BPF prog-id=88 op=UNLOAD
Feb 27 12:05:43 framework audit: BPF prog-id=87 op=UNLOAD
Feb 27 12:05:43 framework audit: BPF prog-id=86 op=UNLOAD
Feb 27 12:05:49 framework PackageKit[8435]: get-updates transaction /2033_aecbcaac from uid 1000 finished with success after 106ms
Feb 27 12:05:54 framework PackageKit[8435]: get-updates transaction /2034_cacacbde from uid 1000 finished with success after 98ms
Feb 27 12:06:05 framework protonvpn-app.desktop[2835]: 2024-02-27T20:06:05.791385 | proton.vpn.session.utils:25 | INFO | API:REQUEST | '/vpn/loads'
Feb 27 12:06:07 framework protonvpn-app.desktop[2835]: 2024-02-27T20:06:07.646830 | proton.vpn.session.utils:29 | INFO | API:RESPONSE | '/vpn/loads'
Feb 27 12:06:07 framework protonvpn-app.desktop[2835]: 2024-02-27T20:06:07.785608 | proton.vpn.app.gtk.services.refresher.server_list_refresher:126 | INFO | Next server list refresh scheduled in 0:15:56.334292
Feb 27 12:06:48 framework kernel: i2c_hid_acpi i2c-FRMW0005:00: i2c_hid_get_input: incomplete report (7/65535)
Feb 27 12:07:03 framework systemd[2333]: app-flatpak-org.signal.Signal-4832.scope: Consumed 5.192s CPU time.
Feb 27 12:09:20 framework NetworkManager[1212]: <info>  [1709064560.7233] dhcp4 (wlp1s0): state changed new lease, address=192.168.157.141
Feb 27 12:09:20 framework systemd[1]: Starting NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service...
Feb 27 12:09:20 framework systemd[1]: Started NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service.
Feb 27 12:09:20 framework audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 27 12:09:30 framework systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Feb 27 12:09:30 framework audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 27 12:09:59 framework wpa_supplicant[1875]: wlp1s0: Reject scan trigger since one is already pending
Feb 27 12:10:04 framework PackageKit[8435]: get-updates transaction /2035_ddbbeeba from uid 1000 finished with success after 108ms
Feb 27 12:10:13 framework PackageKit[8435]: get-updates transaction /2036_eaabebea from uid 1000 finished with success after 100ms
Feb 27 12:10:34 framework PackageKit[8435]: get-updates transaction /2037_dacdadcc from uid 1000 finished with success after 99ms
Feb 27 12:10:39 framework PackageKit[8435]: get-updates transaction /2038_bcecccde from uid 1000 finished with success after 98ms
Feb 27 12:12:28 framework rtkit-daemon[1091]: Successfully made thread 2599 of process 2561 (/usr/bin/gnome-shell) owned by '1000' high priority at nice level 0.
Feb 27 12:12:28 framework rtkit-daemon[1091]: Successfully made thread 2599 of process 2561 (/usr/bin/gnome-shell) owned by '1000' RT at priority 20.
Feb 27 12:12:28 framework dropbox[3038]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Feb 27 12:12:28 framework protonvpn-app[2835]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
 Feb 27 12:12:54 framework NetworkManager[1212]: <info>  [1709064774.4134] agent-manager: agent[0df3f4c533037f94,:1.90/org.gnome.Shell.NetworkAgent/1000]: agent registered
Feb 27 12:12:54 framework rtkit-daemon[1091]: Successfully made thread 2599 of process 2561 (/usr/bin/gnome-shell) owned by '1000' high priority at nice level 0.
Feb 27 12:12:54 framework rtkit-daemon[1091]: Successfully made thread 2599 of process 2561 (/usr/bin/gnome-shell) owned by '1000' RT at priority 20.
                            

I have a video of the Terminal on wake, but it’s just the above with the cursor spacing across endlessly.

I’ll try USB boot next and will update. Thanks.

Ok tried the USB boot and the problem does not happen in that state. I tried a few times, with the only anomaly being the second time when the screen did not wake, but I could tell it was receiving keyboard inputs because I had Text Editor open and holding the cursors down caused it to start beeping at the end of lines.

Toggling the power button got the screen to wake and I could see the keys I’d been pressing.

I tried a couple more times after that, thinking I’d found a new problem, but could not replicate. It just worked fine.

So it’s something to do with my current installation/configuration. The install is quite fresh as I had the emergency boot issue a couple of weeks ago, so had to reinstall.

I do not have Accessibility engaged.

And on closer inspection I see that I did not have Accessibility Menu engaged, and since I’d never set any Accessibility options I thought that was all switched off. Then I happened to see a good solution for blurry text with fractional scaling (set scaling to 100% and switch on Large Text in Accessibility) and I realized some settings are engaged by default, including Repeat Keys.

Tested with this off and on again and that is indeed the problem. That setting has a bug on screen wake-up initiation.

Thanks again for your help. Hopefully one day I’ll start to follow instructions properly.

2 Likes

Thanks for updating the thread @phrwn , glad it got resolved with Matt’s help. changing status to resolve. :slight_smile:

1 Like