Feature request: work across 'barrier' client/server pairings (Windows -> Other)

[kmac]

Is your feature request related to a problem? Please describe.

I'm wondering if it's possible to have kanata work across the KVM barrier software package. See https://github.com/debauchee/barrier.

I have a windows laptop, where I am (very happily) using kanata. I run barrier server on this laptop in order to access another linux laptop (running barrierc) as a third monitor. I've also configured a working kanata config on the linux laptop; however, either with or without kanata running on the linux barrierc laptop I don't see any of the kanata keys recognized from the windows keyboard.

Describe the solution you'd like
It would be fantastic if there is a simple solution to have the keyboard work across barrier instances.
It's entirely possible that this is an issue or limitation with barrier. I don't know.

Describe alternatives you've considered
Nothing comes to mind.

Additional context

Windows               Linux
+----------+         +-----------+
| kanata / |  =====> | kanata /  |
| barriers |         | barrierc  |
+----------+         +-----------+
  \
   \__ physical keyboard

[jtroo]

The limitation is almost certainly on the Windows side, likely to do with how barrier is intercepting keys. It may be that barrier is ignoring injected keys from SendInput, and there might be a good reason for it.

The interception driver could help, but the usual caveats for that apply (see warning in release notes). Maybe I'll poke around in the barrier code to see what they do.

[jtroo]

Ah yes, it's this code. They have logic to filter out injected events specifically. I don't fully understand what the conditions are for ignoring, so not sure if there's anything that can be done there.

    // check for special events indicating if we should start or stop
    // passing events through and not report them to the server.  this
    // is used to allow the server to synthesize events locally but
    // not pick them up as user events.
    if (wParam == BARRIER_HOOK_FAKE_INPUT_VIRTUAL_KEY &&
        ((lParam >> 16) & 0xffu) == BARRIER_HOOK_FAKE_INPUT_SCANCODE) {
        // update flag
        g_fakeServerInput = ((lParam & 0x80000000u) == 0);
        PostThreadMessage(g_threadID, BARRIER_MSG_DEBUG,
            0xff000000u | wParam, lParam);

        // discard event
        return true;
    }

    // if we're expecting fake input then just pass the event through
    // and do not forward to the server
    if (g_fakeServerInput) {
        PostThreadMessage(g_threadID, BARRIER_MSG_DEBUG,
            0xfe000000u | wParam, lParam);
        return false;
    }

[jtroo]

If you're able, I would suggest building barrier manually and mess around with the code in there to see what happens if you comment some stuff out or change the checks.

It would almost certainly be fixed by the interception driver, or some other (future, currently nonexistent) driver-level remapping solution on the kanata side as well. But for now, I think this issue is out of scope for something I can fix. I'll leave it open for some time for discussion, maybe I'll close it as out of scope at a later time, or maybe I'll leave it open with the blocked tag, not sure yet.

[kmac]

Thanks very much for this triage. I'm fine with you closing this as it seems to be on the barrier side. I'll poke around that code when I get a chance.

[flamingjupiter]

Just to keep it registered, kanata wintercept version works flawlessly with Barrier on my Windows machines.