For remote desktop support, we need to move with the pointer using absolute positin.
Details
I tested this with xdg-desktop-portal-kde and krfb and it worked.
Diff Detail
- Repository
- R127 KWayland
- Branch
- master
- Lint
Lint Errors Excuse: it's a Qt macro Severity Location Code Message Error src/client/xdgshell.h:92 Cppcheck unknownMacro - Unit
No Unit Test Coverage - Build Status
Buildable 6859 Build 6877: arc lint + arc unit
src/client/protocols/fake-input.xml | ||
---|---|---|
19 | Version of the interface has to be bumped. |
src/client/fakeinput.h | ||
---|---|---|
139 | Wouldn't QPointF be a better choice? |
src/server/fakeinput_interface.cpp | ||
---|---|---|
164 | Please delete one extra empty line. |
Add information when new methods were introduced and bump version of FakeInput in registry
src/client/fakeinput.cpp | ||
---|---|---|
106 | if (wl_proxy_get_version(d->manager) < ORG_KDE_SOMETHING_SOMETHING_FAKE_INPUT_VERSION) { |
src/client/protocols/fake-input.xml | ||
---|---|---|
86 | since="3" |
src/client/fakeinput.cpp | ||
---|---|---|
106 | Use curly braces even when the body of a conditional statement contains only one line. |
I didn't intent to push this together, but when creating a branch from master which already had first round of changes caused my second part of changes to be pushed here. I hope you don't mind that. I'm doing this in a hurry hoping to get exception from David Faure to include this with KDE Frameworks 5.54. I thought the tagging is this saturday and tarballs are made after that, but I was wrong. I would really like to push the remote desktop support into Plasma 5.15, I have almost complete support in xdg-desktop-portal-kde and krfb.
I don't want to have key press/release in it. It has a reason that I didn't add key press/release from the start. The problem is the mismatch of key events and keysyms. Especially the kdeconnect use case for which this interface was developed has this problem. Android composes text, not key codes. Thus it would not be possible to inject key events.
Also from a security perspective I'm strictly against adding fake key events. That's one of the largest security problems on X11. I rather have no remote support than a gaping security hole.
I'm the author of this interface and I consider it nowadays as a mistake to have added it. If I would restart I would do the whole thing differently: input events need to be injected through a kernel module in a dedicated input device. It would need a user space component which processes can talk to and that would need to be secured though e.g. polkit. Thus we could properly authenticate. This protocol does not support it and KWin does not even try to authenticate. Overall from security perspective this is a mess.
Hi, can I get please this re-approved? It's now just again about the additional mouse support.
@jgrulich With D22571 looking promising do you want to put the keyboard parts of this diff into a separate one? There is still the question about keysyms and key events but we should discuss this in the new diff. Maybe we can have both: Keysyms for special keys / combinations like Alt+Tab and text input via text-input protocol?
I currently don't have that much time to look into this, but I'm glad we can move with this further. Maybe Akademy is a good opportunity to work on this, there are also some things which would be nice to improve in screen sharing support.