Comment by jchw

Even if you do generate legacy input events, it is worth noting that the kernel still knows that they're not real input events. It seems to keep track of the current event on a per-thread basis (maybe it's stuffed into the TIB or something, but it could also just not be visible, I didn't search too deeply.) The knock-on effect of this is that sometimes DefWindowProc won't do the expected thing if you feed it a synthetic event, which could lead to strange behavior. You can of course use CreateSyntheticPointerDevice[1], and try to emulate it like that, but obviously then it knows that the events are coming from a synthetic pointer device (which is also system-wide and not just per-application!) So it feels like any way you go, behavior will be slightly different than expected.

Will this matter? I'm not quite sure.

I think Microsoft's WebView2 component enables Mouse-in-Pointer mode using the undocumented syscall for doing it per-HWND, but apparently Raw Input is per-entire-process, so if you aren't generating "legacy" events, will a WebView2 component in your process function as expected? Maybe if you go the synthetic pointer route, but again, that's a pretty big can of worms in and of itself.

Windows input is indeed very tricky. Seems like there's only one way to figure out some of these answers. Perhaps I should add RawInput to my test application and find out what the interaction is.

[1]: https://learn.microsoft.com/en-us/windows/win32/api/winuser/...