Per-seat gamepad controller isolation

[jmlopezdona]

Sharing a week of measurements from a two-seat host, because the answer turned out to be a HidHide
feature that is documented nowhere and that I think MultiSeat should be using.

Full write-up, with every measurement table and the refuted alternatives:
https://claude.ai/code/artifact/a2fd1da7-c18f-4fd0-a7a2-64fb71bcb534

Host: Windows 11 26100.8972, two seats + a console player, HidHide driver 1.4.181.0, ViGEmBus 1.22.0.
Everything below was measured there between 2026-08-14 and 2026-08-20.

Even though I've arrived at a configuration that works for several sessions (two — that's the limit because my GPU has 2 NVENC encoders; with the 5000 series you could do up to 3 simultaneous sessions, regardless of whether the GPU can actually handle those three games in parallel or not), I have the feeling that the setup is very convoluted, and I'd like to know if there's any option (e.g. using an alternative to ViGEmBus) that's simpler, and therefore probably more robust as well.

Without a doubt, once you start digging into the different gamepad driver standards (XInput, DInput, SDL, HID...), the quirks of individual games (e.g. ones that only read XInput slot 0), and the limitations of per-session device isolation in Windows (something already solved on Linux), you begin to understand just how hard it is to set up parallel sessions on a single Windows installation.

The problem

Every Apollo instance asks ViGEmBus for its pad, and the resulting PnP node is machine-level with
no session affinity. With both seats streaming, a probe run in session 0 — which is neither
seat — saw both pads, XInput slots 0 and 1, live packet counters on both. Keyboard and mouse are
fine, because Apollo SendInputs those inside the session; it is only the pad that escapes.

DEVPKEY_Device_SessionId does not rescue this: Windows clears it every time the device starts.
Five variants refuted (stamping a live pad, Disable-PnpDevice re-enumeration, reconnect, stamping
the phantom devnode, disable → stamp → enable). DuoStream does confine devices this way, but from
their own driver — they dropped ViGEmBus.

What actually works

Append !<sessionId> to the device instance path in HidHide's ordinary, persistent blacklist:

USB\VID_045E&PID_028E\01!2                          seat's pad, XUSB node → visible only in session 2
HID\VID_045E&PID_028E&IG_00\3&130C1E12&0&0000!2     same pad, HID node    → visible only in session 2

Shipped since v1.4.181.0 (2023-10-31), contributed by DuoStream's author in commit 3934d9a.
HidHide/src/Logic.c:817 is the whole decision:

sessionId != 0 && jailSessionId != 0 && sessionId == jailSessionId ? FALSE : TRUE

It is in no README, no CLI help and no release note. Measured in a VM against the released signed
driver, one fresh process per reading:

blacklist entry	session 0	session 1
…\2&130C1E12&0&0000	denied	denied
…\2&130C1E12&0&0000!1	denied	opens
…\2&130C1E12&0&0000!2 (no such session)	denied	denied
(nothing)	opens	opens

The third row is what makes it a measurement and not a coincidence.

Why this matters more than the usual answers: it acts on the device, not on the reader. No
DLL in a game folder, no environment variable, no list of .exe paths — so it does not care where a
game is installed or which API it enumerates through. Confirmed in game, both directions: The Last
of Us Part II in a seat (which reads through Windows.Gaming.Input, the hole no local filter can
reach) stopped responding to the console pad and responded to its own; NBA 2K26 on the console,
the same in reverse.

Two bonuses: on a session match Blacklisted() returns FALSE, so the whitelist is never
consulted and its global-hole problem disappears for a confined device. And the jail is per entry,
not one global partition — N seats are N rules, so the two-player ceiling lifts.

Three things that will bite whoever implements this

1. A pad is not one device, and XInput reads the node nobody hides. A ViGEm x360 publishes
three nodes. Hiding the HID one — which is the obvious move — leaves the pad fully visible in XInput:

what is hidden	HID, s0	XInput, s0	XInput, s1
the HID node only	denied	connected	connected
the XUSB node only	opens	empty	empty
XUSB with !1	opens	empty	connected

The XUSB node is USB\VID_xxxx&PID_xxxx\NN. Both ends need a rule. Leave the keyboard/mouse/consumer
nodes some pads publish alone.

2. HidHide filters at open time, so a rule written after the pad is late by definition. One pad
appeared at 13:27:33 and its rule landed at 13:27:39.9 — 6.9 s, because every read of HidHide's
config costs ~800 ms. Batching a whole pass into one call gets it to 1.7–3.1 s over eight
creations, and that does not close it: dwm, explorer and GameInputSvc of every session
open each new pad inside that window, and those handles never expire. Symptom that exposed it: a
seat's Xbox app moved with the other seat's controller, because it opens nothing itself — it reads
from its own GameInputSvc, which had both.

A rule for an absent device matches nothing, so it is inert and free to write in advance. Measured
with control: with one pad's rule pre-written by hand, that pad came up open only to its own session,
while the other — rule 2 s late — was open in all three. Same host, same instant, only variable being
when.

And it cuts both ways: releasing a wrong rule does not hand the pad back, because the session
that opened it keeps its handle and the real owner tried once and does not retry. It took two
reconnects.

3. Ownership must be derived, never configured. My config said the console player's pad was
045E:028E while the actual controller was a GameSir — so the watcher had not recognised it for
days, and nothing said so. Two traps in deriving it:

