00:00 eruditehermit: ok it's the entrypoint but it can't find it
00:05 eruditehermit: this time it's worth building in docker, it's a path issue i'm pretty sure
00:16 eruditehermit: so close
00:36 whot: eruditehermit: fwiw you don't need --filesystem=xdg-run/eis-0 anymore
00:37 eruditehermit: whot: ok I removed that
00:37 eruditehermit: whot: building locally has different issues =P
00:37 eruditehermit: nothing is free
00:47 eruditehermit: ok on the CI build it didn't fix things
00:47 eruditehermit: my local build I'm stuck because it can't flatpak build-init properly
00:59 eruditehermit: whot: had to run the container --privileged
01:23 eruditehermit: progress
01:24 eruditehermit: https://github.com/rohitpid/input-leap/actions/runs/10803213152/job/29966690141
02:40 eruditehermit: ok I think I got it
03:08 eruditehermit: whot: https://github.com/rohitpid/input-leap/actions/runs/10804183760 I have a flatpak! Now to figure out how to even run it
03:09 eruditehermit: whot: https://bpa.st/MZQPU
03:38 whot: eruditehermit: nice. fwiw I've filed a PR in libei to get rid of python-attrs, it's not really needed and one dep less
03:39 eruditehermit: whot: very nice
03:40 eruditehermit: whot: do you know what the config files should look like. The readme is quite light on the subject
03:40 whot: eruditehermit: in the input-leap-flatpak script you can drop the LIBEI_SOCKET bits, they're no longer needed
03:40 whot: eruditehermit: that's my config here: https://paste.centos.org/view/11444306 and iirc most of this was auto-generated
03:41 eruditehermit: you want me to drop this right: export LIBEI_SOCKET=$XDG_RUNTIME_DIR/eis-0
03:41 whot: i *think* you can now just start normal input-leap and it will DTRT instead of wrapping it via that script. That script pre-dates most of the implementation
03:41 whot: yes, you can drop that export
03:42 eruditehermit: whot: if you have time, can you test the flatpak?
03:43 whot: unfortunately no, i'm completely swamped for the rest of the week
03:43 eruditehermit: ok
03:43 whot: change to `command: input-leap` and see how that works, that should start the gui (iirc)
03:44 eruditehermit: is it safe to change the compile flag that disable the GUI?
03:44 whot: you might need a few more deps then but otherwise yes
03:45 eruditehermit: -DINPUTLEAP_BUILD_GUI=OFF
03:46 eruditehermit: ah qt5
03:47 whot: might be worth using the KDE runtime for that though not sure that one has the required bits to build libportal
03:48 whot: but saves you having to install all of qt manually
03:48 eruditehermit: whot: yeah I'm trying with the kde runtime
03:48 eruditehermit: can you build with 2 runtimes?
03:49 whot: i don't think so but not sure
03:49 eruditehermit: ok well let's see if it works
03:50 eruditehermit: your config looks pretty complex
03:50 whot: I think the only one I added was the key toggle, the rest is the default template
03:52 eruditehermit: I assume this is the InputLeap.conf
03:52 eruditehermit: what is server.name
03:52 eruditehermit: just a file with your IP address?
03:54 whot: huh?
03:55 eruditehermit: whot: the error I pasted: https://bpa.st/MZQPU talks about 2 config files
03:58 whot: hmm, I don't remember. the path is wrong too, should be input-leap, not InputLeap (I think)
03:59 whot: oh, I think I remember: the client requires the server name to connect but you can't easily add args to a flatpak so this was the way around it. echo "foo" > server.name means the flatpak will run `input-leapc foo`
04:00 eruditehermit: so I'm a bit confused, will there be 2 executables a server and a client we need to export
04:00 eruditehermit: looks like input-leapc and input-leaps
04:00 whot: again, if you just start input-leap it will present you with the GUI to select client or server
04:01 eruditehermit: ah yeah building with GUI is going to be trickier
04:01 eruditehermit: changing to KDE runtime breaks the portal build
04:01 whot: this flatpak wrapper script was written quite early for debugging and testing, so definitely don't take it as gospel, it was a PoC mostly
04:02 whot: the best way around that would be to replace libportal with QtDbus :)
04:02 whot: we didn't do that because ETIME
04:02 eruditehermit: haha this requires more understanding of the code
04:02 eruditehermit: but more specifically the understanding of qt and portal
04:02 whot: hence ETIME :)
04:02 eruditehermit: which I could eventually get to but it's probably not a short term thing
04:03 eruditehermit: I was hoping to be able to test it without the gui
04:03 eruditehermit: if I can get a small win, I will try to get the GUI to work tomorrow
04:05 whot: replace quokka and tassie with your host names and save that as config and you should be able to run it as server
04:05 whot: and echo your server's hostname into server.name on the client and you should be able to run it as client
04:07 eruditehermit: ok sounds good
04:12 eruditehermit: whot: which of quokka and tassie are the client/server?
04:14 whot: whichever one matches $HOSTNAME iirc
04:22 eruditehermit: interestingly I thought barrier used gtk
06:24 eruditehermit: whot: is there anything sacared about your shell script wrapper? Is there anything stopping me from writing a bash shell script with proper cli args to be able to read configs from arbitrary locations?
06:30 eruditehermit: whot: https://bpa.st/QGLSC with your config slightly modified
06:40 whot: eruditehermit: no, go for it
06:40 whot: as I said above this was mostly a PoC anyway
07:02 eruditehermit: I guess I'm stuck anyway
07:02 eruditehermit: I hit that issue with portal
07:03 eruditehermit: do I need a newer native portal or is the one in the flatpak enough?
08:16 eruditehermit: whot: ok I built it with the GUI
08:52 eruditehermit: holy wow the GUI works
09:45 eruditehermit: whot: if you feel like trying the flatpak with GUI is here: https://github.com/rohitpid/input-leap/actions/runs/10808407119
09:46 eruditehermit: I couldn't get the mouse/kbd sharing working between my computers
09:47 bluetail: if software isnt doing it, I can recommend a ezcoo usb switch
09:48 eruditehermit: bluetail: which one, there seems to be one for $30 and one for $130
09:48 eruditehermit: software would be ideal because it's supposed to be seamless =P
09:49 eruditehermit: however I've given up a day to try to get it to work so maybe I should take a hint
09:52 eruditehermit: I appreciate everyone's help and suggestions. Thank you for the support and responding to all the questions. I've learned a lot so it was interesting.
09:52 bluetail: eruditehermit ‎EZ-SW24-U3L for 16.99
09:52 bluetail: The larger ezcoo models with video were not working for me properly
09:53 bluetail: I use a programmable IR remote to switch
09:54 eruditehermit: that looks nice
09:54 eruditehermit: I have a ugreen one at work which has a select button however, it never works properly the first time. I have to wake it up by switching from one input to the other
09:55 eruditehermit: output really
09:55 ofourdan: eruditehermit: I do not see your script using "--use-ei"
09:55 ofourdan: (the command line spawned)
09:56 ofourdan: so I do not think it's using EI actually
09:56 ofourdan: which would be a requirement to work with Wayland
09:56 eruditehermit: ofourdan: whot told me there were some EI lines not necessary
09:56 ofourdan: I think it it has the choice between x11 and ei, it will chose the former still
09:56 eruditehermit: ofourdan: did you run with: flatpak run com.github.inputleap.InputLeap
09:57 ofourdan: yes
09:57 eruditehermit: did the GUI pop up?
09:57 ofourdan: I can se input-leap connecting to the portal, but it doesn;t interact with the compositor, so I suspect it is not using ei
09:57 ofourdan: yes, the gui showed up
09:57 bluetail: eruditehermit I have it paired with ddcutil so I automatically switch display out too!
09:58 bluetail: eruditehermit https://0x0.st/Xx1Q.sh
09:59 eruditehermit: ofourdan: https://github.com/rohitpid/input-leap/blob/rp-feat-flatpak-ci/dist/flatpak/com.github.input-leap.input-leaps.yml
09:59 eruditehermit: ofourdan: is there a compiler flag I need for libei?
10:00 ofourdan: it's there, but when running input-leaps or input-leapc you'd need to pass --use-ei and I do not see that
10:00 eruditehermit: bluetail: thanks for the script, I need to read up on ddcutil as I am not familiar with it
10:00 ofourdan: so you have EI support enabled in the build, but I suspect you're not actualyl using it :)
10:03 ofourdan: but then that's what the gui does, in which case the gui might be missing the feature to enable EI...
10:03 eruditehermit: ofourdan: is it a flag to the executable?
10:04 eruditehermit: ofourdan: ↳ flatpak run --command=sh com.github.inputleap.InputLeap
10:04 eruditehermit: ofourdan: then /app/bin/input-leap --use-ei
10:04 eruditehermit: or whatever flag you think it is
10:04 ofourdan: still need to pass the configs etc.
10:05 eruditehermit: it still pops up the GUI
10:07 ofourdan: it doesn't spawn input-leapc/input-leaps with the requires--use-ei option though
10:07 ofourdan: the option is for the actual server or cleint executables.
10:09 eruditehermit: I see a bunch of failed to initialize InputCapture session no such methoid org.freedesktop.portal.InputCapture
10:09 eruditehermit: when I look at the logs
10:11 ofourdan: I just checked, your flatpak with teh correct --use-ei options works just fine :)
10:12 eruditehermit: ofourdan: that's great to hear!
10:12 ofourdan: I am of Fedora 40 though, as I said, I do not know about other distributions
10:12 eruditehermit: ofourdan: gnome or kde?
10:12 ofourdan: s/of/on/
10:12 ofourdan: GNOME Shell, both client and server
10:12 ofourdan: I could try KDE
10:13 eruditehermit: can you try one gnome and one kde
10:13 eruditehermit: that's what I have and it gives me that error above
10:13 eruditehermit: but maybe that's because of the ei
10:13 eruditehermit: ofourdan: does flatpak require the base system portal to be a certain version?
10:14 eruditehermit: my system deb libportal is at 0.7.1 which is missing some stuff it seems
10:14 ofourdan: the portal runs on the system, so yes
10:15 eruditehermit: what libportal version do you have?
10:16 ofourdan: works a treat with KDE as well :)
10:17 eruditehermit: that's great
10:17 ofourdan: libportal is at 0.7.1 but it's not just libportal, there's the portal, compositor, etc. as well
10:17 eruditehermit: oh do I need those installed?
10:17 ofourdan: the compositor, you have it already, portal most likely
10:18 eruditehermit: I have: xdg-desktop-portal-kde
10:18 ofourdan: but I mean, those need to be at a version which supports the features required by input-leap with EI to work
10:19 ofourdan: fwiw, I have xdg-desktop-portal-1.18.4, xdg-desktop-portal-kde-6.1.4 and xdg-desktop-portal-gnome-46.2 here
10:20 ofourdan: of course you do not need the kde portal for gnome and vice-versa
10:20 eruditehermit: https://bpa.st/ZF7DG
10:20 eruditehermit: but I am on kde 5.27 so maybe it's fine
10:21 ofourdan: tbh, I have no idea whether kde 5.27 had support for that
10:22 eruditehermit: is there a way to easily fix the --use-ei flag to start with
10:22 eruditehermit: I can try 2 gnome machines tomorrow
10:24 ofourdan: anyhow, all thta to say, AFAICS, your flatpak has all it takes to work on a Wayland + EI setup, except that the GUI is not passing the required --use-ei option - Would be a nice thing to contribute upstream ^_~
10:24 eruditehermit: the flatpak stuff or adding the --use-ei?
10:24 ofourdan: adding the --use-ei
10:25 ofourdan: so one can use input-leap GUI with a Wayland + EI setup
10:25 eruditehermit: lol, I'd have to learn qt and learn this code base.
10:25 eruditehermit: I'm not saying I won't, it'd just not happen immediately
10:25 eruditehermit: I'm not saying I won't try, whether I can actually do it is another question
10:25 ofourdan: usually, what I do in a case like that. is to search for an existing UI string, and take example
10:26 ofourdan: (search in the code, I mean)
10:26 eruditehermit: yeah
10:26 ofourdan: failing that, filing an issue upstream would be a good first tep as well :)
10:26 eruditehermit: really this shouldn't even be a configurable really. It should be autodetected when wayland is enabled
10:27 eruditehermit: perhaps I am misinterpreting, upstream didn't seem too pleased with me messing with this =P
10:27 ofourdan: problem is x11 is also available through Xwayland, and strictly speaking EI is agnostic to the windowing system, it should work with x11 as well
10:27 ofourdan: ah, what makes you think that?
10:28 eruditehermit: I talked to them on libera irc and they almost sounded like not having packages was a feature because it's too early to make a release
10:28 eruditehermit: I'll try submitting this flatpak stuff as a PR and raising an issue
10:29 eruditehermit: I imagine it's faster for them to do all this stuff on their own than answer questions
10:29 ofourdan: thanks! it's noice to have that flatpak updated, that's a good starting point!
10:29 ofourdan: *nice
10:30 eruditehermit: I wanted the automated build so I didn't have to build it myself
10:31 ofourdan: I reckon that's how most contributions start from, wanting something that's not there yet :)
10:35 bluetail: eruditehermit for ddcutil u want sudoers or group
10:39 eruditehermit: bluetail: I have bookmarked your code and will have a look tomorrow. It's super late here
10:39 eruditehermit: thank you
10:40 eruditehermit: ofourdan: thanks for your help testing too
10:40 eruditehermit: i'll submit the PR and issue tomorrow and see if the devs are around to chat
10:42 eruditehermit: ofourdan: are you on #inputleap-dev or #inputleap on libera?
10:42 eruditehermit: or just a curious user?
10:43 eruditehermit: fedora 40 has rpms so the flatpak is least useful to you I guess
10:54 eruditehermit: ok gnight thanks again
13:38 wlb: weston Merge request !1588 merged \o/ (Add a new client: weston-color https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1588)
13:38 wlb: weston/main: Joan Torres * clients/window: Allow rendering frame wihout shadow https://gitlab.freedesktop.org/wayland/weston/commit/53419eb9918b clients/window.c clients/window.h shared/cairo-util.c shared/cairo-util.h shared/frame.c
13:38 wlb: weston/main: Joan Torres * clients: Add color https://gitlab.freedesktop.org/wayland/weston/commit/a266c5fff5fd clients/ color.c meson.build
15:57 light_: Hi, is there any working example of how xdg-decoration can be added to a wayland compositor, in C?
16:01 emersion: the implementation would differ a lot depending on the specific compositor
16:01 emersion: which one is it?
16:01 light_: my own that i am making
16:02 light_: what is the basic steps?
16:02 emersion: it's not very different from other protocols
16:03 emersion: for the basics maybe have a look at wlroots
16:03 light_: yeah, that what i have been doing.... is there any others?
16:07 ofourdan: kwin has support for xdg-decorations as well
16:08 ofourdan: (-s)
16:08 light_: kwin is c++ i think
16:08 ofourdan: it is, yes
16:10 ofourdan: there's that, might be useful to you: https://wayland.app/protocols/xdg-decoration-unstable-v1#compositor-support
16:13 light_: thanks
17:58 sewn: what would happen if a registry global_remove event was sent to delete an object (eg. seat) that another object (eg. ext_idle_notification_v1) is tied to?
17:59 vyivel: ext_idle_notification_v1 probably becomes inert then?
18:01 sewn: hm, i guess needs user data (set object data to a seat) to determine if that is the case and do something about it
18:01 sewn: thanks
18:46 phodius: when adding xdg-decoration protocol i get error wl_display#1.error(wl_display#1, 1, "invalid method 2, object xdg_toplevel#13
18:48 phodius: i have a function for xdg_toplevel_set_title so what else could be the issue?
18:48 phodius: this is for compositor not client
18:52 phodius: yelp!!!.....it loads windows fine when i dont use the xdg-decoration protocol....
18:53 vyivel: maybe wrong resource interface or something
18:54 phodius: hmmm..
20:42 eruditehermit: @ofourdan: can I tag you on the PR to main inputleap as someone who has tested the flatpak?