Revo Metro UI broken on a XP-Pen display — one-button fix (AutoHotkey)

Support & Feedback
1

Before :

image
image1918×1007 271 KB

After :

image
image1918×1007 316 KB

:pen: One-press “scanning mode” on an XP-Pen pen display (Revo Metro)

If you run Revo Metro on an XP-Pen pen display as a secondary screen, you’ve probably hit this: the app’s interface only lays out correctly on your primary monitor. Drop it on the pen display and panels overlap, buttons get clipped. And the XP-Pen driver always maps the pen to whatever monitor is primary — so making the pen display primary fixes it, but then your whole desktop lives on the little tablet, and every new window opens there.

I got tired of shuffling primaries by hand, so I wrote an AutoHotkey script that does the whole dance in one shot. I’m sharing it in case it helps other reverse-engineering / sculpting folks with the same setup.

:gear: What it does — one trigger and:

  1. makes the pen display primary,
  2. launches the app so it’s born correct on that screen,
  3. flips your main monitor back to primary,
  4. re-pins the pen to the tablet anyway,
  5. leaves you with: main monitor primary, pen active on the tablet, app perfectly laid out. New windows still open on your main screen where they belong.

:radio_button: The tablet-button part (the good bit)

Bind it to a key on the pen display itself. Press one button on the tablet → Revo Metro opens ready to work, pen live on it, no fiddling. A real “enter scanning mode” button.

:package: What you need

:hammer_and_wrench: Setup

A few minutes: fill in your monitor IDs and your tablet’s mapping values, then assign a pen/tablet button to run it. Everything — the why, the how, and step-by-step setup — is documented in the header of the script itself, so read that first.

:warning: Good to know

  • Any display change while it runs (monitor sleep, remote desktop, resolution change) resets the pen to the primary — just press the button again.
  • One quick driver restart per launch (tray icon blinks, pen drops ~1-2 s).
  • It edits only the pen-mapping line and keeps a timestamped backup of your driver config, so your button/pressure/calibration settings are untouched.

:page_facing_up: The script

Full source, with all the setup docs in the header:

:backhand_index_pointing_right: One-press launcher for Revo Metro on an XP-Pen pen display · GitHub

Open it, click Raw, and save as pen-display-launcher.ahk (the Raw view copies cleanly — no forum reformatting).

:test_tube: Tested on Windows 11 24H2, Artist 13 (2nd Gen), two monitors + one pen display. Adapt the config block to your own kit. Questions welcome.

1 Like
2

:magnifying_glass_tilted_left: For the Revopoint dev team — a possible root cause

Full disclosure on this one: the analysis below was written by Claude, which helped me diagnose the issue and build the workaround. It is black-box reasoning only — no access to Revo Metro’s source — so treat it as a hypothesis to check, not a verdict. Posting it in case it saves your team some time.

Observed on Revo Metro 5.8.7, Windows 11 24H2, primary monitor 3840×2160 @150%, pen display 1920×1080 @150%:

  • Launched while the pen display is not primary → panels overlap, controls clipped.
  • Launched while the pen display is primary → correct. Flip the primary back afterwards and the window stays correct.
  • Moving the window between monitors after launch → never re-lays out, in either direction.

Things that did not fix it (this is the interesting part):

  • Setting both monitors to the same scale factor (tried 100 / 125 / 150 on both) — no change.
  • Compatibility → High DPI override, “System” and “System (Enhanced)” — no change.
  • Forcing ~ DPIUNAWARE via AppCompatFlags\Layers — no visible effect at all, so the shim appears to be overridden by the app’s own startup code.
  • QT_ENABLE_HIGHDPI_SCALING=0 — no change.

Hypothesis. Because matched DPI scaling changed nothing, this doesn’t look like a DPI-awareness problem. It looks like layout geometry being computed from the primary screen instead of the screen the window is actually on — i.e. something equivalent to QApplication::primaryScreen()->geometry() / availableGeometry() being used at startup for sizing and placing the panels, rather than the window’s own screen.

That single assumption predicts every result above: correct when primary is the target screen; broken when the two differ in resolution; unaffected by DPI settings; and never self-correcting, because the geometry is read once at startup and there’s no re-layout on screen change.

Worth checking, if it holds:

  • Derive layout from the window’s own screen (QWidget::screen(), QGuiApplication::screenAt()) rather than the primary screen.
  • React to QWindow::screenChanged and re-run the layout, so dragging between displays works too.
  • If per-monitor DPI is also in scope, declare Per-Monitor v2 awareness in the manifest and let Qt handle the rest.
  • Test matrix suggestion: launch on a secondary monitor whose resolution differs from the primary — that’s the case that breaks, and it’s easy to miss when all test machines have matched displays.

Happy to re-run any test on my setup if that helps narrow it down. Hardware: Artist 13 (2nd Gen) pen display alongside two 4K monitors, Metro Y Pro scanner.

3

Hi
Thx for sharing amd elaborating the bug. You should share it directly to customer@revopoint3d.com ,too. You can link your thread here.

Cheers

4

Thanks Ivan, it’s done !

1 Like