• "Emulated" cannot be recognised by name. A ViGEm pad's XUSB node reports its parent as
  ROOT\SYSTEM\0001; nothing in the tree says "ViGEm". Looking for the word read both seats' pads as
  physical and confined them to a session neither seat was in, reporting success. The real test is
  bus (USB\, BTHENUM\, PCI\) versus PnP root.
• A placement made by elimination must not be remembered, and must be said out loud. With one
  free seat, the pad created by the console player's Apollo got confined to that seat with no
  evidence and no warning — the panel showed a healthy verified jail while the player's controller
  had stopped working — and the wrong decision then survived two minutes after the situation that
  produced it was gone.

Useful side effect: session 0 never matches (the driver requires sessionId != 0), so a service
running there can use "can I still open this device?" as a live probe that a rule took effect. Worth
having, given the feature is undocumented and a future release could drop it silently.

What I built

Four switches, all off or empty by default — a host that sets nothing behaves exactly as before:

key	what it turns on
EnableHidHideCloaking	the mechanism: one entry per relevant node per pad, suffixed with the owner's session
EnablePadRulePreWrite	write each seat's rule before its pad exists
EnableSeatPadIdentity	a fixed per-seat serial and VID/PID — requires a patched, self-built Apollo/Vibepollo; see the caveat below
EnableXInputRemap	per-process XInput slot compaction; refuses to deploy without confinement

The XInput proxy and the SDL environment filter are now deprecated and off; with confinement on, the
already-deployed DLLs are removed at startup. GamepadType stops being part of the mechanism and
seats go back to x360 (native XInput).

On the identity switch: the last section of the XUSB path is a serial that ViGEmClient.cpp:558
picks in user mode by sweeping the free ones from 1 — so where a seat's pad is born is decided
by whoever connects first, which is the whole explanation for the \01↔\02 alternation that makes
instance paths look non-deterministic.

Pinning it costs a patched, self-built Apollo, and that is not a small ask. Being explicit,
because it is the one part of this that a host cannot just switch on:

• Two diffs, 243 added lines, against Nonary/Vibepollo 1.18.4-stable.2. They add three config
  keys — gamepad_serial_no, gamepad_vid, gamepad_pid — all additive and inert when unset.
• One of them has to live in the ViGEmClient submodule, because PVIGEM_TARGET is opaque in
  the public header and the serial cannot be set from outside the client. So it is a fork of a fork,
  with two levels of rebase every time upstream moves.
• You have to build it yourself. MSYS2 UCRT64, the documented package list plus
  mingw-w64-ucrt-x86_64-nlohmann-json, which the docs omit and without which
  tools/display_settings_helper_main.cpp will not compile. A full build from clean is 2 min 44 s
  here, which is what makes the rebase tolerable — but the toolchain has to exist first.
• The resulting binary needs its own directory, separate from any console-side Apollo install,
  and MultiSeat points at it by path. That also makes rollback one config value.
• Nothing of this is upstream. I have offered the keys to Vibepollo separately; until then it is
  carried.

Without it everything above still works, just approximately: the XUSB path is learned from where
a seat's pad has been rather than computed, so a seat that lands on a serial it has never used falls
back to the reactive path for that one creation. That is the honest trade — the patch removes an
approximation, it does not add a capability. Diffs and the full rationale are in the write-up.

Measured result

Two seats streaming, both playing, each session moved only by its own pad. Across seven hours
covering seats with and without identity, the console player's pad, reconnections, a binary swap and
a reboot: zero pads attributed by guesswork.

What it does not cover

• XInput slot numbers are machine-wide and confinement cannot renumber them. Each session saw
  exactly one pad — isolation working — but each kept the slot XUSB gave it, so one seat had slot 0
  and the other slot 1, and DOOM Eternal moved in one and was blind in the other. 6 of 11 titles
  measured here bind their input to slot 0. Free workaround: the slot frees when its pad disappears,
  so whoever wants the slot-0-bound title just creates their pad first (move the stick, wait, then
  launch). The DLL is only needed when both want such a title at once.
• A whitelisted application walks straight through it. The list is global and cannot pair an app
  with a device, so one entry sees every confined pad. Mine had twelve entries including
  Hades2.exe, and Hades II in a seat was moved by both players' pads while Forza beside it saw
  none. ConsolePlayerApps has to be empty. Note also it protects the process that opens the
  device, which is often not the game — Forza runs from a versioned WindowsApps path, and Steam
  games often read pads through steam.exe. That made two of my first three readings say the
  opposite of the truth.
• Talking to HidHideCLI.exe has five traps, all of which made an earlier implementation a
  silent no-op while HidHide sat installed and healthy: it never exits if it inherits stdout/stderr;
  it saves the config on exit even for a pure listing (so reads need --cancel); the value goes
  directly after the switch (--dev-hide "PATH", there is no --id form); back-to-back invocations
  return empty, which reads exactly like "nothing is configured"; and the driver's control device
  takes one caller at a time, returning 0x0005 Access denied and doing nothing silently. All five
  are written up with fixes in the full report.
• Unmeasured: rumble through a confined pad, raw DirectInput/HID with a borrowed identity, and a
  pad connected by Bluetooth and cable at once.

Offer

All of this is implemented and running: the HidHide CLI client with the five traps handled, the
per-session rule writer, the pre-write registry, attribution, the live probe, the API surface and the
dashboard tab. Happy to open PRs against whatever subset you want, or to answer questions — no
expectation that you take it as-is.

[vibesoftwarecoder]

