The cursor will not move: how to fix the input layer
Symptom, cause and fix for the input layer: a dead cursor, jitter, a missing COM port, a cheat that will not connect, passthrough that kills the real mouse, double inputs and wrong sensitivity.
Short answer
First prove that your own mouse moves the cursor through the device, then prove the second PC can open the link. Most input faults come from the wrong socket, a missing serial driver, a mismatched COM port or baud rate, or a charge-only cable.
On this page8
Which half of the chain is broken?
The input layer has two independent halves, and almost nobody tests them separately, which is why these faults take hours instead of minutes. The HID half is your hand: the physical mouse goes into the device, the device goes to the game PC, and the cursor moves. The control half is the cheat: the second PC sends commands over serial or IP into the device, and the cursor moves without your hand. One question tells you which half is broken: does your own mouse move the cursor? If it does, the HID half is fine, and every remaining problem is drivers, ports or configuration on the second PC. If it does not, stop looking at the cheat, because you have a cabling or firmware problem that no software setting will fix.
How to find the fault in five minutes
Follow these steps in order without skipping any. Each step rules out a whole category of faults, and the order puts the cheap tests first.
- Confirm that the physical mouse is in the device's host socket and the game PC cable is in the device's HID socket, because two of the three sockets usually look identical
- Move your own mouse. If the cursor moves, the HID half works and you can stop worrying about the cables to the game PC
- On the game PC, open Device Manager and confirm that exactly one mouse device is listed for your setup, with no warning triangle
- On the second PC, open Device Manager and find the device: a COM port for serial devices, or a network adapter for KMBox Net
- Replace the second PC's cable with a known data cable in a different rear USB port, because a charge-only cable fails completely silently
- Check that the COM number matches what the cheat is set to, and force it to a single digit if it is not one already
- Check the baud rate on both sides, because a mismatch looks like a working connection but does nothing
- Run the cheat's or the vendor's movement test and watch the game PC's cursor. If it moves, the chain is proven and anything left is aim configuration
Common faults and how to fix them
These ten faults account for nearly every input-layer ticket. Find your symptom and work through the fix, and do not move on to the next row until the current one is truly ruled out.
| Symptom | Likely cause | Fix |
|---|---|---|
| Cursor does not move at all, from your hand or from the cheat | Wrong socket, no power to the device, or firmware that is not running | Confirm that the mouse is in the host socket and the game PC cable is in the HID socket. Connect both USB cables, because several devices need the control cable attached just to power up. Check the status LEDs, then reflash if the device shows no sign of life |
| Your mouse works, but the cheat produces no movement | Almost always a baud rate mismatch, or the cheat pointed at the wrong port or IP | Set the device and the cheat to the same baud rate, which is 115200 unless the software documents otherwise. For a network device, ping the box's IP before you open the cheat. A port that opens cleanly but moves nothing is the typical sign of this fault |
| Cursor moves but is jittery, stepped or stutters | Movement deltas clipping in an 8-bit descriptor field, a saturated control link, or CPU starvation on the second PC | Use firmware whose report descriptor declares 16-bit relative axes. Lower the command rate in the cheat rather than raising it, then close whatever else is running on the second PC and test again |
| Device does not appear in Device Manager on the second PC | Missing serial driver, a charge-only cable, or a dead port | Install the right driver (CH343 for MAKCU or CH340 for KMBox B+), then try a different rear USB port with a known data cable and reboot the second PC |
| COM port is missing, or the number keeps changing | Driver not bound, or a native-USB board that re-enumerates on every reset | In Device Manager, update the driver manually from the vendor folder. Then open Port Settings, then Advanced, and force a fixed single-digit COM number. Unplug and replug the device and confirm that the number stayed |
| Cheat reports it cannot connect to the device | Wrong port or IP, another process holding the port open, or the cheat needing administrator rights | Close every other tool that might hold the COM port open, including vendor test utilities and serial monitors, and run the cheat as administrator. For a network device, check that the second PC's static IP is in the box's range and is not the same address |
| Works for a while, then stops mid-session | USB power saving suspending the device, a marginal cable, heat, or a command rate the device cannot sustain | In Device Manager, open every USB Root Hub and USB controller, go to Power Management and untick the option that allows Windows to turn the device off. Replace the cable, and lower the command rate, because some devices are documented to hang if called too frequently |
| Plugging the device in kills the real mouse entirely | Passthrough is not running: the device presents a mouse to the game PC but never forwards your hand's input | Reflash the host side with current passthrough firmware. On a DIY board, prove the host controller works with the library's own mouse example before you blame the cheat |
| Every movement and click registers twice | The physical mouse is plugged into the game PC as well as into the input device | Unplug the real mouse from the game PC, because it belongs only in the input device's host socket. This also removes a duplicate identity from the game PC's USB bus, which you did not want anyway |
| Aim is wildly over or under sensitive, or scales with in-game settings | Mouse DPI, in-game sensitivity and the cheat's own scaling are three multipliers, and the cheat only knows about one of them | Set a known DPI on the mouse, note it, and enter the same value wherever the cheat asks for it. Turn off in-game mouse acceleration and any smoothing, and retune after every DPI or sensitivity change instead of fighting the cheat's scaling |
Which part of the setup is causing the problem
Check this before you post anywhere, because a question sent to the wrong layer gets a confident but wrong answer.
| Symptom | Layer | Do not bother checking |
|---|---|---|
| Your own mouse does not move the cursor | Input device hardware or firmware | The cheat, the DMA card, the memory map. None of them are involved |
| Your mouse works, the cheat cannot connect | Second PC drivers and port configuration | Soldering, the game PC, the descriptor |
| Cheat connects, cursor moves, aim is wrong | Cheat configuration: DPI, sensitivity, smoothing | Cables and drivers. The chain is already proven |
| No targets, no boxes, nothing on screen at all | The card, firmware or memory-map layer | The input device entirely. It has no idea what is in the game |
| Everything works, then stops after a game update | Cheat and offsets | Hardware. A game patch does not change your USB wiring |
What to include when you open a ticket
These six lines of detail turn a two-day back-and-forth into a single reply, so paste them into your first message.
- Device and firmware
- Exact model, and the firmware version currently on it
- Link type and settings
- COM number and baud rate, or IP, port and whether ping replies
- Which half works
- Does your own hand move the cursor, yes or no. This is the most useful single line in the ticket
- The mouse
- Model, whether wired or a dongle, and its DPI setting
- Sockets
- What is plugged into which socket on the device, in words
- What changed
- The last thing you altered before it broke: a driver, a firmware flash, a Windows update, a new cable
What to rule out first, every time
- Both of the device's USB cables are connected, not just the one to the game PC
- The real mouse is not also plugged into the game PC
- The second PC's cable is a data cable in a rear port, with no hub in the path
- The COM number in the cheat matches Device Manager and is a single digit
- The baud rate matches on both sides
- USB selective suspend is off for the controllers on both machines
- No serial monitor or vendor test tool is still holding the port open
Tip
Two habits worth building
First, replace the cable before you believe anything else. A cable that charges a phone perfectly can lack the data pairs entirely and then fail silently at every layer above it, so keep one proven cable and use it for testing. Second, power-cycle properly: unplug the device from both machines, wait a few seconds, then reconnect the control cable first and the game PC second. A soft reset on a device whose USB rail never lost power often changes nothing, and many faults disappear after a genuine cold start.
Common troubleshooting questions
The cheat says connected but nothing happens. What is that?
Nine times out of ten it is a baud rate mismatch. Opening a serial port succeeds whether or not the two ends agree on speed, so the software reports success while every byte it sends is misread. Set both sides to the same rate, starting with 115200.
Should I plug my mouse into the game PC as well, as a backup?
No. It doubles your input, and it puts a second device with the same identity on the game PC's bus, which is the opposite of what descriptor cloning is for. If you need a backup, keep a spare mouse unplugged in a drawer.
Can a bad input device get me banned?
It can add signals, because a stock development-board identity on the USB bus or movement that is obviously not human can be looked at. Nothing here is a guarantee in either direction, and no configuration makes you safe. Fix the obvious anomalies and be honest with yourself about how your aim looks.
Why does it work on my second PC's front USB port but not the rear, or the other way round?
The ports run on different controllers with different power and driver behaviour. For testing, use a rear port directly and remove every hub from the path. If only one specific port works, you have a marginal link that will fail again mid-session.
I flashed firmware and now the device is dead. Is it bricked?
Usually not. Most of these boards have a hardware route back to the bootloader, such as the Program button on a Teensy or holding a side button while connecting power on a MAKCU. Look up that route in your device's documentation before you buy a replacement.
Sources
No published document lists these symptoms and fixes, so every row comes from support tickets and our own bench testing.
Read next
- KMBox Net, KMBox B+, MAKCU, Teensy or Arduino: which input device to buy
- MAKCU and MAKCM setup, start to finish
- Teensy 4.1 as a DMA input device
- KMBox Net or KMBox B+: which one and why
- The full signal chain, from your hand to the game
- DMA troubleshooting: fixes for common issues
- How to read the build status board
Still stuck? Open a ticket on Discord
All guides