Peter Hutterer

> Aha, so the capabilities reported here about capturing and compositor/libei can still think otherwise about the events sent. correct. the libei events must be a subset of the capabilities...

> Will this input portal allow something equivalent to EVIOCGRAB? Two comments here: First, with this portal, an application can *capture* input, even when sandboxed. IIRC your use-case requires *replaying*...

> It sounds like this new input portal won't be able to support EVIOCGRAB since it uses "libei" and I'm guessing it's not using evdev and may not have access...

For more clarification: XTEST is an X11-specific API to emulate input events. That one doesn't work on Wayland compositors and does not work on Xwayland either (though Xwayland is getting...

Oh, right. So in that case - what would be needed here is a new trigger for the CaptureInput portal so you can effectively capture input on request by the...

> Having some way of preventing the input from ever come back to us like you suggest would be even better. Since this is all controlled by the compositor, it's...

FTR, I've rebased this on top of #762 now because the use-case we're working on all require both RD and IC to have the new EIS functionality anyway. The patches...

It all hinges on libei which hasn't had a stable release yet because the protocol is not stable. That's being worked on, but meanwhile we keep everything else in draft,...

ftr, libei 1.0.0RC1 was released last week and the API is now stable. however, this PR was updated to remove any dependencies on libei itself - just like #762 there...

cc @fooishbar