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

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:

Code:

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

This will show something like:

Code:

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.

Code:

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

Code:

xdotool getwindowpid 0x3a00001 && ps aux | grep prlcc

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

Code:

xdotool windowkill 0x3a00001

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

Code:

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.

 

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.

 

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.