I managed to implement a prototype version of this, and based on logs coming from my modified version of Kloak it seems to be working… almost. I ran into a complication I didn’t expect.
Obfuscating the timing of mouse events completely throws off relative pointer movement here, because of pointer acceleration profiles. Basically something in the stack (maybe in evdev? maybe in X?) doesn’t just look at the values of each evdev event, it also also looks at the time at which each event arrived. Events that arrive in rapid succession end up moving the pointer further than events that show up with long pauses in between. Implementing the “event merging” technique described above completely confuses the system, because now the actual events are much sparser (concealing the mouse’s actual path and event timing), and so Linux simply thinks the mouse isn’t moving all that much! The result is not just laggy, choppy pointer movement (expected), but extraordinarily slow, unusable pointer movement (not expected). Properly dealing with this will probably require figuring out the details of the acceleration profile algorithm in use, so that kloak can tweak the values so as to fool the algorithm into moving the pointer far enough.
Worst case scenario, we can abandon relative movement support, absolute pointer movement should be unaffected by this. But doing that means that if someone disables mouse integration in Whonix, they could be exposing biometric data. That’s obviously not desirable, so I think it’s better to start by finding the acceleration profile algorithm and figuring out how to work around it.