/usr/bin/prlcc causes dead/unclickable areas on screen edge after snapping window

[IoannisK3]

As the title says, I was confused for a very long time because in Linux (X server only-not wayland) whenever I snapped a window on the screen edge inside the vm, it caused this area to become unclickable. E.g. even if I moved the window, I was not able to click anything on that area!. xprop showed this when inspecting the unclickable area which doesn't seem normal:

└─$ xprop
XdndAware(ATOM) = undefined atom # 0xa240e6ff
XdndTypeList(ATOM) = text/uri-list, TARGETS, MULTIPLE
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0

After digging around a little bit, I remove the /etc/xdg/autostart/prlcc.desktop file. This prevents /usr/bin/prlcc from auto-start. Issue got resolved, although now I cannot copy & paste between the VM and MacOS. If I want to copy paste something I have to manually start prlcc and then force kill it again.

I am leaving this here for anyone else who might be having the same issue. Parallels team, PLEASE FIX THIS!

 

[Injod]

Killall is a little overkill and there is a much simpler solution without killing processes.

But first I want to confirm that the issue is present on both Wayland and X11. Its also independent of Desktop Environment (KDE, XFCE, etc).

To troubleshoot and confirm it really is what we say it is and get the window ID:

xwininfo -root -tree 2>/dev/null | grep 'prlcc\|prl\|10x10'

This will show something like:

0x3a00001 "prlcc": ("prlcc" "Prlcc")  10x10+10+10  +10+10

It will likely show several other things, including the grep process itself and it might show a false positive hit with '10x10'. Ensure you look at the correct 'prlcc' line.

Also your hex code might differ. It shows there is a 'prlcc' window with a size of 10x10, but the invisible overlay is often bigger.

xwininfo -id 0x3a00001 -tree

Will show the process' child windows. Remember to use your own hex code. We don't actually use this info it just shows some extra info on child windows.

To show the actual processes of the window

xdotool getwindowpid 0x3a00001 && ps aux | grep prlcc

The remove the window. Again, use your own hex code.

xdotool windowkill 0x3a00001

I think a better work around is to actually move the window out of the desktop area.

xdotool windowmove 0x3a00001 -1000 -1000

Again, use your own hex code. The -1000 -1000 are X and Y coordinates. If you run dual screen setup depending on which monitor is primary, these coordinates might actually just move it to the other screen and still block a part of your desktop. If that happens, just increase to -10000 -10000. I'm not sure but I don't think there is a downside to using large numbers. I wouldnt go overboard though into millions. Just ensure its just out of usable desktop space. To be clear, its simply the combined resolution of your monitors. Two 1920 wide monitors will amount to 3840, so to place it offscreen double that or add another 1920 to it. Imagine you have 3 screens .

Last but not least, I wholeheartedly agree this is very annoying and should be fixed. I don't think its very hard, just ensure its positioned off-screen.

Thanks.

 

[Injod]

No edit on my own posts? That's lame.

I missed the post about 'prldnd' being the actual cause, I'll investigate some more next time the issue occurs to confirm and see if moving that off-screen (if possible) works too.

 

[EnricoD6]

As a customer with a paid license: I'm begging you, Parallels guys, to please fix this before hitting me with other upselling emails (and before I'll move back to Virtualbox out of frustration...)

It has happened: I've forced myself to try out Parallels for a whole year worth of headaches, suggested by my colleagues which are Apple (and somehow this also means Parallels(!)) fan boys and eventually - on Parallels subscription renewal - I have moved back to VirtualBox out of frustration. In July 2026 VBox is anyway quicker, more reliable and free, so it's a no-brainer.

Having Xubuntu - which is xfce4 - as a Parallels guest os: the most annoying problem for me was still the one described in this topic: dead/unclickable areas on screen edge after snapping window. After a year, solution for me was still launching the `killall prldnd` command as a first thing on machine fully booted; hope this will help someone else before migrating to VBox or alternatives.

Note: migration to VBox is dead simple - grab the big Parallels .hds file inside the .pvm or .hdd file using right click -> 'Show Package Content'. Copy/paste the big .hds file somewhere else and rename it to .hdd. Done, you can already use it as a virtual hard-drive in Virtualbox, just remember to uninstall the Parallels tools and installing the virtualbox-guest-addition tools as first thing after boot.

Note2: I'm also used to convert the .hdd into a .vdi format to be able to leverage the VBox `--compact` command. In this occasion for example - because the equivalent functionality in Parallels (they call it something along the line 'claim free space') does not really work - with VBox vid --compact I've just saved 150GB like that, which Mac users will surely appreciate.

Good luck Parallels devs, hope this will teach you to (better) listen to your customers.