Burrito loses focus when focusing on Gw2

[Nuxmin]

Hey there!

I could make it work like you stated using ArcDPS, however, another issue I've seen. Even if the Burrito is checked as always on top and I have gw on windowed. Every time you focus on gw the Burrito stays in the background.

I find no way to make it stay on top so it's only possible to see the path alternating with Alt Tab.

[AsherGlick]

Can you share what distro and window manager you are using?

[Nuxmin]

Sure!

I'm using Pop OS, it uses GNOME.

I tried KDE too, it doesn't work either, same issue 😭

[AsherGlick]

Is guild wars in fullscreen or windowed-fullscreen?

[Nuxmin]

Is guild wars in fullscreen or windowed-fullscreen?

Windowed.

[AsherGlick]

Unfortunately I cannot reproduce this issue on ubuntu using gnome and I do not have the resources to replicate a popos environment. If you or anyone else happen to figure it out, or are able to debug any more into the issue please add it here so we can work on a fix.

[coderedart]

i have the same issue. Endeavour/KDE latest packages (plasma-desktop version 5.22).

so, if you click on gw2 window, the whole overlay goes into background. but if you set the gw2 window as "keep below others" , overlay will now display over gw2 window.
the issue with this work around is that you can't focus on burrito by clicking on its icon, you have to use alt-tab to actually focus input on burrito and then, you can click on burrito icon to get the main panel of "open marker file" and such.

i just recommend sticking to window mode for now and maybe play gw2 with "borderless" decoration.

[coderedart]

i checked on gnome 40 and xfce 4.16 . the same issue with windowed full screen. with gnome, i couldn't even use windowed mode of gw2.

According to distrowatch,
pop os has gnome 40.2 or 40.3, while arch/endeavour got gnome 40.3 .
OTOH, ubuntu has the following gnome versions with the respective ubuntu releases.
3.38.4 | 3.38.1 | 3.36.1
21.04 | 20.10 | 20.04 lts.

I think gnome 4 might have a bug that affects me and @Nuxmin . will need more people to report their distros/DE versions along with what issues they have with burrito to confirm. @AsherGlick what's your distro/gnome version? maybe you can put it in README as the main target that you develop for?

[coderedart]

#23 (comment)
so, cinnamon works i guess.

EDIT: i installed cinnamon to find out and had a horrible experience. cinnamon won't bring the focused windows up, so i hate to manually alt tab into them. but the good thing is that with cinnamon, the overlay stays above gw2 window, But when using full screen setting from godot, it didn't let me click through. that is one DE i am never installing again.

[AsherGlick]

@coderedart I am using 20.04 LTS. I think you probably right about gnome 4 having some sort of bug, or weird interaction.

[coderedart]

@coderedart I am using 20.04 LTS. I think you probably right about gnome 4 having some sort of bug, or weird interaction.

Think we should have a sort of table in readme with working combination or one primary target distro and wm. Cannot be bothered to support all variations of distros and wms. Maybe Ubuntu lts with gnome for starters

[coderedart]

I just installed ubuntu 20.04 lts, and the overlay was not working for me in gnome (3.38 version i think. i upgraded all packages to latest). i was researching this stuff for Jokolay, and i posted an issue on that repo, coderedart/jokolay#1 .

TLDR;
Windowed fullscreen or fullscreen won't work reliably. unless we can use "Transient_For" hint, which needs us to dabble in x11..
Godot has a function to get the raw x11 window handle if we choose to use raw X11 commands via OS.execute(). we can also try other commands like https://docs.godotengine.org/en/stable/classes/class_os.html#class-os-method-move-window-to-foreground and call them every frame to put it above gw2 (don't know if it will work but worth a try).
for now, i would just recommend telling people to use Window Mode and move burrito. and concentrate on getting gw2 window size via burrito_link.

[royalmustard]

we can also try other commands like https://docs.godotengine.org/en/stable/classes/class_os.html#class-os-method-move-window-to-foreground and call them every frame to put it above gw2 (don't know if it will work but worth a try).

Tried that, it did not work

[royalmustard]

I have made some progress: Using the XWindow handle (though I am currently acquiring them through the window names, which we would have to do anyways for getting the GW2 handle) and setting the override_redirect and WM_TRANSIENT_FOR properties I am able to get the window to stay above gw2, even in (windowed) fullscreen. This, however, leads to some other problems:

1. Burrito no longer gets mouse inputs
2. GW2 no longer gets keyboard inputs

[royalmustard]

I have tried a few other things:

1. The composite protocol extension for X11 adds an "overlay window" which is only superseded by the screen saver. However setting it as a parent causes Burrito to appear on the wrong (Physical) screen for me.
2. Setting GW2 as the parent window of burrito allows GW2 to receive both mouse and keyboard inputs as well as Burrito to stay on top of GW2, however Burrito now no longer receives any input.