Your issue sent us through our HidHide integration and turned up two bugs in it — one fixed, one
deeper underneath. Taking the parts in order.

We found the bug and it is fixed

the value goes directly after the switch (--dev-hide "PATH", there is no --id form)

MultiSeat was calling --dev-hide --id "<path>" and --app-reg --path "<exe>" at eleven call
sites. HidHide received the literal string --id as a device instance path, matched nothing, and
exited 0. Fixed in
f23117e, with seven tests that I
made fail first — reintroducing --dev-hide --id turns two of them red. The guard asserts
DoesNotContain --id, because --dev-hide --id X contains --dev-hide too and would pass a naive
check for the good form.

Your --cancel point went in with it. --dev-gaming and --app-list were rewriting the config they
were asked to report on.

And underneath it, the reason none of that had ever mattered

Our ParseDeviceList assumed "HidHide CLI outputs device instance paths, one per line" and kept
lines starting with HID\ or USB\. The CLI emits JSON. Measured against real --dev-gaming
output on this host: 25 non-empty lines, 0 matched, 4 of them actually containing a path.

So ListGamingDevices() always returned empty, CloakForSession took its "No gaming devices found
to cloak" early return, and the CLI was never invoked at all. The argument bug was real but academic —
the loop that used it never had anything to iterate. The only signal either bug produced was a
LogDebug line, which a Windows Service never writes anywhere.

So: MultiSeat's controller cloaking has never done anything, on any host, since it was written.
Your issue is what surfaced that.

I verified your mechanism from the HidHide source before believing it

Not doubting you — it is an undocumented kernel behaviour we would be building on, so it deserved
independent confirmation:

• Commit 3934d9a is "Add WTS session jail support", 2023-10-31, touching Logic.c and Logic.h.

• Release v1.4.181.0 was published the same day.

• The decision line is verbatim what you quoted, at Logic.c:637 in v1.5.230.0:

  return (sessionId != 0 && jailSessionId != 0 && sessionId == jailSessionId ? FALSE : TRUE);

• It is byte-identical in v1.4.181.0 and v1.5.230.0, the current latest. Your worry that a future
  release could drop it silently has not been realised so far, which is worth knowing given you are
  right that nothing documents it.

That single line also confirms all three of your corollaries at once: session 0 can never match, so a
service there is a valid probe; the jail is per entry, so N seats are N rules; and a session match
returns FALSE before the whitelist is consulted.

Our host runs driver 1.4.181.0 with CLI 1.5.230.0, so the same version you measured on.

Your XUSB point, confirmed here

Our --dev-gaming output shows both nodes for the same pad, exactly as you describe:

"deviceInstancePath"              : "HID\VID_045E&PID_028E&IG_00\3&8968588&0&0000"
"baseContainerDeviceInstancePath" : "USB\VID_045E&PID_028E\01"

We were reaching for the first one. Per your table that is precisely the node XInput does not read,
so even a correctly-parsed, correctly-invoked version of what we had would have hidden the pad from
everything except the API that matters.

On the PRs — yes, and here is the subset I would take

Being specific so you are not guessing at scope:

Yes, please:

• EnableHidHideCloaking — the session-suffixed rules, one per relevant node per pad. This is the
  mechanism and it replaces our approach rather than extending it; hide-all-plus-whitelist-Apollo
  cannot isolate seats from each other by construction.
• EnablePadRulePreWrite — I read this as correctness rather than optimisation, given HidHide
  filters at open time and dwm/explorer/GameInputSvc handles never expire.
• The session-0 live probe. Cheap, and it is the right answer to building on an undocumented
  feature.

Not yet, and I want to be honest about why rather than leave it ambiguous:

• EnableSeatPadIdentity. We do ship our own Apollo fork, so carrying a patch is less alien here
  than for most projects — but a fork of a fork with two levels of rebase, to remove an approximation
  rather than add a capability (your framing, and I think it is the right one), is not a trade I want
  to make while the mechanism above is still new to us. If the reactive path proves painful in
  practice I would revisit it.
• EnableXInputRemap. You have deprecated it in favour of confinement and it needs a DLL in a
  game directory, which I would rather not ship.

Two things I would want in whatever lands: the whitelist stays empty for confined devices (your
ConsolePlayerApps warning — one entry seeing every confined pad is a worse failure than no
isolation, because it looks like it works), and pad ownership derived by bus versus PnP root
rather than by name, since your ROOT\SYSTEM\0001 finding means the obvious check reads emulated pads
as physical and confines them to a session nobody is in, reporting success.

Two asks

1. I could not open your write-up. claude.ai/code/artifact/… refuses for me with "this artifact
   is served to you as a public reader, and reading public artifacts that way is not enabled yet", so
   I have worked entirely from the issue body. If the diffs and the refuted alternatives could go into
   the PR description, or as a gist, I would read them properly.
2. Does --dev-hide pass the !<sessionId> suffix through unmodified, or did you write the
   registry value directly? I would rather not assume the CLI leaves it alone. Happy to test that end
   here if it is easier — a rule for an absent device is inert, as you noted, so it costs nothing to
   try.

One difference worth flagging so the PRs land against the right assumption: MultiSeat defaults
EnableViGEmController off — we create no pad of our own, and Apollo forwards the client's
controller into the seat natively. So the pads in play here are Apollo's own per-stream ViGEm pads,
which I believe matches your setup, but say so if not.

