Support for org.freedesktop.portal.RemoteDesktop?

[lessu]

portal.RemoteDesktop interface is not implemented, so we are lacking the ability to work with remote controlling Apps, like rust-desk.

Is there a plane to implement?

[vaxerski]

not atm

[gac3k]

@lessu @vaxerski so since that subject was brought again, I will confess that I actually started to implement that on my own some time ago, to have a proper support for tools that are currently requring that portal such as InputLeap.

This is my current effort: a8553de

Which is not even close to finish, contains a lot of bloat and is violating a lot of rules, but what I already have in there is a RemoteDesktop basic implementation with a support for basic mouse movements, as well as a seperate small application named hyprland-eis which is based on emulated input server example from libei, and that is because tools such as InputLeap are only using RemoteDesktop portal to connect to device, and then there's a method which is only returning a file descriptor to the emulated input server socket, through which all the actual traffic so mouse movements, key presses etc. is being served. Also since this is my use case it's the easiest way for me to test the whole thing.

All together, I currently do have it in the state in which I can create a working connection between InputLeap/Barrier server and to connect to my Hyprland based InputLeap client, I can then also move the mouse freely between these two targets, which already I think is quite a lot. Currently struggling a bit with a keyboard presses, mostly due to all the xkb specific quirks, but I think I am getting there as well.

