[Bug]: Mouse and trackpad stutter in a second macOS account while the agent runs in the first (Fast User Switching)
- Dominant language
- Rust
- Stars
- 21k
- Forks
- 675
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 172
Description
## Pre-flight checklist
- [x] I searched existing issues and this is not a duplicate.
- [x] I am on the latest release or a recent `master` build.
- [x] I quit Logi Options+ before running OpenLogi. (Never installed. Logitech G HUB was previously installed on this machine and was fully removed, including its driver extension, before OpenLogi went on.)
## Which part of OpenLogi?
Agent (background daemon)
## OpenLogi version
0.8.1 (Homebrew cask)
## Operating system
macOS
## OS version & architecture
macOS 15.8 (24H16), Apple Silicon
## Device model
G502 X PLUS
## How is the device connected?
Lightspeed receiver (`046d:c547`)
## Affected area(s)
- [x] Other — pointer input generally, including the built-in trackpad
## What happened?
I keep two macOS accounts logged in at once and move between them with Fast User Switching. OpenLogi is installed and configured in the first account only.
While the OpenLogi agent is running in account A, pointer input in account B stutters:
- The cursor is jittery when driven by the G502.
- The cursor is **also** jittery when driven by the built-in trackpad.
- Holding a modifier chord such as Command-Tab, to keep the application switcher open, stops cursor movement entirely until I release the keys.
Account B has no OpenLogi install of its own. There is no `org.openlogi.agent.plist` in its `~/Library/LaunchAgents`, and `ps` shows no OpenLogi process owned by that user. The only OpenLogi processes on the machine belong to account A, which is switched away from at the time.
Account A itself is smooth throughout. I only see this in the account that is *not* running the agent.
Stopping the agent makes account B smooth immediately. So does leaving the agent running with `capture_mouse_events = false` in `~/.config/openlogi/config.toml`, which is what I am using now.
For context on why I am confident this is not general system load: my first observation happened while the machine was busy after a reboot, so I retested later with the machine idle. Results below.
## Steps to reproduce
Two accounts, A and B, both logged in. OpenLogi installed and configured in A only, with Accessibility and Input Monitoring granted, and `capture_mouse_events` left at its default of `true`.
**1. Confirm exactly one agent is running in account A.**
```bash
pgrep -fl openlogi
```
Expect one `openlogi-agent`, one `openlogi-overlay`, and `openlogi-desktop` if the GUI is open. See the note at the end about accidentally getting two agents.
**2. Record system load, so it can be ruled out later.**
```bash
uptime
```
**3. Fast-switch to account B.** Do not log out of A.
**4. In account B, move the mouse, then the trackpad.** Both stutter.
**5. In account B, hold Command-Tab and move the cursor.** Movement stops until the keys are released. This was the most repeatable of the symptoms.
**6. Switch back to A and stop the agent.**
```bash
launchctl bootout gui/$(id -u)/org.openlogi.agent
pgrep -fl openlogi # expect nothing
```
**7. Switch to B and repeat steps 4 and 5.** Smooth, including the Command-Tab case.
**8. Switch back to A, disable the setting, and restart the agent.**
```bash
sed -i '' 's/^capture_mouse_events = true$/capture_mouse_events = false/' \
~/.config/openlogi/config.toml
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/org.openlogi.agent.plist
```
**9. Switch to B and repeat steps 4 and 5.** Smooth, with the agent running.
**10. Switch back to A, re-enable the setting, and restart the agent.**
```bash
sed -i '' 's/^capture_mouse_events = false$/capture_mouse_events = true/' \
~/.config/openlogi/config.toml
```
Then quit OpenLogi from the menu bar and reopen it, so exactly one agent starts and reads the changed file.
**11. Switch to B and repeat steps 4 and 5.** The stutter returns, indistinguishable from step 4.
## Observations
Each row is one pass through the switch-and-test cycle above. Load average is the 1-minute figure taken in account A immediately before switching.
| Agent | `capture_mouse_events` | Load avg | Input in account B |
|---|---|---|---|
| running | `true` | ~25 | stutters |
| stopped | — | ~5 | smooth |
| running | `false` | ~5 | smooth |
| running | `true` | ~8.6 | stutters, same as row 1 |
The last row is the one that convinced me. The first observation was made on a machine still busy after boot, so I could not initially separate the setting from the load. Re-enabling the setting later, at roughly a third of that load, brought the symptom straight back.
**Reproduction caveat worth knowing:** opening the OpenLogi GUI starts its own agent as a login item, which is separate from one started via `launchctl bootstrap`. I ended up with two agents running simultaneously and briefly got a meaningless result from it. Check `pgrep -fl openlogi` returns a single `openlogi-agent` before trusting any pass.
## `openlogi list` output
```
Lightspeed Receiver (CFE1ADDE, vid=046d pid=c547)
└─ slot 1 ● G502 X PLUS (mouse, wpid=4099, battery=71% full (discharging))
model_ids=[4099,c095,0000] ext=00 serial=— unit_id=80bab579 transports=usb+equad
Cameras (1 Logitech UVC)
└─ ● HD Pro Webcam C920 (camera, vid=046d pid=08e5, up to 1920x1080@30, id=0x1122300046d08e5)
```
## macOS permissions
- [x] OpenLogi has Accessibility permission.
- [x] OpenLogi has Input Monitoring permission.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the Agent background daemon and trace the mouse-event capture path controlled by capture_mouse_events in ~/.config/openlogi/config.toml. Reproduce with two logged-in macOS accounts, Fast User Switching, pgrep -fl openlogi, and the org.openlogi.agent launchctl commands. Done means capture_mouse_events=true no longer stutters or blocks pointer input in the inactive account while the agent runs in account A.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- macos, rust
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100