Thank you for the measurement tables, and particularly for the controls — the !2-for-a-session-that-
does-not-exist row is what makes the whole thing evidence rather than a plausible story.

[jmlopezdona]

Thank you for digging into it that far — the JSON parse finding is a better result than anything I
reported, because it explains the shape of the whole thing. Answering your two asks first, then the
part I think matters most now that the CLI actually runs.

1. Yes, --dev-hide passes the suffix through untouched

We never write the registry directly. Every rule this host has ever had was written by
HidHideCLI.exe, one argument, suffix included:

HidHideCLI.exe --dev-hide "USB\VID_045E&PID_028E\01!2"

On the source side, ValOneDeviceInstancePath validates argument count and length only, never the
format, so the string reaches the configuration verbatim.

But the behavioural proof is stronger than the source reading, and it is free: if the CLI stripped
the suffix, the rule would degrade into a plain global hide — the pad would vanish from the seat as
well, which is about as loud as a failure gets. What we measure instead is the asymmetry: from
session 0 the service's own probe goes from opening the device to ERROR_ACCESS_DENIED, while the
seat's session keeps it. That asymmetry cannot exist unless the suffix survived.

So it costs you nothing to confirm at your end, and I would expect it to just work.

2. Sorry about the write-up — that link was the wrong channel

Artifacts on claude.ai are private to the publishing account by default; you reached it as an
anonymous reader, which is the state that error describes. My mistake for using it as though it were a
public URL. Everything is now in a plain gist:

https://gist.github.com/jmlopezdona/e289d9ff676c71b8dcdcd81b447a86e8

• 01-one-pad-one-session.md — the full write-up, same content as the issue body but complete.
• 02-refuted-alternatives.md — what you asked for: every approach tried before this one and why
  each was discarded, written in English for this purpose. DEVPKEY_Device_SessionId and its five
  variants, the inverse whitelist (--inv-on) with its four-step measurement, the pad-type/SDL/global-
  whitelist design this replaced, the Playnite pre-launch hook, and a section on the ones that were
  refuted by a broken instrument rather than by the world — those cost the most.
• 03-controller-isolation-design.md — the raw design record, kept verbatim. Fair warning: its
  historical half is in Spanish. 02 exists so you do not have to read it.
• 04-vibepollo-patches-README.md plus the two diffs, with base commits and the rebase runbook.

3. The part I would flag hardest: your fix means the CLI now runs for the first time

This is the bit I would most want to hand over, because it follows directly from your ParseDeviceList
finding. If ListGamingDevices() always returned empty, then the CLI was never invoked, which
means none of its transport traps have ever fired on your host. They will now. There are five; you
have independently found the third. In rough order of how much they cost us:

It never exits if it inherits stdout/stderr. Timeouts at 12 s and 45 s with nothing applied.
Redirected through cmd.exe to a temp file, exit=0 in under a second and the config lands. This is
the one that will bite first, because it looks like a hang rather than a bug.

Invocations that follow each other too closely come back empty — and an empty answer is
indistinguishable from an empty configuration. Three chained reads once reported an empty blacklist,
an empty cloak state and an empty application list while all three were populated. That nearly made
us "restore" over the user's own entries. What we do now: ~800 ms between reads, a separate
redirection file per read, retry, and treat an empty answer as a failed read — where a failed read
changes nothing. The tell is that a valid run always prints its cloak state, which is how a real empty
config and a failed read are told apart.

Note this compounds with your bug in a nasty way: --dev-gaming also returns [ ] legitimately when
no pad is attached. So an empty answer there means three different things.

The driver's control device takes one caller at a time. With the service mid-pass, a second
invocation — running as SYSTEM, so not a permissions problem — returns Error code 0x0005 … Access denied and silently does nothing. It cuts both ways: opening HidHide's own GUI while a pass runs
can make one of the service's writes vanish. It also explains the "access denied" people report when
running the CLI by hand; it is not about elevation. Retry changes, and never parse an error output as
an answer.

And one for the parser you have just rewritten: absent devices have to be dropped. HidHide
remembers every device it has ever seen, and this host's history holds dozens of dead ViGEm pads —
--dev-all's game-controller entries are almost all present: false.

4. Your version finding is new information here, and useful

I had only checked the driver installed on this host. That the decision line is byte-identical in
1.4.181.0 and 1.5.230.0 is a materially better answer than "it works on the version I have" — it
means the undocumented behaviour has survived every release since it was introduced. It does not make
it documented, so I would still keep the live probe, but it lowers the risk a good deal. Thank you for
checking it rather than taking my word for it; that was the right call.

5. On the scope

Your subset is the right one and I will send it that way: EnableHidHideCloaking,
EnablePadRulePreWrite, and the session-0 probe.

On EnableSeatPadIdentity — deferring is reasonable and your framing of it is the one I would
use. It removes an approximation rather than adding a capability, and a fork of a fork with two levels
of rebase is a real cost. So that you can recognise it if the reactive path does start to hurt, this is
what it looks like:

• The gap between a pad being created and its rule landing is 1.7–3.1 s over eight creations, once
  a pass is batched into a single CLI call. Before batching it was up to 6.9 s.
• EnablePadRulePreWrite closes that for a seat whose pad has been seen before, because the
  learned paths are already written. What it cannot cover is a seat landing on a serial it has never
  used — which happens because the serial is swept from 1 in user mode, so it goes to whoever plugs in
  first, not to whose pad it is.
