Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MangoHud still relies on X11 even when built with_x11=disabled and with_wayland=enabled #1497

Open
nokia8801 opened this issue Dec 5, 2024 · 15 comments

Comments

@nokia8801
Copy link

nokia8801 commented Dec 5, 2024

Describe the bug
When built with with_x11=disabled and with_wayland=enabled, the HUD position is wrong and doesn't follow the config value, RShift_F11 doesn't change the position as none of the shortcuts work, display-server config option also doesn't work.

List relevant hardware/software information

  • OS: Arch Linux
  • MangoHud: 0.7.2
  • GPU: Intel Arc A750
  • Mesa: 24.2.7
  • Wine: wine-tkg-git 9.22.r2.g342b3b81-327 ( TkG Staging NTsync )
  • DE/WM: GNOME 47.2 on Wayland (Mutter)
  • DXVK: 2.5.1
  • Kernel: Linux 6.12.1-arch1-1

To Reproduce
When running a game natively over Wayland, such as Windows games using Wine with the graphics backend set to Wayland (without x11 fallback) or Minecraft with GLFW 3.4 running natively over Wayland, if we build MangoHud with with_x11=disabled and with_wayland=enabled, the HUD position will be wrong, shortcuts won't work and display-server will return empty.

Expected behavior
Shortcuts, display-server and position should work.

Screenshots
image

Additional context
I made this issue back in April, which could be related. #1281

