bennyp
(Benny Powers)
November 14, 2023, 6:10am
1
I would like to use input-leap as a server on a GNOME Wayland Fedora Workstation 39, and as a client on a GNOME-Wayland Fedora Silverblue 39 workstation, as well as as a client on a macos installation.
I Installed the ei-enabled package from this COPR ofourdan/input-leap-ei-enabled
I got this output:
❯ input-leaps --debug DEBUG2 --no-daemon --name i --use-ei --config ~/.config/input-leap/default.conf
[2023-11-14T08:06:33] DEBUG: opening configuration "/home/bennyp/.config/input-leap/default.conf"
[2023-11-14T08:06:33] DEBUG: configuration read successfully
[2023-11-14T08:06:33] DEBUG1: starting server
[2023-11-14T08:06:33] DEBUG1: thread 0x00000002 entry
[2023-11-14T08:06:33] FATAL: An error occurred: Missing libportal InputCapture portal support
[2023-11-14T08:06:33] DEBUG1: caught cancel on thread 0x00000002
If i uninstall and use the non-copr version
❯ sudo dnf remove input-leap && sudo dnf install input-leap-2.4.0^20230918git004a54fb-1.fc39
in that case I get the same error as above
Then, running the GUI:
❯ input-leap --debug DEBUG2
I see in the input-leap log window
[2023-11-14T08:10:06] INFO: starting server
[2023-11-14T08:10:06] INFO: config file: /tmp/InputLeap.bnGzFW
[2023-11-14T08:10:06] INFO: log level: INFO
[2023-11-14T08:10:06] FATAL: An error occurred: Missing libportal InputCapture portal support
[2023-11-14T08:10:07] ERROR: process exited with error code: 1
[2023-11-14T08:10:07] INFO: detected process not running, auto restarting
cross-post: FATAL: An error occurred: Missing libportal InputCapture portal support · Issue #1728 · input-leap/input-leap · GitHub
chrisawi
(Chris Williams)
November 14, 2023, 7:04am
2
Did you install libportal from that COPR as well? Fedora’s libportal doesn’t yet have
flatpak:main
← whot:wip/inputcapture
opened 07:21AM - 02 Jun 22 UTC
For the corresponding Portal PR, please see https://github.com/flatpak/xdg-deskt… op-portal/pull/714
This is a draft PR to add support for the input capture portal. Most of it is straightforward portal implementation but this portal does have a larger surface and more state than most, which raises a few questions:
- [ ] ~~`XdpSession` is re-used for input capture portals now too. This makes namespacing (or the lack thereof) slightly awkward, e.g. the `activated` signal on the session is instead `inputcapture-activated` to avoid future conflicts, which then requires the other signals to be namespaced too.~~
- ~~ideally we'd have a `XdpInputCaptureSession` as subclass of `XdpSession` but the latter is declared final right now and I'm not 100% if that's an ABI break then.~~ edit: this was nacked in #102
- [ ] `XdpInputCaptureSession` now *contains* an `XdpSession` and the API is namespaced properly.
- [x] The `enable`/`disable`/`release` methods ~~are paired with their respective `_finish`, but tbh this is of questionable value. Even if the portal keeps these as requests, I'd argue hiding this away here would make for better API - we can use the session signals to notify the caller out-of-band.~~ Update June 06: these are method calls now
- [ ] the pointer barriers and capture zones have their own GObjects with properties and little other functionality. This makes for slightly more sensible API but it also conflicts a bit with e.g. `XdpSession` which doesn't have properties but setters/getters only.
- [x] the `Disabled` signal is still missing here I just noticed
- [x] there's a dbusmock/pytest based test suite included. ~~that won't run without patched dbus-python and dbusmock~~ but it makes testing *so* much easier. specifically, it allows to test libportal without an existing implementation of the actual portal. Merged to main in #99, this is just the inputcapture tests now
The above are the larger topics, I'd appreciate a high-level review of the API and suggestions for where to go with this.
cc @jadahl
bennyp
(Benny Powers)
November 14, 2023, 4:35pm
3
Thanks for the tip!
I performed the following on the server
sudo dnf remove input-leap
sudo dnf copr enable ofourdan/input-leap-ei-enabled
sudo dnf install input-leap --repo copr:copr.fedorainfracloud.org:ofourdan:input-leap-ei-enabled
sudo dnf reinstall libportal --repo copr:copr.fedorainfracloud.org:ofourdan:input-leap-ei-enabled
Then i logged out and started input-leap, and that was enough to get a session working between fedora and mac os
I then performed the same steps on the silverblue client (in a toolbox), but the copy linked doesn’t have an aarch64 build, so i guess ill have to sit on my hands for that one. @ofourdan would you be willing to add an aarch64 build to your copr? anything I could do to help?
This is already a huge improvement though
So I’ve installed input-leap
and libportal
from @ofourdan ’s COPR repo and when I configure it and try to start the server I gets asked to allow reading input and click the Share button but then gnome-shell
crashes.
Is @ofourdan ’s COPR repo already out of date with Fedora 39?
Yeah, Neal has updated input-leap in Fedora (rawhide and F39) to enable EI support, best is to use the “official” input-leap package from Fedora instead of my build in copr.
bennyp
(Benny Powers)
December 2, 2023, 5:42pm
6
So today I updated my Fedora Workstation 39 GNOME input-leap server from the first package to the second package
1st package:
Name : input-leap
Version : 2.4.0^20230914git4ecedf1d
Release : 1.fc39
Architecture : src
Size : 4.9 M
Source : None
Repository : copr:copr.fedorainfracloud.org:ofourdan:input-leap-ei-enabled
2nd package:
Name : input-leap
Version : 2.4.0^20230918git004a54fb
Release : 1.fc39
Architecture : x86_64
Size : 805 k
Source : input-leap-2.4.0^20230918git004a54fb-1.fc39.src.rpm
Repository : fedora
input-leap no longer works, and clicking the “stop” button crashes my GNOME session. This is exactly what I had prior to installing the COPR packages.
I reverted the action with this command
sudo dnf remove input-leap && sudo dnf install input-leap --repo copr:copr.fedorainfracloud.org:ofourdan:input-leap-ei-enabled
and found that input-leap immediately started working again