• The symptom, when it happens, is not subtle but it is misattributed: a rule pre-written for one
  seat catches another player's pad. And releasing that rule does not hand the pad back, because
  HidHide filters at open — the session that grabbed it keeps a handle that never expires, and the
  real owner tried once and does not retry. In our measurement the correction took two
  reconnections to become visible.

If that never shows up for you, the identity patch buys nothing. It is worth knowing which symptom to
attribute to it, though, rather than to the pre-write.

On EnableXInputRemap — agreed, and I would make the same call. It is deprecated here in favour
of confinement and it exists only for the one thing confinement provably cannot do: XInput slot
numbers are machine-wide, and 6 of the 11 titles measured here bind their input to slot 0. There is a
free workaround for most households, which is that a slot frees when its pad disappears — so if only
one of two players wants a slot-0-bound title, that player creates their pad first. The DLL is only
needed when both want one at the same time.

6. Your two conditions, agreed, plus one I would add

Both of yours are right and both are in what I would send: the whitelist stays empty for confined
devices (with a warning that names any foreign entry, and a permanent exemption for HidHide's own
two, since --app-unreg on itself does not stick — an earlier version of that check warned on "the
list is not empty" and therefore read "Not guaranteed" on every host that had ever installed
HidHide, which made it useless on the day it mattered), and ownership derived from bus-versus-PnP-root
rather than by name.

The one I would add is the read gap from §3. It is not a nicety: without it the monitor reports an
empty configuration, and something that then tries to reconcile against that reading is one step away
from removing entries a user wrote by hand.

7. On EnableViGEmController

Confirmed, and it matches — that default is off here too, and the pads in play are Apollo's own
per-stream ViGEm pads. One difference worth naming because it is the case that cost us the most: this
host also runs a standalone Apollo for the console player, whose pad is created the same way with
the same VID/PID and is therefore indistinguishable from a free seat's. That is what produced the
worst failure in the whole week — a free seat was handed the console player's pad by elimination, the
panel reported a healthy verified jail, and the player's controller had simply stopped working. Hence
identity first, evidence second, elimination last, and elimination never remembered and always said out
loud.

If you are not running a console-side instance, that branch is much less load-bearing for you.

[jmlopezdona]

Right now I have a local version that works, but it may have diverged too much from your multiseat version. I think it would be a good idea to wait and see if we get any feedback from Nonary (VibePollo/VibeShine) about what the new "multi-session" version of his Sunshine/Apollo fork includes. After that, it'll be a good time to take stock, review where MultiSeat stands at that point, and decide which PRs to open for better integration of everything.

Thanks to both you and Nonary for creating these two pieces of software. Today more than ever, there are fewer and fewer limitations on developing software solutions, with the help of AI.

I hope I've been able to contribute to building a full open-source alternative to DuoStream — until recently, the only solution I knew of that could do this.

[jmlopezdona]

I think Nonary is making good progress on version 1.19, and having a custom driver to replace ViGEmBus is the right call. The changes he's including in this new version (currently in beta) look interesting: https://github.com/Nonary/Vibepollo/releases

[vibesoftwarecoder]

Implemented and shipped: 5a58a6d, deployed here, off by default. Thank you — this was the most
useful thing anyone has sent this project.

Your behavioural argument for the suffix is what I actually relied on, not the source reading. "If
the CLI stripped it, the rule would degrade into a plain global hide and the pad would vanish from
the seat too" is checkable without trusting anyone's reading of ValOneDeviceInstancePath, and it
made the CLI-versus-registry question answer itself. So it goes through HidHideCLI.exe.

What landed

The subset we agreed, all of it off unless switched on:

EnableHidHideCloaking	the jail: one rule per node per pad, suffixed with the owner's session
EnablePadRulePreWrite	rules written at provisioning step 2.7, before Apollo starts
VerifyHidHideJail	the session-0 probe, on by default since it only reports

HidHideSessionJail refuses sessionId <= 0 outright rather than writing it, for the reason above —
a session-0 rule is not ignored, it is a global hide wearing a suffix.

Attribution is identity (SeatPadDevicePaths) then elimination, and elimination is refused when
more than one unconfined emulated pad exists. When it is used it goes to the log at Warning saying
it is a guess, and it is never remembered.

There is a --hidhide inspection mode now, because too much of this fails while reporting success:

MultiSeat.Service.exe --hidhide

Cloak state, whitelist with foreign entries flagged, existing rules with their jailed session, and
per pad both nodes, both parents, the emulated verdict and the exact rules a jail would write.

Two things I measured here that sharpen your notes

1. The HID node's parent looks physical even for an emulated pad. Your write-up says the test is
the parent, bus versus PnP root, which is right — but which node you ask turns out to matter. On
this host:

FriendlyName : "Xbox 360 Controller for Windows"          <- says nothing
HID  node    : HID\VID_045E&PID_028E&IG_00\3&8968588&0&0000
   parent    : USB\VID_045E&PID_028E&IG_00\2&DEE0F28&0&00  <- looks like a real controller
XUSB node    : USB\VID_045E&PID_028E\01
   parent    : ROOT\VIGEMBUS\0002                          <- the only place it shows

Ask the HID node and you classify a ViGEm pad as physical and politely leave it alone. My code asks
every node and takes emulated if any of them says so.

2. The root enumerator is not a fixed string. Yours reports ROOT\SYSTEM\0001, mine
ROOT\VIGEMBUS\0002. Same conclusion, different name, so the test is the ROOT\ prefix rather than
either literal — worth knowing if anything downstream ever matches on the whole path.

