erratic behaviour in wtp / wmv / wrs

[tudurom]

These three programs are doing their work at random rates. Sometimes I have to execute wmv from 3 to 6 times to move a window.

I observed this issue yesterday, 14th of January. I did some investigation and I found that I upgraded xorg-server on 13th of January, although the three programs were behaving normally two days ago.

Recording of wmv: http://pub.iotek.org/p/2W8nWui (open as mp4 file)

In the recording wmv is not moving the window at all.

Props to @laserswald for notifying me about this bug.

[tudurom]

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.

[laserswald]

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.

[dcat]

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

[derrickcope]

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.

[dcat]

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.

[z3bra]

dead cat wrote:

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

Libinput has nothing to do with wmutils' problem. It might cause issues with sxhkd/xbindkeys, but it shouldn't affect the tools themselves. I've been testing on an arch VM, and it seems - in the case of wmv - that it cannot retrieve the geometry correctly, thus returning from the "move" function too early (error code: "9"; thanks libxcb...). I suppose it's the same thing with wrs. wtp does not have any issue for me, and works all the time. I tested wtf as well, but it seems like it behaves correctly. I'm still not sure what's wrong with it.

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

I didn't see anything either, but the API might have changed slightly, causing libxcb to fail at some point (due to the "asynchronous" state of it). I wonder how other tools using libxcb behave now (sxhkd seems to have a problem as well for example)

[tudurom]

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.

[feroldi]

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

[z3bra]

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!

[dcat]

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

[feroldi]

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.

[tudurom]

The binary is libxcb-util.so

[z3bra]

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.

[z3bra]

Closing as per commit dd268ec. Well done dcat!