It should also be noted that reparenting seems to disable compositing for me, as in both cases Burrito loses its transparency.
In both cases, Burrito also no longer gets any input (mouse or keyboard).
Setting the _NET_WM_BYPASS_COMPOSITOR property to always composite did not help that.

[coderedart]

Great job. What wm/os? I think override flag is not good. Because the window needs to be controlled by wm and be provided events.

[royalmustard]

Great job. What wm/os?

Manjaro with kwin/picom.

I think override flag is not good. Because the window needs to be controlled by wm and be provided events.

As far as I understand the documentation, TRANSIENT_FOR is supposed to be used in combination with override_redirect.
Also, using only TRANSIENT_FOR results in the same behavior, where burrito seems to receive all keyboard inputs and gw2 all mouse inputs

[coderedart]

As far as I understand the documentation, TRANSIENT_FOR is supposed to be used in combination with override_redirect.

This specification extends the use of the property to override-redirect windows.
that version of the spec allows override windows to use the transient_for property. the previous spec didn't require that windowmanagers make transient_for property available to override_redirected windows.
or that's how it looked to me.
https://tronche.com/gui/x/icccm/sec-4.html#WM_TRANSIENT_FOR

It is important not to confuse WM_TRANSIENT_FOR with override-redirect. WM_TRANSIENT_FOR should be used in those cases
where the pointer is not grabbed while the window is mapped (in other words, if other windows are allowed to be active while
the transient is up). If other windows must be prevented from processing input (for example, when implementing pop-up
menus), use override-redirect and grab the pointer while the window is mapped.

I am pretty new to this stuff too, but what i learnt after going through a bunch of articles is that. a window manager is just another x11 client, similar to any other window. but a window manager registers a substructure redirect mask, for all the windows. which means when any window wants to display itself or circulate itself aka alt+tab or change its size/pos/border/stacking order , that request will instead go to the window manager which will be the boss and decide what should actually happen. by using oerrideredirect, we essentially say that we will ourselves handle the resizing/positioning/focus/unfocus etc..

TRANSIENT_FOR otoh, just lets you be associated with a window. but still lets the window manager decide who gets the focus or other stuff.

its a little confusing why burrito would receive keyboard, but gw2 would receive mouse inputs. there should only be one window in focus. and that should receive all of it.

anyway, lets start with kde for now. if you have the time, can you try coderedart/jokolay#1 (comment) suggestion? that was recommended in kde forums. ik that it will be great if we can find a single solution for all DEs, but i don't think that's happening anytime soon. no matter what we do, there's already stuff happening in godot itself which is beyond our control, we might be putting override redirect and godot could be trying to interact with wm, too much debugging. we have a much better chance at just creating a borderless window for gw2 and pretend that gw2 windowed mode is now windowed fullscreen. much easier for burrito to stay on top then without having to worry about transient_for or override_redirect. and we can start with kde first as both of us are on kde/arch based distros.

[royalmustard]

I am not quite sure whether this works correctly, but according to the KDE docs in the issue you linked, 17 should be for ciritical notification. It seems to do nothing, xprop reports _NET_WM_WINDOW_TYPE(ATOM) = DRAWABLE
The code used to set the property:
long wt = 17; XChangeProperty(display, burrito, XInternAtom(display, "_NET_WM_WINDOW_TYPE", false), XA_ATOM, 32, PropModeReplace, (unsigned char *)&wt, 1);

[royalmustard]

I found out why Burrito was eating the input when setting WM_TRANSIENT_FOR: It was because I used my own build which was still calling OS.move_window_to_foreground() in godot every frame. So mouse passthrough worked but because burrito was always above gw2, it got the keyboard. WM_TRANSIENT_FOR almost works, however burrito still receives no mouse inputs.

Edit: You have to tab to Burrito to interact with it, but when playing the game the overlay stays where it is supposed to in fullscreen. I will try to make a pr later, with a small gdnative library (probably in rust) which will take burritos window id, find out the window id of gw2 and set the WM_TRANSIENT_FOR hint.

[AsherGlick]

This is great! I look forward to seeing the pr. Does the mouse capture region work properly when you are tabbed into burrito or do you have to tab back into Guildwars when you are done?

[royalmustard]

I guess we can close this now?

[AsherGlick]

We can close this issue. If users are still experiencing similar problems we should open a new one referencing this one.

[coderedart]

I get the following error

Godot Engine v3.3.3.stable.official.b973f997f - https://godotengine.org
WARNING: initialize: Error setting locale modifiers
   At: platform/x11/os_x11.cpp:153.
WARNING: initialize: XOpenIM failed
   At: platform/x11/os_x11.cpp:200.
WARNING: initialize: XCreateIC couldn't create xic
   At: platform/x11/os_x11.cpp:510.
OpenGL ES 3.0 Renderer: NVIDIA GeForce GTX 1070 Ti/PCIe/SSE2
OpenGL ES Batching: ON
 
