search

wmutils / core

Set of window manipulation tools
Other
714 stars 33 forks source link

erratic behaviour in wtp / wmv / wrs #53

Closed tudurom closed 7 years ago

tudurom commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

derrickcope commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

z3bra commented 7 years ago

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 commented 7 years ago

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

feroldi commented 7 years ago

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 commented 7 years ago

The binary is libxcb-util.so

z3bra commented 7 years ago

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 commented 7 years ago

Closing as per commit https://github.com/wmutils/core/commit/dd268ecacc773aa6f767f8d3e6653b2a71f25c4e. Well done dcat!