obsproject / obsproject/obs-studio

Mouse cursor capture position slightly off in GNOME on Wayland

Open
#11,636 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
76.4k
Forks
10.2k
Avg merge
4d 23h
Merged PRs (30d)
12

Description

Operating System Info

Other

Other OS

Arch Linux

OBS Studio Version

30.2.3

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/Sn7vKsGiASj082cO

OBS Studio Crash Log URL

No response

Expected Behavior

I expected the cursor position in the video to match the actual cursor position on the screen.

Current Behavior

The mouse cursor is sometimes one pixel off on the X and/or Y axis.

Screenshot From 2024-12-15 18-08-17

Steps to Reproduce
  1. Capture a window using PipeWire on Wayland. (This behavior does not occur when using PipeWire or Xcomposite on Xorg.)
  2. Compare the position of the cursor in the video preview to the position on the screen.
Anything else we should know?

As far as I can tell, the mouse cursor position in OBS is being displayed rounded to the nearest pixel, while the mouse cursor position in GNOME is being floored. In other words, if the mouse position is (23.6, 11.9), OBS displays it at (24, 12), while GNOME displays it at (23, 11).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the cursor-position mismatch while capturing a window with PipeWire on Wayland, then compare the OBS video preview with the GNOME cursor. Use the linked OBS log and the reported rounding-versus-flooring behavior to locate the relevant cursor-position handling. Done means the captured cursor aligns with the on-screen cursor without regressing PipeWire or Xorg behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, linux
Domain
desktop, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.