A trap I built for myself, which you may be one step away from

You noted the CLI's own help says commands can be sequenced. I took that further and made every read
--cloak-state <query> --cancel, so that an empty answer can be told from an empty configuration —
your point 2, and the tell is exactly the one you named.

That immediately broke device parsing, silently. The transcript is no longer pure JSON: it is
--cloak-off on its own line and then the array. Handing the whole thing to a JSON parser throws,
and my code turned that into "no gaming devices" — which is the very confusion the cloak-state line
was added to prevent, arriving through the door I opened.

It survived my unit tests because the fixture was pure JSON. What caught it was --hidhide printing
Gaming devices present: 0 while the raw CLI reported a pad in the same second. If you batch reads
the same way, this is worth ten seconds of checking.

A third silent reader, if you read the whitelist

--app-list replays commands rather than printing paths:

--app-reg "C:\Program Files\Nefarius Software Solutions\HidHide\x64\HidHideCLI.exe"

My old reader dropped every line starting with -- as a header, so the whitelist always read as
empty — the one reading this feature must never get wrong, since an empty whitelist is what makes a
confined pad safe. Combined with the device parser that matched nothing, this class had two readers
that always returned "everything is fine".

Your permanent-exemption point is in: it reports foreign entries rather than a non-empty list,
because HidHide's own binary is whitelisted here too and --app-unreg on it does not stick.

What I have NOT verified, and why

The asymmetry test has not run. I have not seen a pad disappear from one session and stay in
another on this host.

The reason is your section 6, arriving unprompted while I was building it. The only pad on this
machine belongs to a console-side Apollo with a Moonlight client connected — created the same
way, same VID/PID, indistinguishable from a seat's. Writing a rule against it meant risking a live
session, and a wrong rule is not undone by releasing it. So I stopped.

What is proven: the rule format, the parsing against real CLI output, the ownership derivation
against the real PnP tree, and that the CLI answers. What is not: that the driver still honours the
suffix on this build. The session-0 probe is in precisely because I could not check that by hand.

That your worst failure of the week reproduced itself as a hazard on my machine, before the feature
was even switched on, is the best argument I have for it defaulting to off.

Still open from your side

EnableSeatPadIdentity remains deferred on the terms we agreed — and thank you for spelling out
which symptom to attribute to its absence, that is the part I would otherwise have blamed on the
pre-write. If you do send the confinement PRs, the pieces I would most like to compare are your
attribution code and your retry policy around 0x0005.

The gist opens fine. I have read 01 and skimmed 02; the refuted-alternatives file is the one I
expect to save someone the most time, and it is not a normal thing to be handed. Thanks for writing
it in English for us.

[vibesoftwarecoder]

Follow-up to my last comment: I said the asymmetry test hadn't run and I couldn't run it without
risking a live session. I found a way round that, so here is the measurement. It reproduces your
result on real hardware, driver 1.4.181.0.

Getting a pad to test with, without a Moonlight client

This is the part I'd have wanted three days ago. Apollo only creates its ViGEm pad while a client is
streaming — but MultiSeat has its own ViGEm path behind EnableViGEmController, and switching that
on makes MultiSeat create the seat's pad itself, at provisioning, with no client involved.

The useful property isn't the convenience, it's the epistemics: the pad appears at a moment I chose,
so diffing the device list across that moment attributes it by creation. No elimination, nothing
to guess. That sidesteps exactly the trap in your section 6 — which, as I mentioned, was live on this
box the whole time in the form of a console-side Apollo with a client attached.

The measurement

Two emulated pads present throughout. A is the console-side Apollo's, with a real client
streaming to it. B is the seat's. B was confined to the seat's session (16) by the shipped code
path, using identity attribution from config, not by hand.

rule on pad B	session 0	session 1 (console)	session 16 (the seat)	pad A
none	–	OPEN	OPEN	OPEN
USB\VID_045E&PID_028E\02!16	DENIED	DENIED err=5	OPEN	OPEN
USB\VID_045E&PID_028E\02!99 (no such session)	–	–	DENIED err=5	OPEN

Same device, same instant, three sessions, three different answers.

Your third row is the one I made sure to copy, because it's what turns this from a coincidence into a
measurement: with the suffix naming a session that doesn't exist, the seat's own session is
refused. So it's the session number being matched, not the mere presence of a rule — which is what
rules out a plain global hide, and also rules out "everyone is denied but the seat happens to be
holding a handle".

Two controls alongside it. Pad A stayed OPEN in every single reading, so nothing here was a blanket
hide. And the probe opens an ordinary file first in each session, because a probe that can't open
anything reports DENIED for every device and looks precisely like a working jail.

The service's own session-0 check agreed without being asked:

Seat ...: pad identified by configured path for Gaming
Seat ...: confined 'Controller (XBOX 360 For Windows)' to session 16 with 2 rule(s)
          [HID\VID_045E&PID_028E&IG_03\3&31042e6&0&0000!16, USB\VID_045E&PID_028E\02!16]
Seat ...: verified - session 0 is refused ..., which is what a live jail looks like from outside it

Your point about session 0 never matching turns out to be worth more than a sanity check. It is the
only way this service can confirm an undocumented behaviour still works, from the one session that
can never be the answer.

Three smaller things you may want

