Ei protocol support using reis - #1388
Conversation
53c0ca9 to
225f716
Compare
|
Oops, I've been doing the same thing in Niri. I ruled out upstreaming to Smithay because I thought the implementation would have more Niri and Some comments on your code: ( I wrote an adapter struct between Doesn't Smithay specify that IDs must be unique? I currently pass a I can also provide a true |
Yeah, the same module or type name being used for different things in different parts of
https://docs.rs/smithay/0.7.0/smithay/backend/input/trait.Device.html says "Unique id of a single device at a point in time." and "Note: This means ids may be re-used by the backend for later devices.". I suppose with ei, the protocol object id would be unique in that manner. |
|
Probably the biggest question here is exactly how much of it Smithay should handle/abstract. But I think we probably should just clean up any issues with the event conversion, and merge a minimal version of this. Then see what further abstractions are useful to add in either |
|
I think I've come up with a reasonable API for input emulation using libei. (Input capture for something like the Input Capture portal may have different requirements). Mirroring the Smithay seat API a bit, to provide an API that should be flexible enough without requiring the compositor to do too much. I've also moved some things into |
|
I guess this will also need to send For a unique device Edit: I guess fds racing isn't an issue, because as long as we're processing the event source, the fd isn't closed. |
e8c4b19 to
aa010ff
Compare
db24f42 to
2c1d922
Compare
1a6b229 to
587a092
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1388 +/- ##
==========================================
- Coverage 18.77% 18.69% -0.09%
==========================================
Files 180 182 +2
Lines 28743 28879 +136
==========================================
+ Hits 5397 5399 +2
- Misses 23346 23480 +134
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
The EI protocol is needed for the xdg-desktop-portal `RemoteDesktop` portal to emulate input devices, as well as by the `InputCapture` portal for Synergy-like uses (input-leap supports Wayland with this portal). This exposes a relatively simple API for a compositor to create EI seats and devices, mirroring the `Seat` API. It also provides an `InputBackend` that converts emulated input to Smithay input events. Receiver contexts for the `InputCapture` portal are also a bit more complicated to implement. Those involve capturing input once the cursor crosses outside the display. That isn't implemented at all here yet. We may want to change things in the future to accommodate receiver contexts, etc. But this API is fairly minimal to use, so future breaking changes shouldn't be too challenging for a compositor to adapt to.
This seems a bit awkward to support on other backends given how Anvil uses `process_input_event_windowed` there... This implementation creates a socket file and sets `LIBEI_SOCKET` to allow sending emulated input events to Anvil.
|
Merged in #2051. Any future improvements can now be done in separate PRs. |
3 participants
The Ei protocol is needed for the xdg-desktop-portal
RemoteDesktopportal to emulate input devices, as well as by theInputCaptureportal for Synergy-like uses (input-leap supports Wayland with this portal).This is quite incomplete, but the
type-textexample inreisnow works in Anvil. Reis could still use somewhat better higher-level servere-side APIs.It might make sense if ei exposed seats and devices matching those in Smithay (or would compositors not always want to do that?). Not sure how best to handle that.
Receiver contexts for the
InputCaptureportal are also a bit more complicated to implement. Those involve capturing input once the cursor crosses outside the display. That isn't implemented at all here yet.