Burrito_FG fails to connect to X on some configurations

[royalmustard]

as discussed in #25 the current implementation of burrito-fg fails to connect to the x server sometimes. This seems to be an issue with breadx.

[royalmustard]

Breadx has merged my pr and added handling for error responses from the x server concerning connections. I will do a pr which will change the breadx dependency to the official repo, then we/you can do some further testing @coderedart

[coderedart]

https://github.com/bread-graphics/breadx/issues/8 it seems for some reason my .Xauthority file was the issue. once i removed it and rebooted, there's no crash now. I will try swapping DE and rebooting to see if there's a reason why it didn't work before.

[coderedart]

now it fails to find the gw2 window :( i checked that the wm_name is guild wars 2 with xprop/wmctrl/xwininfo commands and they all properly list gw2 window.

[royalmustard]

Was the WM_NAME "guild wars 2" (lowercase) or "Guild Wars 2"?

[coderedart]

Guild Wars 2 xprop output

_NET_WM_NAME(UTF8_STRING) = "Guild Wars 2"
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True
                Initial state is Normal State.
                bitmap id # to use for icon: 0x44003cc
                bitmap id # of mask for icon: 0x44003ce
                window id # of group leader: 0x4800009
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7a, 0x0, 0x0
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified location: 0, 29
                window gravity: Static
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x440001a
XdndAware(ATOM) = BITMAP
_NET_WM_PID(CARDINAL) = 2128
WM_LOCALE_NAME(STRING) = "en_IN"
WM_CLIENT_MACHINE(STRING) = "redarch"
WM_CLASS(STRING) = "gw2-64.exe", "gw2-64.exe"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, _NET_WM_PING

[royalmustard]

The only reason I can see why it would not work is if GW2 is on a different display (X11 internal, not physical screen) than the default one.

[coderedart]

I found a really cool and easy way to get x11 window id of gw2 for my overlay which might be useful here too. but that functionality would need to be implemented in burrito_link if anyone's interested in refreshing their C skills. https://github.com/coderedart/jokolay/issues/1#issuecomment-919905013

TLDR; after mumble link is initialized, the burrito_link will need to get the window handle of the gw2 window by using the pid in mumble context. then, use that window handle to use the method GetProp(handle, "__wine_x11_whole_window") and we have the xid.

[AsherGlick]

Brilliant! I think I have something working.

This is a great find @coderedart . I gotta say you and @royalmustard have really done a great job here.

I am going to add it to the data sent in the low priority packets to burrito. I am super strapped for time right now to do more, so hopefully from there one of you can pipe it to the right place. I have barely even been able to play festival of the four winds!

[AsherGlick]

Alright! It works. The variable is just sitting as a local variable https://github.com/AsherGlick/Burrito/blob/0b4e38adca74fb5432174c097eefa351fe9e4af5/Spatial.gd#L227 But feel free to elevate it to global so it can be used elsewhere if needed.

[royalmustard]

I will make changes to burrito-fg so that it just sets the property with the Ids supplied by burrito instead of parsing the entire window tree. The only problem I see is that we can only do this after the connection with the link has been established (so at a point where we run in a loop). Maybe we can just have fg return whether is succeeded and act based on that, though I would prefer a nicer solution.

[AsherGlick]

The link will eventually be run automatically so I can imagine burrito entering a "starting up" phase between being launched and when it connects with burrito link the first time. The entire utility of the program relies on the connection with the link existing so getting a graceful failure from burrito-fg while we are not connected seems like an acceptable long term solution. Another option would be to just not call burrito-fg until we have had our first communication with burrito link. Either way it will be the same user experience.

[coderedart]

I was working on the "attach to gw2 window" part of jokolay when i discovered this xid thing. after that, i was also wondering what to do without mumble link, then i remember there's no point in even showing the overlay until we have gw2 logged in. I did not implement it yet***, but I just planned to initialize mumblelink handler part of overlay first, check if mumble link is active with uitick > 0, then get window id to attach and start, otherwise, sleep for a second and loop again. doing it this way, we won't have to start parsing the marker files or initialize textures/opengl unneccesarily.

*** one thing to note is what happens if gw2 crashes, and when gw2 starts again, it will have a new window/pid.

This issue will also affect the order of starting gw2 logging in to a map, and then starting overlay. or starting overlay and then logging into gw2, because we need to consider for how long burrito will try to check for mumblelink before finally exiting. (maybe after a minute or 5 minutes).

I'm also looking at a lutris feature called pre-launch/post-launch scripts, which can be used to autostart link with the game (maybe even the overlay itself). starting a script, and then overlay everytime you start the game is really not user friendly. If someone else wants to look into it, that would be cool too. this will also be useful for armored package https://en-forum.guildwars2.com/topic/22771-playing-guild-wars-2-on-linux-performance-optimizations-and-more/?do=findComment&comment=1434103

[AsherGlick]

@coderedart Can you add that last bit of info to #7 as well. I imagine this issue will be closed soon once the changes to have burrito-fg use the new data from burrito link an I think that topic is worth continuing.

[royalmustard]

I have it working now, though because I was tired and made some mistakes the current version of my repo might contain some files which would make a PR ugly (idk how to fix, help). Short version: the rust lib now returns true or false depending on whether setting transient_for succeeded. The godot script stores that in a global variable and checks it in decode_context_packet. It then calls the fuction if it has not been set. This leads to some weird behavior (mainly the property not being set until the next context packet arrives, which appareantly does not happen in character select).