Hello!
I am enjoying the ‘Virtual Display’ feature in KDE Connect to use a laptop as another (remote) monitor for my dekstop. Problem is the cursor does not display on the virtual display. I can drag windows over there but the mouse doesn’t render.
(both machines are wayland + plasma)
I tried the “Show Local Cursor” button, but it does nothing as the local (laptop) mouse always renders. I guess I would want a “Show Remote Cursor” button? If the cursor is supposed to show the remote mouse, then I will should file a bug. If it is not implemented, then a feature request instead.
Also, “Remember this certificate” doesn’t seem to remember between connections. I hit remember but it always asks every session. I don’t see any errors in log. Is it because the user connection hash thingy changes each time I connect? When I hit connect it seems to have a format of rdp: <user>:<hash>@<ip>:<port> where the <hash> is different each session.
Also, does KRDC have a “keep awake” setting while connected? The laptop (virtual monitor) device wants to go to sleep after a while, so I have to hit “Manual Block” in Power and Battery tray icon settings under “Sleep and Screen Locking after Inactivity”.
Just discovered and interesting quirk.
If you shake the mouse it becomes larger so you can find it. That’s not the quirk, that is expected behavior. But the quirk is that in the enlarged mode, it renders on the remote screen “Virtual Display”!
So current work around to see cursor on Virtual Displays is to shake it to make it big then use it while its in big mode. Once it shrinks back to regular size, it disappears completely.
This also confirms to me its a bug, and the cursor should be rendering. Will file an official bug report.
hmm. it also sometimes randomnly disconnects. then trying to reconnect it says:
Remote device does not have a VNC or RDP client (eg: krdc) installed.
Cannot start a request without a resolution.
Now this is false as it is clearly installed, and was just working. But the second line saying it cannot start a request without a resolution.
Do I interpret that as “screen resolution” or “problem resolution”?
Curious why it can no longer find the krdc client after it disconnects… perhaps another bug.
Documenting as I go…
Have you tried using krfb-virtualmonitor command instead of kdeconnect? That should keep the virtual display available after disconnection.
krfb-virtualmonitor --name laptop --resolution 1920x1080 --password your_password --port 3389
The cursor doesn’t show up for me either, and for some reason the connection is very slow (even with the two computers connected to each other via Ethernet) to be useful but I don’t know what the problem is.
any news about this bug? also where is the reported bug to vote it?
I tried that too, KDEConnect uses RDP which is way way faster than doing manually with VNC
I have the same exact problem and can’t find anything online…
Also on the client machine for wathever reason the cursor is stuck on left top corner and i can’t move it, only mouse click buttons
And the other one I reported also:
Another couple things I have noticed.
I had an instance waking from sleep where one of the devices seems to have been spamming Input Capture Requests. Unsure of repro but will keep an eye on it and make another bug report once I have something more concrete.
Additionaly related to Input Capture Request, it would be nice if this prompt included the device name and IP that was making the request. Since I have 3-4 devices linked, it’s not clear which one is requesting input, and in tandum with the above request spam, it would make it easier to isolate the device in question that spamming requests. Maybe will open a feature request for that.
Just made an interesting discovery, relevant to the original mouse render issue.
I have a multi-monitor setup, I am not sure if that matters to the root cause. I have the virual monitor as the last monitor to the very right. Something like this:
[monitor A] [monitor B] [monitor C] [virtual monitor D]
When I mouse off of monitor C to the right to get to the left of monitor D, the mouse does not render but I can click on things so it still works. This is the original bug.
However, when I mouse off of monitor A to the very left, its somehow has wrapped the mouse around to virtual monitor D where it should not, and when this happens the mouse is rendering on the Virtual display D!!! wut? But… nothing clicks. So visually it now works on the virtual display, but no more clicking. The opposide of the original bug.
Additionally when the mouse enters the virtual monitor, a popup on the main machine appears:
“Input Capture Started”
That popup doesn’t show up the other way, so that is interesting. Perhaps the rendering logic has a miscalculation on the offset relative to all monitors?
So to test I decied to put the Virtual Monitor on the very left. So now my configuration is:
[virtual monitor D] [monitor A] [monitor B] [monitor C]
Now when I enter the virtual monitor from monitor A to the left, it does the original bug of clicking but not rendering. But now trying to flip around from the very right going off of monitor C, it does not enter virtual monitor D from the left. Seems to be a one-way quirk.
As a final test I decided to unplug my side monitors A & C, and leave only the center main monitor B physically connected. The behavior remained.
[monitor B] [virtual monitor D]
Mouse entering from right of B to left of D: clicks work, but mouse doesn’t render.
Mouse entering from left of B to right of D: clicks dont work, but mose renders.
So the quirk still exists with single monitor vs multi-monitor setups. (additionally, it shouldn’t even let the user mouse off into very left where the monitor isn’t actually positioned, so perhaps that is another separate bug or related to the original?)
Also tried positioning the virtual monitor above and below the main monitor, and again nothing rendered.
Hopefully this makes sense, if my wording was confusing or I mixed up my lefts and rights. Point is; try the monitors in different configurations, and behvaior may be slightly different.
Maybe this information is useful to isolate / test the issue.
Because the cursor renders when the shake-to-find magnification effect is triggered, KWin appears to draw the enlarged cursor directly into the compositor scene rather than relying on the standard Wayland cursor plane. For those tracking bug 514934, does forcing software cursor mode in KWin or checking whether the RDP stream captures compositor effect layers provide a usable cursor on the virtual display?