err=5, not err=2. A jailed device fails CreateFile with ERROR_ACCESS_DENIED, while a wrong
path gives ERROR_FILE_NOT_FOUND. Worth logging the code rather than a boolean — mine caught a bad
probe invocation purely on err=2 where I'd have believed a bare "denied".

Serial allocation, exactly as you described. The console's pad took \01 and the seat's \02,
and the seat kept \02 across a teardown and re-provision because \01 stayed occupied by the
console instance. First-come, user-mode sweep from 1, just as ViGEmClient.cpp:558 says.

One clarification so I don't look like I'm contradicting you. Releasing !16 gave the seat its
pad back immediately here, which isn't at odds with your "releasing a wrong rule does not hand the
pad back" — nothing had opened B in the wrong session, so there was no stale handle to outlive the
rule. Your case is about a session that already got a handle and keeps it. Same mechanism, different
starting state, and the distinction is worth having in writing since the two look contradictory in a
changelog.

Where it leaves things

Off by default, 5a58a6d, with the probe script at scripts\hidhide-can-open.ps1 in 52913ad if
you want to run the same comparison against your implementation.

Thank you for this. It arrived as a week of somebody else's measurements with the refuted
alternatives attached, which is not a normal thing to be handed, and the parts that cost you the most
— the XUSB node, open-time filtering, derived ownership — were all things I would have got wrong in
exactly the ways you predicted.

[jmlopezdona]

Your two sharpenings both landed, and one of them found a bug in the thing this whole feature is
built on. Taking them in the order they cost me.

Your err=5 point was a real defect here, not a note

SessionJailVerifier.Verify read only whether the handle came back invalid:

if (handle == Kernel32.INVALID_HANDLE_VALUE) return JailVerdict.Held;

So a rule matching nothing verified as a rule being enforced. The silent success this probe exists
to prevent, sitting inside the probe — and I wrote nine sections warning other people about exactly
that shape. Being the author of the argument turns out to be no protection against writing one.

Measured here before fixing it, on the host, with a positive control so a probe that can open nothing
could not fake the result:

probe	result
a real file (control that the P/Invoke works at all)	opens
a well-formed HID device path for a device that is not present	fails err=2
a malformed path	fails err=2

Both of the bottom rows used to return Held. Now anything that is not ERROR_ACCESS_DENIED returns
a new JailVerdict.Absent, which the watcher treats as not verified and logs with the code. The
5 → Held half is unchanged.

And a second-order thing I got from your write-up: distinguishing 5 from 2 is a cheap version of
your "open an ordinary file first" control. Your probe guards against a probe that cannot open
anything; reading the code guards against the same failure from the other end, because a broken probe
returns 2, not 5. Yours is still the stronger check — mine only catches it if the breakage is in the
path rather than in the process. I have not added the file-open control yet; it is the right idea.

Ask every node, and ROOT\ as a prefix — both were already right in the code and wrong in the prose

I checked rather than assumed, which is the only reason I can be specific:

• PadNodeResolver.EmulatedOf iterates every member node and takes emulated if any one of them
  says so — so the HID node's USB\…&IG_00\2&DEE0F28&0&00 parent never gets the last word.
• RootEnumeratedPrefix is @"ROOT\", matched as a prefix.

So the code does what you describe. What was wrong was every document I wrote about it, all three of
which named ROOT\SYSTEM\0001 as though it were the value and none of which said which node to
ask. Corrected in the report, the design record and our own guide, credited to you.

And your enumerator name sharpens the finding rather than softening it

This is the part I would not have got on my own. Your host reports ROOT\VIGEMBUS\0002. Mine reports
ROOT\SYSTEM\0001. The first build's bug was searching the ancestry for the word VIGEMBUS — which
failed here, and would have succeeded on yours.

So a name-based test is not merely unreliable. It is unreliable per host, and it is confirmed by
whichever machine you happen to develop on. That is the worst shape a test can have, and it is a
better argument for the bus-versus-root rule than the one I originally wrote.

Your two CLI traps do not reach us, and the reason is structural rather than luck

Worth spelling out, because it says which shape is safe rather than just "we got away with it".

The non-JSON transcript. We never batch --cloak-state with the device query. It is its own
invocation — --dev-gaming --cancel — so the JSON parser is handed JSON and nothing else.

--app-list replaying commands. Our combined read is
--cloak-state --inv-state --dev-list --app-list --cancel, and it is parsed as command lines,
not as paths, precisely because that is what --dev-list and --app-list print. So the --app-reg "…" form is the expected shape rather than a header to be skipped.

The two put together are one rule: batch the reads that print command lines, and isolate the read
that prints JSON. The failure is mixing the two in one invocation, which is the door your
--cloak-state prefix opened. The cost of the split is that our emptiness test differs per read —
the cloak-state tell covers the batched one, and the JSON read is judged on its own parse.

On your measurement

The third row is the one I would have wanted someone else to insist on, so thank you for copying it.
Both of your controls are better than mine were: pad A open in every reading rules out a blanket
hide, and the ordinary-file open rules out the instrument. That second one is the control I did not
have and should have.

Your serial observation matches ours exactly — console took \01, seat \02, and the seat kept
\02 across a re-provision because \01 stayed occupied. First-come, user-mode sweep from 1.

And your clarification about releasing !16 is right and I would rather have it in writing than be
credited with a rule that has an unstated precondition. The two statements are the same mechanism
from different starting states: a handle that was never taken cannot outlive the rule.

The instrument you found is better than the one I used

