erratic behaviour in wtp / wmv / wrs about core HOT 14 CLOSED

I just realized that I used the wrong command in the recording.

Nevertheless, running wmv -a 0 0 $(pfw) moves the window after 3 tries.

from core.

It's not just those three programs. I've seen erratic behavior with wtf as well. Since those four are pretty much the linchpin of my workflow, and the difficulty of diagnosing problems with wmutils itself, I haven't been able to drill down enough to get a more detailed list of malfunctioning programs.

from core.

okay then, which X version and OS are you guys running?

from core.

I am having the same issues on arch. Arch just upgraded xorg-server to 1.19-1 I think. Libinput also became the new default driver so that could be the problem also.

from core.

I don't run bleeding edge shit, can you confirm whether or not libinput is the problem?

I don't see anything that should be a problem in the 1.19.1 release notes.

from core.

from core.

I tried downgrading xorg-server and xorg-server-common to version 1.19.0 (way older than the most recent version) and the problem is still here. Their dependencies were last updated in september. Seems like it's not a server problem.

from core.

It seems (at least for me) that the problem goes away when you don't disconnect right after flushing.

from core.

The issue seems to lie within the XCB library. Due to the asynchronous
state of it, connection sometimes gets closed before a request could
be handled by the server.

I tried rewriting mapw/wtf using xlib, and both of them work as expected
(xlib makes synchronous calls to the server)

I'm not sure what changed in xorg 1.19, but the issue is only present
after this release. I suppose WM compiled against XCB keep working
because they keep the connection openned for a long enough time to see
their requests executed. Most of the time, adding a sleep(0.3); before
killing the connection makes the tool reliable enough (it's not a
solution though).

I'll keep investigating. If anyone has an idea, please speak up!

from core.

Can anyone confirm if problem persists after replacing xcb_flush(conn) calls with xcb_aux_sync(conn)?

from core.

Yes, it works for me. I didn't find the binary to link with, so doing

free(xcb_get_input_focus_reply(c, xcb_get_input_focus(c), NULL));

(which is basically the same behavior) worked for me.

from core.

The binary is libxcb-util.so

from core.

Good catch d!

As a reference, here is the definition from the libxcb page:

int xcb_aux_sync (xcb_connection_t *c);

This functions also flushes all pending requests to the X server,
and then waits until the X server finishing processing these requests.

This way, we won't close the connection "too early" as we currently do.
I guess that X.org 1.19 discards requests that are still pending for
a connection when that connection is closed.

from core.

Closing as per commit dd268ec. Well done dcat!

from core.