x11vnc hangs while moving/sizing windows on IceWM

[elluisian]

Describe the bug If I decide to stop the x11vnc server while I'm dragging/resizing a window through keyboard shortcuts, I'm not able to restart said server. When I try to restart it, it just hangs at:

18/11/2024 22:47:49 passing arg to libvncserver: -listen
18/11/2024 22:47:49 passing arg to libvncserver: localhost
18/11/2024 22:47:49 -usepw: found *OMITTED*
18/11/2024 22:47:49 x11vnc version: 0.9.16 lastmod: 2019-01-05  pid: 289967

I'm using IceWM 3.6.0 (the actual version doesn't matter) on Debian Trixie (testing), its shortcut to move/resize windows are ALT+F7 and ALT+F8. Please note that I'm not sure this is related to x11vnc itself, as I was able to reproduce this issue with other programs as well (xdotool, icesh). Unfortunately I'm not familiar with X11's architecture, so I'm not able to say what's causing it.

While when being phisically in the vicinity of the server, it is simply a matter of "canceling the move/resizing" by pressing ESC/Enter, this becomes extremely problematic when connecting from the outside, since there's no way to "cancel" (even xdotool hangs).

To Reproduce As far as I noted, there's an easy way to test this on the server itself, there's no need for an external connection:

1. Login with IceWM as Desktop Environment/Window Manager;
2. Switch to a TTY, perform the login;
3. Start x11vnc from the TTY (foreground mode);
4. Go back to the desktop, open a window and focus on it;
5. Press Alt+F7/Alt+F8 to start moving / sizing it;
6. Go back to the TTY and stop x11vnc with CTRL-C;
7. Re-run it again and observe it hanging;

Expected Behavior When I decide to re-run x11vnc, it should not hang, it should run as normal and I should be able to go back to the VNC session, in order to cancel the window moving/sizing.

Screenshots N/A

Desktop

• OS and version: GNU/Linux Debian Trixie (testing)
• Xorg version used: 21.1.14
• Wayland version used: N/A

Additional context As already said, I'm not totally sure this is a bug with x11vnc, unfortunately, since other tools seem to hang to the same situation. I'd like some help in order to correctly diagnose the problem and solve it, since it is very annoying.

[elluisian]

As another try, I tried to use "strace", here's where it hangs:

...omitted...
newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644, st_size=2641, ...}, 0) = 0
write(2, "19/11/2024 12:32:35 ", 2019/11/2024 12:32:35 )    = 20
write(2, "x11vnc version: 0.9.16 lastmod: "..., 56x11vnc version: 0.9.16 lastmod: 2019-01-05  pid: 268032
) = 56
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, 20) = 0
getpeername(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, [124 => 20]) = 0
uname({sysname="Linux", nodename="omitted", ...}) = 0
access("/var/run/lightdm/root/:0", R_OK) = -1 EACCES (Access denied)
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="l\0\v\0\0\0\0\0\0\0\0\0", iov_len=12}, {iov_base="", iov_len=0}], 2) = 12
recvfrom(3, 0x556cd5195ec0, 8, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}], 1, -1)

The same happens with tools such as "xdotool". I guess somehow, the Alt-F7/F8 blocks something? What's that?

[elluisian]

The only workaround I found, for now, is to use the 'forever' option and keep the program in background, so that it doesn't stop accidentally.

To start the server (other parameters may be used):

sudo x11vnc -forever &

To stop it:

sudo x11vnc -R stop

If it doesn't work, just kill it:

sudo killall x11vnc # 'sudo killall -9 x11vnc' if the previous is not working

Of course, before stopping the server, BE SURE To stop moving/sizing windows.

Still, I'd be glad for some contribution in finding out what the problem might be and how to solve it properly.

[elluisian]

Better yet, to start the server, a combination of nohup and disown may be used, so that if ssh accidentally goes down, everything is fine:

sudo nohup x11vnc -forever & disown

[elluisian]

Unfortunately even with this setup, the bug might happen while grabbing/sizing windows by using a pointer device... so, even WITHOUT using ALT-F7/F8... What's worse, I'm not able to replicate it reliably, sometimes it happens, but sometimes not.

While this is another bad news, I've finally figured out a way to actually "unlock" this situation while being on a remote computer, WITH NO ACCESS to the physical one.

What you need is 'ydotool' (you read correctly 'ydotool', not 'xdotool'). As I've said in the previous comments to this issue, xdotool hangs, since it tries to talk to X11, but fails for some reason, but not 'ydotool', since this works by using the uinput Linux kernel module to interact (so, X11 is bypassed). This means that it works whatever the environment is, be it X11, Wayland or the TTY.

There's a github repository for ydotool (https://github.com/ReimuNotMoe/ydotool), so yeah, you can use that to inject an ESC o ENTER key, this way, the window movement gets stopped.

Still, it would be nice if the bug were to be solved without the need to use this kind of workaround, since this can get very annoying. I've not tried to determine if the problem can be avoided if using the keyboard only (this might be possible with the use of keynav, found at https://github.com/jordansissel/keynav).