pre
post init
Setting transient for
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: FailedToConnect', src/lib.rs:34:61
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
ERROR: <native>: gdnative-core: method panicked (check stderr for output)
   At: src/lib.rs:32.

and then burrito goes on to run normally. latest kde/arch.
any requirements on how i should be starting gw2 or something? its a freshly installed gw2 from lutris with the lutris-gw2-6.14 runtime.

[AsherGlick]

This seems to be panicking as a result of failing to connect to the default x11 server

Burrito/burrito-fg/src/lib.rs

Line 34 in fb2ef57

let mut dpy = DisplayConnection::create(None, None).unwrap();

https://docs.rs/breadx/1.2.1/breadx/display/type.DisplayConnection.html says it can return errors from from_connection

https://docs.rs/breadx/1.2.1/breadx/display/struct.BasicDisplay.html#method.from_connection says this error is due to the x server rejecting the connection.

@royalmustard any ideas?

@coderedart when you say goes on to run normally, do you mean that it is still effected by this issue where burrito goes behind the gw2 window when gw2 is focused?

[coderedart]

aye. it goes behind in windowed fullscreen, and when i bring it forward with alt-tab, its just a black screen.
in windowed mode, its fine. but maybe its just my system, someone with not arch/kde can also try it. I will go see if it works on mx/xfce

[coderedart]

godot on mxlinux can't build burrito for some reason (wasted like 3 hours on it -_- godot in debian repo is too old and can't even open the project. otoh, the latest binary can open it, but can't build it. if i use the burrito binary build on arch, i get a segfault and it can't even load the library ). so, i just tried arch/gnome and i get the same crash of xconnection failure, but this time, i can't even see the burrito icon. i will just see what @royalmustard tested this on and try that. i tried on kde again, and it works properly in window mode even if it can't connect to x server

[royalmustard]

i bring it forward with alt-tab, its just a black screen.

This seems to be an issue with the compositor not working. I had the same issue with Manjaro/kde and the kwin compositor. Try turning off compositing in kwin and install picom (or another compositor), that is what worked for me.

As for the crash, are you running pure X or Xwayland? I tested it on pure X on aforementioned setup (Manjaro, kwin, picom).
Godot also seems to have some problems with X (as indicated in your output) which do not appear when I run it.

[coderedart]

@royalmustard pure X. Just normal kde installation.i have nvidia card, so Wayland is a not an option. Maybe we should get someone else to check it. Maybe your system has a library installed that I don't?

[royalmustard]

which drivers are you running?

[coderedart]

@royalmustard nvidia proprietary latest.

Edit1:
In ubuntu gnome 21.04, it works and sets transient for xid. But I can't see burrito icon. I see the burrito window in taskbar, but I can't find the icon on screen and theres no point without that.
Edit2:
Ubuntu 21.04 kde works properly in window mode. But in windowed full screen, burrito stays on top, as a black area, cannot click burrito without alt tabbing.
I will see if this is because sometimes window managers disable compositing when a game is being played to improve performance. There should be an option somewhere
Edit3:
as expected, kde is disabling compositing/animations when our game goes into windowed fullscreen, that's why burrito is a black box. the shortcut for toggling compositing is alt + shift + F12, so after pressing burrito can display over windowed fullscreen gw2 transparently without blackbox. the best way is to go to lutris -> right click gw2 -> configure -> system options -> turn off disable desktop effects. you can stop all apps from blocking compositing by going to settings -> display/monitor -> compositor -> untick the "allow apps to block compositing". or you can create a window specific rule for gw2 with block compositing -> force -> false. now i only need to understand why it fails to get a x11 connection on my arch.

[royalmustard]

The alt tabbing is the only way we can get it to work on windowed fullscreen. Its a feature, not a bug

[royalmustard]

Since it seems to work on Ubuntu and not on Arch, maybe compare your Xorg installations (version, Xorg.conf, addons, etc.). Maybe share your arch findings so others can try to reproduce the bug.

[coderedart]

i can't even get breadx example to run. it fails to connect for some reason.

[royalmustard]

Try if you can get some xcb or xlib stuff to run, so we can see if it is a problem with breadx.

[coderedart]

everything else runs. it was fine when i was using x11rb to try the _NET_WINDOW_TYPE flags thingy. it seems breadx cant use xauth yet? bread-graphics/breadx#8

[royalmustard]

I don't quite understand the byte parsing code going on in the breadx authorisation functions, but failing to authorize should give a different error than failing to connect (see bread-graphics/breadx/pull/10). According to the X protocol, on refusing the connection (which is something different than not being authorized), X should send a reason in the connection response. (However I don't quite understand enough of it to add functionality to read it). Maybe there is something in Xorg.log, but I am not sure.

On another note, I got someone to test it on arch with i3 and picom, where it seemed to run fine.

[AsherGlick]

This is really great progress. I think this has been scoped down enough to be its own issue at this point so it can be better tracked. @coderedart or @royalmustard can you transition this into a new issue with any system details or breadx code snippets that are necessary?