That being said, C/C++ are almost completely unknown languages to me, and I am learning while coding that piece of code, and I am doing that mostly because there are no other volunteers and I need it for my life to be fully comfortable. So in general a quality of that (especially currently since it's simply work in progress experiment) is terrible... but hey, it works (at least till the certain exempt) :D

So now going to the end if I would have some support/guidance from the @vaxerski or any other contributor who could help me to review that (once finished) and to iterate on potential fixes if needed I am happy to continue working on that.

[leon-erd]

Thanks a lot for trying to implement that.
I would also love to see full support for it. I am using kdeconnect which also requires this for mouse movement and keyboard presses. There is a MR in the xdg-desktop-portal-wlr project which also tries to implement that: emersion/xdg-desktop-portal-wlr#263
Different ppl have progressed it bit by bit. I have actually been using this: Enovale/xdg-desktop-portal-wlr@11817f9 on hyprland (in addition to xdg-desktop-portal-hyprland) for some months now. For me it works well enough and is certainly an upgrade compared to no remote control at all.
All basic lower case letters are working as well as mouse movement.
Maybe his implementation can help you with yours. He is also new to C so maybe you can help each other out :D

[Tsagadai]

This is good progress. It should be possible to use libei directly or at least calling the upstream interfaces that are implemented now. I'm also taking a look at this and I'll submit a PR soon too.

[nnra6864]

Would be really nice to see this feature at some point.

[gac3k]

@nnra6864 @Tsagadai @leon-erd if somebody is interested, I have like a first POC created as a separate xdg-desktop-portal because for now it was an easier option for me to create, rather than playing around with the official hyprland desktop portal, and adding that feature on the top.

The above is not fully completed, and I am not going to lie... plenty of that was vibe-coded for now just to check whether that implementation might actually work, but it's doing fine on my machine, meaning I have usable mouse and keyboard utilizing deskflow on macos as a server.

If anybody wants to try it out let me know in here, and I can try to help you to build it on your OS. Technically, it should also work on your system out of the box after doing the build process with cmake, and then doing sudo cmake --install. I did not have a chance to test it though since I am using nixos and had to create a custom derivation for that to work.

In any case, with some help with the tests, I should be able to move forward with it, and maybe it could be either taken from here to somehow port it into official xdg-desktop-portal or if that's not possible, that could at least live as it's own thing to fulfill that gap for these very few people that needs it like me and you :D

https://github.com/gac3k/xdg-desktop-portal-hypr-remote

[fufexan]

@gac3k I've run the test script, here's the output:

test script output

[nix-shell:~/Documents/code/git/xdg-desktop-portal-hypr-remote]$ ./test_portal.sh 
🧪 Testing Hyprland Remote Desktop Portal (Development Mode)

Building Hyprland Remote Desktop Portal...
-- Building in DEVELOPMENT mode - will use .dev service name
-- Configuring done (0.0s)
-- Generating done (0.0s)
-- Build files have been written to: /home/mihai/Documents/code/git/xdg-desktop-portal-hypr-remote/build
[ 21%] Built target generate_protocols
[ 47%] Built target wayland_protocols
[ 68%] Built target test-virtual-input
[100%] Built target xdg-desktop-portal-hypr-remote
✓ Build complete!
Executable: build/xdg-desktop-portal-hypr-remote

To run:
  cd build && ./xdg-desktop-portal-hypr-remote
Setting up development D-Bus environment...
✓ Development files created:
  Service: ~/.local/share/dbus-1/services/org.freedesktop.impl.portal.desktop.hyprland.dev.service
  Portal:  ~/.local/share/xdg-desktop-portal/portals/hyprland-dev.portal

Testing the portal directly...
Should see 'Portal registered on SESSION bus' if working!
Press Ctrl+C to stop

Hyprland Remote Desktop Portal starting...
Wayland Virtual Keyboard initialized successfully
✓ Virtual keyboard initialized
Wayland Virtual Pointer initialized successfully
✓ Virtual pointer initialized
Initializing LibEI Handler...
EI receiver context created for portal file descriptor sharing
✓ LibEI Handler initialized successfully
✓ LibEI handler initialized
✓ LibEI handler started and ready for connections
LibEI Handler running and processing events...
Portal D-Bus interface registered at org.freedesktop.impl.portal.desktop.hypr-remote
Portal registered on SESSION bus (not system bus)
Portal version: 2
Portal path: /org/freedesktop/portal/desktop
Portal interface: org.freedesktop.impl.portal.RemoteDesktop
Portal D-Bus interface registered at org.freedesktop.impl.portal.desktop.hypr-remote
Portal registered on SESSION bus (not system bus)
✓ D-Bus portal initialized

🚀 Hyprland Remote Desktop Portal is ready!
Portal available at: org.freedesktop.impl.portal.desktop.hypr-remote
Press Ctrl+C to stop.
🔄 Starting proper sdbus D-Bus event loop...
📡 Portal ready to receive D-Bus calls!

Is this supposed to make tools like KDE Connect's Remote Input work directly?

[leon-erd]

Isn't this:
#308
together with this:
#268
hyprwm/Hyprland#7919
hyprwm/hyprland-protocols#8

what we are waiting for? 🙈

[gac3k]

@fufexan As long as they're using RemoteDesktop portal yes, InputCapture portal is not implemented yet, most importantly xdg-desktop-portal service probably has to be restarted after that instance is spawned, and new portal is registered.

@leon-erd Not sure who should answer that question. wasn't aware of these PR-s to be honest. I did a short attempt on that one back in september, then gave up and just used waynergy as workaround for a time being, but got back into this a few days ago since I wanted to give it a shot to Deskflow, which seems to be actually well maintained in comparison to Barrier (not maintained at all) and input-leap, From my point of view, the fact that these PR-s are waiting months to be merged, and generally speaking that subject is hanging like forever, would be cool to either push it somehow, or as an alternative, just create an own independent portal, what I did above. If these are merged though, that's resolving the whole issue, so fingers crossed...

@vaxerski any input here?

[segln]

#308 works fine for me. I’m waiting for that PR to be completed.

[ConnorField]

Probably not helpful haha - but I know at least 10 who are waiting on Deskflow support to move to Hyprland
It's the only thing stopping me moving 3 machines from KDE.

If this is a 'needs more hands' thing, is there anything I can do to help?

[gac3k]

@ConnorField From my point of view, would be good to get an answer from one of the main Hyprland contributors to understand when it might be merged, and what is the decision behind keeping these PR-s in the limbo for months. If that's still not the case, I would really just move that logic to the separate xdg-desktop-portal, technically there's nothing wrong about this

[fufexan]

AFAIK we don't have any blockers on the Hyprland part. But reading the description of #268:

Is it ready for merging, or does it need work?

It work when used with hyprwm/Hyprland#7919, but still need work, like sending the keyboard layout, or security concerns.

So that needs addressing first.

[gac3k]

@fufexan Yeah, I am aware, but also that PR has origins in September last year, we are 9 months further down the road, and it's still in the draft state, it's being updated of course, and I can imagine at some point it'll be merged, but the problem here is that there are two portals that should be supported RemoteDesktop and InputCapture, at least to have bidirectional support for apps like Deskflow, inputLeap, Barrier etc. The PR-s are targeting either of them, but not both, and also to make things more complex, these PR-s are both in the main Hyprland repo and in the xdg-desktop-portal-hyprland... so while of course I fully understand that this is not a top priority for the Hyprland team to merge, there is a variety of concerns given the delicate nature of the input capture thing, and at the end of the day there's a very specific niche that needs this solution... but it's still there :D And the main issue to me is that there's no comment on when all of these could potentially be merged, or if there's even a plan to do this. That's why I was thinking of moving to a temporary solution with a dedicated portal for that particular case should at least be an option.