EnableViGEmController making MultiSeat create the pad itself, at a moment you chose, with no client
involved — so the device-list diff attributes it by creation. I spent a week doing attribution by
arrival timestamps against Apollo log lines, which is evidence but is still inference. Yours is not.
I will use it.

Where things stand from my side

Holding on the PRs until Nonary's direction for 1.19 is clearer, as I mentioned. One finding from
reading that code that bears directly on this project, since it is not in the release notes:

His new VHF gamepad driver would, as it stands today, stop a second seat from getting a pad at
all. The driver's slot array is machine-wide and indexed by a controller_id the client supplies,
and Vibepollo passes its own per-instance gamepad index, which every instance numbers from 0. So two
instances on one host both ask for slot 0 and the second gets STATUS_DEVICE_BUSY. With ViGEmBus that
never arose, precisely because of the serial sweep we have both been complaining about.

The good half: the driver picks the child's instance id itself (VibeshineGamepad<n>), so the path is
known before the pad exists — which is what our identity patch buys on ViGEm, for free and without a
fork. And it confines nothing, so !<sessionId> stays exactly as necessary there as here.

Read from source, not measured — I have not run 1.19.

When I do send the PRs, attribution and the 0x0005 retry policy are the two I will put first, since
those are what you asked to compare.

To start making progress on syncing my MultiSeat fork with your original, I'm going to begin by reviewing the differences between your master and my main branch, to see what's actually worth submitting as a PR and what's specific to my own environment (which I hope is next to nothing, so I'm not forced to maintain my own fork and can contribute directly to your project instead).

By the way, have you had a chance to look at https://punktfunk.unom.io/en/? It looks promising — maybe a version of MultiSeat could be made with different video streaming options.

[vibesoftwarecoder]

Two things owed to you, and an apology for the delay on the first.

punktfunk

I hadn't looked when you asked. I have now — the site first, where I drew the wrong conclusion
twice, so I went to the source at git.unom.io/unom/punktfunk.

What I got wrong: I assumed a new protocol meant new clients. It doesn't. "It speaks the existing
GameStream protocol, so any Moonlight client works day one", and the status table lists the
GameStream host as live end-to-end — pairing, RTSP, audio, per-client virtual output, zero-copy
NVENC. punktfunk/1 is the additional native path, not a replacement. It's MIT OR Apache-2.0, and
the Windows 11 host is in beta with a signed installer.

So the "you'd have to abandon Moonlight" objection I was ready to make doesn't hold. The real reason
it isn't a substitute for this project is narrower and, I think, more interesting:

Its concurrency is per-display, not per-session. "For each client that connects, the host spins
up a virtual display sized to that device — 1080p60 to a laptop, 1440p120 to a desktop, 4K to a TV,
all at once", and elsewhere, "let several devices become monitors of one desktop". That is several
clients sharing one desktop, one user account, one input focus. I found no language anywhere
about separate accounts, session isolation, or independent game instances.

Which is the same distinction that keeps coming up around Nonary's Remote Monitor: excellent
multi-viewer, not multi-seat. Everything that makes this project hard starts after that line —
separate Windows accounts so two players get two Steam logins, input that reaches one seat and not
the console, per-session audio endpoints, and this issue. A shared-session design doesn't have those
problems because it doesn't have seats, so there's nothing to borrow for them.

The part I'd actually read, and that may matter to you. Its virtual display is an all-Rust IddCx
driver, permissively licensed and shipped signed, and claimed to work on the secure desktop
(UAC / lock screen). Whatever else is true, a signed permissive IddCx driver is a hard thing to come
by — I've spent real time on that problem from the other end. I want to be careful not to overstate
it: operating on the secure desktop is a different axis from creating a display per WTS session, and
only the second one is what a seat needs. I haven't verified either claim. But it's the first thing
in a while I've wanted to read properly, and if you get there before I do I'd like to hear what you
find.

Your libvirtualgamepad reading — I think the warning is a little too strong

We read the same source independently and landed close to you, with one qualification and one thing
that cuts the other way.

The qualification. STATUS_DEVICE_BUSY comes back when that controller_id is already taken
in the machine-wide 16-slot array. It's less "the second seat gets nothing" than "the second seat
gets nothing if both instances ask for the same index". The index is chosen by the consuming
application, and that choice isn't public, so from source alone neither of us can say two Vibepollo
instances necessarily collide — only that they will if each numbers from 0, as you say it does.
The risk is real; I'd just stop short of stating the collision as certain until someone runs 1.19
with two seats. Neither of us has.

The thing that cuts the other way, and I think it matters more. VHF cannot create an
Xbox 360 / XUSB node at all. So on a VHF host the lesson we both learned the hard way here —
XInput reads the XUSB node, so hiding only the HID node achieves nothing — inverts. There's no
XUSB node to hide, and the HID rule becomes the one that does the work. Anyone porting the jail to
that driver who carries our rule across unchanged writes a rule for a node that doesn't exist and
gets a silent no-op: exactly the failure shape this issue keeps producing. Not a problem while we
ship ViGEm, but it belongs in writing before either of us ports anything.

Read from source here too — not measured, same caveat as yours.

On syncing your fork

Please do, and I'd rather see the diff early than a finished PR. If something in it is specific to
your environment I'd still like to know what and why — twice now the things you hit first have turned
out to be general (the err=5 defect, and section 6's ambiguous-pad hazard, which was live on this
box the whole time I was arguing about it). Attribution and the 0x0005 retry policy first sounds
right to me.