Laptop 16, AMD Ryzen AI 7 350, X11, lxterminal, and Delayed Keystrokes

This is an “FYI” for anyone running LXDE on a Laptop 16 with the AMD Ryzen AI 7 350 CPU.

I encountered this on a Devuan Excalibur installation, but it should also apply to Debian and its other derivatives.

With LXDE as the desktop environment, and with an instance of “lxterminal” running, if “Hide mouse pointer” is enabled (from “Edit → Preferences → Display”), not all keystrokes will be shown after the mouse pointer auto-hides; they only show up after the mouse pointer is moved after typing.

To reproduce the issue, with “Hide mouse pointer” enabled in that lxterminal window, type a few characters, then wait for the mouse pointer to disappear. Type a few more characters, and only the first one will show up; the others won’t show until the mouse pointer is moved.

After a couple of weeks of investigating with an AI assistant (which consistently and confidently suggested solutions which didn’t work), I finally noticed today that the issue didn’t start until the mouse pointer auto-hid. (The AI never thought of this, so +1 for humans. :slight_smile:)

My Intel-based desktop, with the same LXDE version, does not have this issue. After feeding that data point back to the AI, it suggested that the issue is due to the AMD Ryzen AI 7 350 using “AMD’s new DCN (Display Core Next) display controller generation. This hardware has well-documented bugs when paired with the amdgpu kernel driver under X11, particularly regarding hardware cursor rendering…”

The AI suggested this X11 config, named “/etc/X11/xorg.conf.d/10-amdgpu.conf”:

Section "OutputClass"
   Identifier "AMDgpu"
   MatchDriver "amdgpu"
   Driver "amdgpu"
   Option "SWCursor" "True"
EndSection

I implemented this suggestion, rebooted (even though an X11 restart should have sufficed), and confirmed that “Hide mouse pointer” works as expected without the keystroke delays.

So, if you use lxterminal on a Laptop 16 with the AMD Ryzen AI 7 350 CPU and like using “Hide mouse pointer”, this seems to be a decent workaround until the alleged “amdgpu kernel driver under X11” bug(s) are worked out.

--Dave

1 Like

This sounds like the bugs I had with amdgpu variable refresh rate (PSR?). Somehow typing does not trigger a screen refresh, so you see the same image even though the system has actually received the input (no actual input delay!). Moving the mouse then refreshes the screen and the letters you types appear as well.

You might want to try kernel parameters that disable those VRR features, IIRC amdgpu.ppfeaturemask=0xf3fff would do that but there seem to be more features you could try masking out. Check drivers/gpu/drm/amd/include/amd_shared.h in kernel sources for the full list in enum PP_FEATURE_MASK.

Heh – the AI did suggest things like checking the refresh rate, disabling “TearFree”, disabling various power-management settings, adding kernel-boot options, messing with “ppfeaturemask”, and other things which seemed to me like grasping at straws. (I didn’t mess with “ppfeaturemask” because it seemed like overkill at the time, and the other AI suggestions had no effect.)

One good AI-suggested test was running “evtest” via SSH from the desktop to the Laptop 16; that showed that the keystrokes were always being received by the kernel without delay. And that pointed back to something in the desktop environment.

The above “10-amdgpu.conf” fix works for this particular issue (mouse pointer hiding causes keystroke delays) without causing any other noticeable issues, but I’ll certainly dig into the other amdgpu module params (“ppfeaturemask” and what-not) if I encounter other issues on my Laptop 16 which don’t show on my desktop.

I just checked the kernel source again myself. Besides ppfeaturemask there seems to be dcfeaturemask as well and also dcdebugmask.

There might be some overlap between those masks. amdgpu.dcdebugmask=0x10 disables the panel self refresh (PSR) functionality - while the ppfeaturemask flags (de)activate certain clock adjustments (which I suppose are needed for PSR). So you might have the same result with different combinations of masks.

I am currently using amdgpu.dcdebugmask=0x10 because of flickering artifacts. It is said to increase power draw a bit though. You could try if it works for you as well.

The problem with the config file you mentioned is that it only works for X11 which AFAIK is not really well maintained anymore because most distros are moving to wayland. But maybe your problem only happens in X11 anyways so it is fine.

I also remember that a while ago software cursors were severely impacting performance of a system I was using. But that might have changed.