Question: How to integrate with KDE Connect and gsconnect?

[fmuelle4711]

I have a working Android remote spotlight, works as follows: Install KDE Connect on Android phone, pair with a patched gnome-shell-extension-gsconnect. ./projecteur -D 2:a (or any other device that is a mouse and works) ./vmouse-receiver /dev/input/event4 (or whatever event the mouse device is attached to) Go into presenter mode in KDE connect, hold "Pointer" to move spotlight on screen.

Now, this still requires some real mouse device, which is inconvenient. So I tried to move the uinput mouse with a running presenteur (new dev version w/ uinput), and it works: ./vmouse-receiver /dev/input/event21 (or whatever event /dev/uinput is attached to) I can now move my mouse pointer on screen since presenteur has created such a device.

But the spotlight is not active. A patch to spotlight.cc removing the emitEvent() calls to the virtual device (since that would create a loop)) and inserting a sleep(1) delay after opening the virtual device allows the udev rule to add user rw access and then I can connect to it: ./projecteur -D feed:c0de When I now move the phone, a get a spotlight on screen for just a moment, but it the X/Y position updates emitted by vmouse-receiver do not update the mouse pointer position on screen anymore. Of course, /dev/input/event21 is now being written to by vmouse-receiver and read by projecteur, but that was also the case before with a physical mouse device (my 2:a example above).

Do you have any idea how to approach this problem? I'm at a loss.

Even without uinput, people might be interested in this. One question is: Should a new plugin for KDE Connect (Android side) be created, derived from their presenter? That could also have hot keys to change zoom, spotlight shapes etc.

And another way to go about this would be for projecteur to directly accept the socket connection from gsconnect that I created and then update the spotlight (maybe even without mouse movement).

Finally, a patch for KDE Connect (PC side) is needed, similar to my gsconnect patch.

If you want to try it out, here are the patches and vmouse-receiver: https://arcb.csc.ncsu.edu/~mueller/projecteur/

[jahnf]

Phew, that's a lot of text for me early in the morning :sweat_smile:

Just for clarification and a basis for discussion so I can understand where KDE connect comes into play: Here a simplified overview about events are handled with and without a upinut device:

So I never used KDE connect or gsconnect. Does KDE connect create it's own virtual device?

[fmuelle4711]

gsconnect was directly manipulating the cursor position via qt5, without any device. My patch removed their qt5 call, instead position updates are sent via a socket to a new vmouse-receiver, which uses evemu events to update /dev/input/eventXY. And that works w/o modifications to projecteur as long as it's a hardware mouse. The same with uinput causes problems, and I think it's because we end up in a loop: MouseDevice gets evens from my external vmouse-receiver on uinput, and VirtualDevice re-issues the same events to uiput -- creating a loop where MouseDevice sees the same input again. That's why I commented out the emitEvent() calls in spotlight.cc, this breaks the loop, but also stops move movement. I found a first solution: I put the qt5 cursor movement back into gsconnect. It works just fine w/ uinput now (and the patch to spotlight.cc). The down-side is that any uinput remappings would not work. I think the proper way would be to replace vmouse-receiver with a receiver thread inside of projecteur that generates events directly (without them coming from any device). The emitEvent() calls would be directly issued from such a socket receiver, which gets it's messages directly from KDE Connect (Android).

[fmuelle4711]

Sorry, not directly from KDE Connect but still from gsconnect (w/o cursor updates in gsconnect).

[jahnf]

Okay I think I understand your issue now. Proposal: Why not create a virtual device in your vmouse receiver? And you can give this new virtual device any vendor product Id you like. For example abcd:ef00 .. then run projecteur with -D abcd:ef00 - should work out of the box since it's just like any other device to Projecteur

[fmuelle4711]

Yes, that works, good idea. Would you be interested in a projecteur plugin to KDE Connect? If so, an integration of my receiver bridge to projecteur might be more appropriate. Your call.

[jahnf]

Generally speaking: yes. Here my first thoughts on it:

• I guess the KDE connect plugin could talk to Projecteur the same way the command line command option sends commands to an existing instance. (via QLocalSocket).
• No KDE dependency to the main Projecteur project.
• The plugin would be kind of a sub project, but could also be independently build.

Do you have a prototype for a KDE plugin already or do you want to write one?

I think I would schedule this feature to v0.9, but I can a feature branch for where experimenting can be done freely.