I build Wine with the Wayland driver and set it as the only graphics backend. Wine is also built with and using WoW64. I also use GLFW 3.4 with Minecraft. Both Wine games and Minecraft run natively over Wayland. When the games are running without MangoHud, no xwayland or mutter-x11-frames are spawned/running/sleeping. I guess something got fixed since April and now, because now, even with MangoHud, those processes aren't spawned/running/sleeping at all. So that's exactly what I wanted. Thanks. It can be used without any X11 dependencies or calls. (Hopefully I'm correct in that last part)

But the HUD is stuck and not configurable. That's the issue.

I should also mention that I don't use mangoapp or mangohudctl, so those may affect the building process or using it as Wayland only. Here's my PKGBUILD options:

build() {
    arch-meson "$_pkgname" build \
        -Dmangoapp=false \
        -Dmangohudctl=false \
        -Dwith_nvml=disabled \
        -Dwith_xnvctrl=disabled \
        -Dwith_x11=disabled \
        -Dwith_wayland=enabled \
        -Dwith_dbus=enabled \
        --wrap-mode=default

    meson compile -C build

}

Edit: Actually, none of the shortcuts work.

Edit 2: Ok so I've done some more testing.

Interestingly enough, the position option is honored in Minecraft and Orwell, both OpenGL Linux native games, but again the shortcuts don't work.

In Wine, when using Proton UMU and Fsync, the option is honored but shortcuts don't work.

In Wine, when using Wine TkG Staging with NTSync, the option is honored wrong and shortcuts don't work. But the interesting part is that:

  • top-left is top-center
  • top-center is top-right
  • top-right is middle-left
  • middle-left is middle-right
  • middle-center is top-center
  • middle-right is bottom-left
  • bottom-left is bottom-center
  • bottom-center is bottom-right
  • bottom-right is top-left

Very weird.

Edit 3: Nevermind what I said about MangoHud working without any X11 calls or dependencies. Minecraft, Orwell and other games launched through Proton UMU spawn xwayland and mutter-x11-frames processes and they are running. Only games launched through Wine TkG Staging with NTSync+WoW64+Wayland don't have them. Even though Proton UMU is also using Wayland in my case. Interesting.

I would very much like MangoHud to work without any X11 calls and dependencies, if it is possible of course.

Edit 4: So I've discussed this below but will add it here as well. The position and display-server values work with my custom system Wine. With some new commits, shortcuts also work. No xwayland and mutter-x11-frames processes are triggered too.

But these do not work with Proton and Minecraft. The processes are also triggered. So there still must be some x11 stuff deep in the code?

@nokia8801 nokia8801 changed the title When built without X11 and using Wayland only, HUD is stuck in top center of screen When built without X11 and using Wayland only, HUD position is wrong, shortcuts don't work Dec 8, 2024
@Etaash-mathamsetty
Copy link
Contributor

position setting works fine for me

@nokia8801
Copy link
Author

nokia8801 commented Dec 8, 2024

It does not for me.

But I just compiled with your pull request and shortcuts work now. position value in the config file is also honored with the pull request, without it, it's wrong. But this is only with system Wine from TkG with Wayland+WoW64+Staging+NTsync. Wine 10.0rc1.r0.g4f96088b to be exact. It does not trigger xwayland and mutter-x11-frames either. So that's great.

In other Wine/Proton versions, shortcuts still don't work, but the position value works, and xwayland and mutter-x11-frames is still triggered and running.

Interestingly, Minecraft (with GLFW 3.4, so Wayland native) does not show anything with display-server config option and shortcuts still don't work. It also still triggers xwayland and mutter-x11-frames. The position value worked before the pull request and still works.

@Etaash-mathamsetty
Copy link
Contributor

It does not for me.

But I just compiled with your pull request and shortcuts work now. position value in the config file is also honored with the pull request, without it, it's wrong. But this is only with system Wine from TkG with Wayland+WoW64+Staging+NTsync. Wine 10.0rc1.r0.g4f96088b to be exact. It does not trigger xwayland and mutter-x11-frames either. So that's great.

In other Wine/Proton versions, shortcuts still don't work, but the position value works, and xwayland and mutter-x11-frames is still triggered and running.

Interestingly, Minecraft (with GLFW 3.4, so Wayland native) does not show anything with display-server config option and shortcuts still don't work. It also still triggers xwayland and mutter-x11-frames. The position value worked before the pull request and still works.

The second issue is probably because x11 is still being used by wine and since your mangohud has no libx11 the shortcuts don't work.

@nokia8801
Copy link
Author

But I set up the other Wine/Proton versions to also use Wayland with winetricks/protontricks and I can confirm that they do not trigger xwayland or mutter-x11-frames when I launch them without MangoHud. When I do launch them with MangoHud, even with this pull request and with_x11=disabled and with_wayland=enabled, the shortcuts don't work and they trigger those processes.

There is also Minecraft to consider, which should be free of any Wine/Proton issues. Again, without MangoHud no process visible. With it they are, and shortcuts don't work.

@Etaash-mathamsetty
Copy link
Contributor

I pushed another commit could you give that a try

@nokia8801 nokia8801 changed the title When built without X11 and using Wayland only, HUD position is wrong, shortcuts don't work When built without X11 and using Wayland only, HUD position is wrong, shortcuts don't work, xwayland is still used Dec 8, 2024
@nokia8801
Copy link
Author

nokia8801 commented Dec 8, 2024

Just tried. Unfortunately still the same issue in Proton and Minecraft. display-server doesn't work. Shortcuts don't work. Processes are still triggered.

Only my custom system Wine works in this configuration.

Does this #1496 perhaps have any relation?

@Etaash-mathamsetty
Copy link
Contributor

Etaash-mathamsetty commented Dec 8, 2024

Just tried. Unfortunately still the same issue in Proton and Minecraft. display-server doesn't work. Shortcuts don't work. Processes are still triggered.

Only my custom system Wine works in this configuration.

Does this #1496 perhaps have any relation?

you need to clean build, and use the latest commit (I fixed a build error)
the HUD should display nothing when using glxgears and will work correctly with eglgears_wayland

@nokia8801
Copy link
Author

nokia8801 commented Dec 8, 2024

Ok, assuming you didn't commit anything else as I'm typing this :D , I just clean compiled with all three commits and same issue in Proton and Minecraft. No shortcuts, no display-server, processes triggered.

But something definitely got fixed with the latest commit. Because before the commits, a game that runs over X11/XWayland because of SDL_VIDEODRIVER=x11 was still able to display MangoHud even though it was built with with_x11=disabled and with_wayland=enabled.

But now there is no MangoHud. So this is progress.

@Etaash-mathamsetty
Copy link
Contributor

Ok, assuming you didn't commit anything else as I'm typing this :D , I just clean compiled with all three commits and same issue in Proton and Minecraft. No shortcuts, no display-server, processes triggered.

But something definitely got fixed with the latest commit. Because before the commits, a game that runs over X11/XWayland because of SDL_VIDEODRIVER=x11 was still able to display MangoHud even though it was built with with_x11=disabled and with_wayland=enabled.

But now there is no MangoHud. So this is progress.

where can I get this build of proton you are using? My minecraft installs use flatpak so I can't test that

@nokia8801
Copy link
Author

nokia8801 commented Dec 8, 2024

It's just Wine TkG with some of the customization options changed. There is more info here. Frogging-Family/wine-tkg-git#936 (comment) in my comment and in the wine-tkg-git page itself.

Make sure to also set Wayland as the Wine Graphics driver with winetricks.

Btw, I have an Intel Arc GPU if that matters, I see that you fixed some Nvidia stuff in the latest commit.

@Etaash-mathamsetty
Copy link
Contributor

you also keep mentioning winetricks, but you don't need to use winetricks on wine 9.22+ just unset DISPLAY

@nokia8801
Copy link
Author

nokia8801 commented Dec 8, 2024

No, that's old advice. If you set Wayland as the only graphics backend for Wine, meaning you do it through Winetricks or through registry editing, without x11 fallback, then you do not need to unset DISPLAY= at all.

Also, the change in Wine 9.22 is that it will use Wayland only if X11 fails. So that does not concern us here.

@Etaash-mathamsetty
Copy link
Contributor

Etaash-mathamsetty commented Dec 8, 2024

No, that's old advice. If you set Wayland as the only graphics backend for Wine, meaning you do it through Winetricks or through registry editing, without x11 fallback, then you do not need to unset DISPLAY= at all.

Also, the change in Wine 9.22 is that it will use Wayland only if X11 fails. So that does not concern us here.

I made that change in Wine 9.22. x11 fails when DISPLAY is unset, so it will automatically use Wayland. Just trying to avoid as many variables as possible since unsetting DISPLAY will force x11 to no function correctly

@nokia8801
Copy link
Author

Oh, then I must've misunderstood it.

Anyways, I still prefer setting Graphics=wayland instead of wayland,x11 or x11,wayland and unsetting DISPLAY=. It's just how I do it. I assume that would be better since less chance of somehow unsetting DISPLAY= not working or it still using XWayland.

So far, since 9.0-rc1, this hasn't failed me once.

@nokia8801
Copy link
Author

That new pull request title is more accurate indeed, relates more to my main issue, which is MangoHud still relying on X11 when built with_x11=disabled.

I've been doing some more testing and will post a new comment detailing which scenarios triggers XWayland and which don't, in a more simpler to read format.

@nokia8801 nokia8801 changed the title When built without X11 and using Wayland only, HUD position is wrong, shortcuts don't work, xwayland is still used MangoHud still relies on X11 even when built with_x11=disabled and with_wayland=enabled Dec 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants