Remote Mouse DPI Scaling On Ohmni

Yes - what you’re seeing is consistent with Windows DPI scaling vs. physical desktop coordinates on the Ohmni’s Windows 10 UpBoard.

Short answer

Remote Mouse uses screen coordinates, not percent-based coordinates, and ARC does not currently expose a separate "scaled desktop" coordinate system for that skill. So if Windows changes scaling or resolution, SetAbsolute will be affected unless you compensate for it yourself.

What’s happening

When Windows is at 125% scaling, the desktop coordinate space reported by some APIs can differ from the actual clickable surface ARC is interacting with. That’s why:

• SetAbsolute lands correctly at 100%
• it drifts at 125%
• it shifts again when the resolution drops to 1024x768

This is a Windows display scaling behavior, not really an ARC mouse skill bug.

Best approach

Option 1: Keep the robot UI at a fixed display mode

For telepresence kiosk-style operation, the most reliable setup is:

• Resolution fixed to 1920x1080
• Scaling fixed to 100%
• avoid auto-switching to 1024x768 after RDP disconnect

If the machine is dropping to 1024x768 after disconnect, that usually means the display session is being renegotiated by Windows or the remote display adapter. In that case, the most stable workflow is to avoid RDP for the live kiosk session if possible.

Option 2: Use image-based targeting instead of fixed coordinates

If the "Join" button can move depending on browser UI, zoom level, or scaling, coordinate clicking will always be fragile.

A better ARC workflow is:

• use the Camera Device skill or screen-capture-based logic if appropriate
• detect the button visually
• click based on the detected location

That is much more robust than hard-coded pixel positions.

Option 3: Read the current desktop size and map coordinates yourself

You can build a workaround in Python/JavaScript by reading the current screen size and converting percentages to absolute coordinates. However, this only helps if the values you read reflect the same desktop coordinate space that Remote Mouse expects.

If you want to test this, I’d recommend using a browser windowed state first and compare:

import ctypes

user32 = ctypes.windll.user32
w = user32.GetSystemMetrics(0)
h = user32.GetSystemMetrics(1)

print("Screen size:", w, h)

x = int(w * 0.92)
y = int(h * 0.95)

ControlCommand("Remote Mouse", "SetAbsolute", x, y)

But if Windows scaling is affecting what GetSystemMetrics() reports vs. what Remote Mouse is using internally, the mismatch can still happen.

Things to try in Windows

On the Ohmni PC, check these:

1. Display Settings

   • Resolution: 1920x1080
   • Scale: 100%

2. Advanced scaling settings

   • Enable Let Windows try to fix apps so they’re not blurry

3. Compatibility settings for ARC

   • You already tested the DPI override modes, which is good

4. Avoid session drops

   • If RDP disconnect changes the display mode, that’s likely the source of the 1024x768 fallback

Recommendation for your use case

For a telepresence kiosk, I’d suggest:

• keep ARC and the browser in a single known resolution
• avoid RDP changing the session resolution
• use windowed browser positioning if possible
• if you need to automate UI clicks reliably, consider a robot skill you create to handle browser/UI state transitions instead of pure coordinate clicking

If a built-in feature doesn’t cover your exact workflow, Synthiam’s path for that is to create a robot skill: https://synthiam.com/Support/Create-Robot-Skill/Overview

Useful related docs

• Screen resolution & display issues:
  https://synthiam.com/Support/troubleshooting/screen-resolution

• Remote Mouse skill:
  https://synthiam.com/Support/Skills/Misc/Remote-Mouse?id=16144

One question so I can narrow this down

Are you launching the browser in:

1. full screen kiosk mode, or
2. a normal window maximized inside ARC/Windows?

That detail matters because the best coordinate strategy changes depending on whether the browser is occupying the whole desktop or just a window.