-
-
Notifications
You must be signed in to change notification settings - Fork 73
Implement Input Capture Desktop Portal #268
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
vaxerski
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a bit of a lengthy review, mostly style and guidelines. Many comments apply to the entirety of the PR
|
tag me for review when ready |
91e9b70 to
fb0e34d
Compare
b9b17ef to
37c5d83
Compare
|
hey, uh the new version did not compile with the following error: |
37c5d83 to
75a754a
Compare
|
I am aware, it is due to the sdbus version bumb, it should be good now |
|
I am having this: |
src/portals/InputCapture.hpp
Outdated
| @@ -0,0 +1,100 @@ | |||
| #pragma once | |||
| #include "dbusDefines.hpp" | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| #include "dbusDefines.hpp" | |
| #include "../dbusDefines.hpp" |
|
I pushed the fix |
|
i gave feedback in hyprwm/Hyprland#7919 |
Deskflow: Is this currently working? |
|
it works for me. restart ur xdg-desktop-portals after installation |
|
Also make sure that the hyprland.portal file has been copied over |
|
also, as an update, still consistently have my modifiers always held down on the client and have to restart input leap/the connection(stop then start again) to fix |
|
It seems to work fine now as the server. |
|
also @3l0w, input capture should not work in ext-session-lock. i.e. rn in hyprlock, you can still control other device via input leap |
dont know if this will work: https://github.com/waycrate/xdg-desktop-portal-luminous since hyprland is no longer wlroots. but it does have |
be33110 to
7c381c7
Compare
7c381c7 to
a1d88df
Compare
a1d88df to
b645519
Compare
|
Something weird started happening recently. I'm not sure if it's input-leap or this implementation , but whenever I start the server, there's a portion of my screen that I can no longer move to. It's roughly the size of my side monitors My hyprland setup the box I can't enter is about 1120 x 1440 fwiw, this doesn't happen in KDE with input-leap so I'm inclined to believe it has something to do with the implementation, which I've used for a while now. Only since the last update that broke my hyprland install has this been happening. Edit: Hmm, I think what's happening is the box I can't entire is actually 2560x1440. It's just the first monitor is rotated, so it's 1440x2560. And my 2nd monitor blocks off what's remain after the 1440 (2560 -1440 = 1120). |
|
I wanted to report I have been running this with deskflow and two Mac’s for the past few weeks and the experience has been rock solid. If there is any specific testing you require let me know but it’s been solid for me. |
|
the Hyprland MR is pending first |
I can confirm it has something to do with the rotated screens. I no longer see this happening after re-adjusting the screens and setting to be horizontal instead of vertical. |
|
Not sure if that relates to the upper-mentioned text, but I notice that in Discord Vertical rotated screen windows and screen itself shares in 90 degree rotation |
aa7f2f4 to
ab6dc44
Compare
|
I think something broke with the compilation. On And inspecting the file In case that it is useful, I'm trying to compile with Fedora 42 and this is my list of dependencies according to cmake Thanks |
|
Hum maybe you are missing the subproject/hyprland-protocols folder, or not up date hyprland-protocols |
|
Super weird behavior. I just checked to see if I had the hyprland-protocols and the subproject folder, and I had them installed and the subfolder there with the last update. For reference, I prepared the repo with: That gave the error I posted before. Even if I go inside the subproject/hyprland-protocols folder and I run the build and install process of the README, the error persists. But then, if I modify the CMakeLists.txt to avoid the system protocols and force the subproject one, the compilation runs flawlessly. And what is even weirder, even if I revert the changes of the CMakeLists.txt to use again the system protocols, it compiles just fine (even deleting and re-cloning the repo) I have been able to replicate this behavior in two separate computers, so I don't really know what or how is happening. I found a solution but I'm at a loss of how or why it works 😅 |
|
I recently updated to the latest on this branch. All in all this has been very stable. RE the numlock issue I was having. Pretty sure this is an issue with my machine. I am running Omarchy and this setup has a utility that messes with Capslock/Numlock. Either way, it remains consistent. Every time I move from my server to a client or back I have to turn on Numlock. The repeat key still doesn't seem to carry over from server to client. This is, by far, the most annoying issue for me. Something new that I noticed is that keyboard events are no longer being captured if the server is locked. This used to work but it no longer does. I don't know if this was expected behavior or if this is something to do with my setup. Mouse events continue to propagate, move and click. |
|
I also updated to the last version, and it works almost great, but I'm finding that if the server goes to sleep, then when it resumes libei seems to be locked and I have to restart. Using input-leap, I get the error I'm not sure if it has something to do with this input-leap/input-leap#2325, but it does not ask for permissions, there is no popup. |
Currently this impl "capture" the modifiers (num lock, caps lock, etc...), i know that mutter (gnome) doesn't do that diff --git a/src/managers/input/InputManager.cpp b/src/managers/input/InputManager.cpp
index 8cd88d02..e19bbad4 100644
--- a/src/managers/input/InputManager.cpp
+++ b/src/managers/input/InputManager.cpp
@@ -1519,11 +1519,6 @@ void CInputManager::onKeyboardMod(SP<IKeyboard> pKeyboard) {
const bool USEIME = HASIME && !DISALLOWACTION;
auto MODS = pKeyboard->m_modifiersState;
- PROTO::inputCapture->modifiers(MODS.depressed, MODS.latched, MODS.locked, MODS.group);
-
- if (PROTO::inputCapture->isCaptured())
- return;
-
// use merged mods states when sending to ime or when sending to seat with no ime
// if passing from ime, send mods directly without merging
if (USEIME || !HASIME) {If you have better results don't hesitate to tell me, maybe i will make this patch live |
Is this consistent ? I will try on my side |
|
Possibly related to permissions, I did not have them enforced. Probably was using an old version before that did not need them. I will configure them and reply back, thanks a lot! I have also found that the layout is not being passed properly, but I should check first this in case it is messing something up. My server has the Spanish keyboard layout configured in Hyprland, but the client register English keys 😅 |
|
I have been checking this today, and it was a permission problem. Now with them enforced the pop-up appears and works as it should, even after waking from sleep. However, I have been finding some more bugs using the latest version of input-leap, 3.0.3:
If you need me to log anything or give more details, I'm totally available. I wrote down what I thought would be relevant, but if anything else is needed, I'll try to help as much as I can 😁 |
Huh, quite strange i use the french keyboard and i have no issue at all, since i send the keymap to the client (Eis.cpp#L176) |
This MR doesn't aim to fix permission manager issues, the popup not appearing until reboot is a normal behavior. |
|
Hey, thanks for your time in answering
Thanks |
|
Maybe you should send here the xdph logs and also the input-leap one (set it to debug) |
|
You might also want to try out deskflow in case its an input-leap issue we have fixed already. |
|
I changed to the last version of deskflow, but it is still the same. I have logged both deskflow as DEBUG and XDPH, starting the server with everything working, and then plugging a new monitor (which disables my laptop integrated monitor), which causes deskflow to fail. The only thing I'm seeing as a warning is that it seems to have a problem setting or detecting the barrier change when the monitors change. Thanks! Here are the logs for deskflow And here are the logs for XDPH |
|
Are you sure that xdg-desktop-portal-hyprland is up to date ? |
|
I'm using the latest version of this branch Let me put here the compilation logs, just in case |
|
I'm using uwsm to launch the Hyprland session, in case it is important. I have checked the docs and it does not say anything related to XDPH, but I don't know if it might be also related |
|
You have a quite strange bug, i will publish a commit to disable the barrier check that make your xdph crash. |
|
Thanks, I'll test the new commit. If you want to add logging so that I can share it here, I will do it no problem, both for xdph and Hyprland (I currently have it compiled in debug mode) To add more information in case it could help you, this is how I'm disabling the integrated screen when I connect the external display https://gist.github.com/aron-hoogeveen/217b6d5d7e25bfda606eee94347ba6b6 |
|
I updated to the latest a couple of days ago and now deskflow doesn't work. I have uninstalled it and I am working through getting it working again. It looks like stuff works until I get to the barrier between server and client and the input disappears. It wont come back to either machine. I have to open a new TTY and switch back to Hypr to get the input back. Odd thing seeing as how the only input that worked was CTL + ALT + F2 to get to the TTY. |
|
deskflow ignores the ctrl+alt+f# shortcuts for this reason, that is in case you wanted to switch ttys |
Describe your PR, what does it fix/add?
This PR implements the input capture desktop portal with the new protocol defined in hyprwm/hyprland-protocols#8.
Fixes #259
Fixes #64
Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)
Nothing to declare yet.
Is it ready for merging, or does it need work?
It work when used with hyprwm/Hyprland#7919.
TODO List: