Trackpad Scrolling Not Smooth on 2022 Blade 15 and 17

Confirming that this issue is not fixed. I’ve been complaining about it ever since I purchased my computer from Razer and their support has been insanely unhelpful about it. I only recently discovered that many others are having this issue and have followed much of the advice in that thread the OP mentioned. But obviously, would be great for Razer to fix this issue themselves.

I have been running that fix in task scheduler and I haven't even thought about it until this reply came up. If you are running Linux there is also a similar fix for that as well.

Hi guys,

Thanks for bringing this problem to our attention. I sent you a message asking for information that I can use to escalate your concern to the relevant team for further diagnosis and advanced resolution. Looking forward to hearing back from you soon. 

Yes unfortunately I already went through support and filmed a video showing it does occur on the original factory image. I am still waiting for a proper fix like a firmware update.

I don’t think replacing the touchpad will fix the issue, right?

Because Razer asked me to send it back to fix it.

Unfortunately it won't 

Hey all, pasting this fix after a bashing the problem with claude ai on fedora linux. also pasted it in this gitlab thread here. basically it falls back to another device, and the problem happened for me on windows too. this approach is different because it detects when the trackpad messes up and runs the fix, instead of running it periodically. i believe a windows user can paste this into claude and work with it to bring it to windows as well. hope it helps someone.

Adding my experience as a possible data point on the grounding/electrical hypothesis that's come up several times in this thread, along with an automated mitigation that might help others.

My hardware: ELAN0406:00 04F3:30A6 (different chip from the 04F3:311C most people here have). My fault is triggered by physical pressure on the chassis following a battery replacement, so my root cause is more obviously mechanical. That said, the failure mode shares characteristics with what's described here: no palm rejection, no multitouch/gestures, oversensitive raw cursor movement, no kernel log output when it breaks, and the device stays fully enumerated with identical sysfs capabilities in both states.

The detectable signal: The ELAN driver exposes two event nodes, Mouse and Touchpad. When working normally, Touchpad produces data and Mouse is silent. When broken, they swap. The recovery is a sysfs rebind:

echo -n "i2c-ELAN0406:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind
echo -n "i2c-ELAN0406:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind

(adjust the device name for your hardware — check ls /sys/bus/i2c/drivers/i2c_hid_acpi/)

Automated detection daemon (/usr/local/bin/tp-check):

#!/usr/bin/env bash

last_tp_activity=$SECONDS
last_mouse_activity=0

while true; do
  mouse=$(grep -A5 "ELAN.*Mouse\"" /proc/bus/input/devices | grep -oP 'event\d+' | tail -1)
  touchpad=$(grep -A5 "ELAN.*Touchpad\"" /proc/bus/input/devices | grep -oP 'event\d+' | tail -1)

  timeout 0.3 cat /dev/input/$mouse    2>/dev/null > /tmp/tp_mouse &
  timeout 0.3 cat /dev/input/$touchpad 2>/dev/null > /tmp/tp_touch &
  wait

  mouse_bytes=$(wc -c < /tmp/tp_mouse)
  tp_bytes=$(wc -c < /tmp/tp_touch)

  [[ $mouse_bytes -gt 0 ]] && last_mouse_activity=$SECONDS
  [[ $tp_bytes   -gt 0 ]] && last_tp_activity=$SECONDS

  mouse_silent=$(( SECONDS - last_mouse_activity ))
  tp_silent=$(( SECONDS - last_tp_activity ))

  if (( tp_silent > 1 && mouse_silent < 2 )); then
    echo "$(date): fault detected, resetting..."
    echo -n "i2c-ELAN0406:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind
    echo -n "i2c-ELAN0406:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind
    last_tp_activity=$SECONDS
    sleep 2
  fi
done

Systemd service (/etc/systemd/system/tp-check.service):

[Unit]
Description=Touchpad fault detector and reset
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/local/bin/tp-check
Restart=always
RestartSec=1

[Install]
WantedBy=multi-user.target

chmod +x /usr/local/bin/tp-check
systemctl enable --now tp-check

This is similar in spirit to what @ryan910 mentioned with modprobe -r hid_multitouch, but targets the specific device and recovers automatically without disturbing other input devices. It won't help anyone whose fault doesn't produce the Mouse/Touchpad node swap — but if you're curious whether your sluggish episodes correlate with that signal, it's easy to check manually with cat /proc/bus/input/devices during a fault.

This is a workaround, not a fix. The underlying issue for most people here is almost certainly still in the touchpad firmware or i2c layer as discussed at length above.