Feature Request: Wayland support

[aveao]

Currently, when ImHex is ran with glfw-wayland, it gives a notable amount of errors regarding window position retrieval/setting. I've even faced crashes when doing random things in a not very reliably reproducible way (I've had one after I clicked "Open File" and another when I was resizing the hex editor). I'm willing to test more if needed.

Here's an output containing both the usual errors, and the specific error that led to the crash on the file open:

Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported
[...a lot more of the same...]
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position setting not supported
Glfw Error 65544: Wayland: Window position setting not supported
xdg_wm_base@9: error 3: xdg_surface must not have a buffer at creation
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported

It would be nice to have ImHex account for a wayland environment and not use unsupported features, if possible.

To any other glfw-wayland users, the only workaround I found is to install glfw-x11 (and remove glfw-wayland) to force ImHex to run in XWayland.

[WerWolv]

Hey!
This seems to be caused by wayland wanting EGL instead of OpenGL. Do you have a build setup right now? If so, you can try changing the OpenGL profile in source/window.cpp, line 221 to GLFW_OPENGL_COMPAT_PROFILE instead of GLFW_OPENGL_CORE_PROFILE and see if that works

[aveao]

I do currently have a build setup, will test that and report back.

[aveao]

That doesn't seem to help with the errors or the crashes, sadly. I think it ended up adding transparency though.

That said, I did manage to reproduce one of the crashes that I'm facing:

When using glfw-wayland, dragging one of the sub-windows (such as hex editor) to the side of the screen (and thereby triggering the snap feature) causes a fairly reliable "crash".

On some "crashes", it actually gave an error:

ImHex: /home/ave/Projects/ImHex/libs/ImGui/source/imgui.cpp:11327: void ImGui::UpdateViewportsNewFrame(): Assertion `g.MouseViewport != __null' failed.
[1]    74508 abort (core dumped)  ./ImHex

and exited with 6, but on some the window just disappeared without an error, and I had to C-c to exit ImHex. And in some cases, it disappeared without an error, but exited with 0.

However, all cases, this was also in the logs shortly before the actual "crash": xdg_wm_base@9: error 3: xdg_surface must not have a buffer at creation

Anyhow, I managed to record a video of these all. It also shows the Open File thing breaking randomly.

That one seems to resolve itself when I remove the imgui.ini. Here's one that causes such a crash. I think that one is caused by the negative position of the hex editor that somehow ended up there. Changing that to a positive number fixes the crashes that happen as a result of opening the Open File window.

[WerWolv]

Oh this looks like an issue with ImGui's new viewports feature. Maybe @ocornut knows more about this?

[ocornut]

As I understand Wayland currently doesn't permit application to neither set or get position or size of windows (!) which is causing problem to our approach. I don't think that's related at all to the crash but at least that's what the GLFW error is spewing.

1. Short-term I think your app should disable multi-viewports on Wayland.

2. There's an issue with MouseViewport being null which should be investigated. A quick parsing of the bottom of UpdateViewportsNewFrame() hints at the fact that the only possible way this is NULL is if g.MovingWindow != NULL but g.MovingWindow->Viewport == NULL.

I personally haven't used Linux in decades. There is a thread asking for help from Mac/Linux users ocornut/imgui#2117 but it yielded zero patches so far. Apart from the ones I paid for Rokups to do because it was frustrating to see so many glaring Linux/Mac issues. It would be great it someone sat down and tackled those problems, alas multi-viewport it not a simple feature so that person will need patience to go back and forth to find a solution for Wayland.

PS: The negative position shouldn't be a problem.

[WerWolv]

Thanks for your input! I'm going to disable multi-viewports then temporarily.

[xhebox]

@WerWolv

Here is a dirty patch that makes ImHex working under pure wayland env without crash(without multi-viewports), link.

I want a pure wayland support in addition to the original request. I did not have x11 on my linux distro. The thing is that: wayland is using GLES+EGL, there is no desktop GL.

And, yes, multi-viewports are not supported somehow, but solved by discarding this lineio.BackendFlags |= ImGuiBackendFlags_RendererHasViewports;.

[denysvitali]

I can confirm that @xhebox patch works! Thank you 🚀 !

[ocornut]

And, yes, multi-viewports are not supported somehow, but solved by discarding this lineio.BackendFlags |= ImGuiBackendFlags_RendererHasViewports;.

You shouldn't have to modify the backend.
You can just avoid setting io.ConfigFlags |= ImGuiConfigFlags_Viewports in the app to disable the feature.

[xhebox]

You can just avoid setting io.ConfigFlags |= ImGuiConfigFlags_Viewports in the app to disable the feature.

Thx for reminding that. But it is just a dirty patch and I don't know much about ImGUI. I would be happy to leave the real PR/commit to someone else.

[xhebox]

wayland patch updated to 1.13.0. It is possible to patch imhex only, which means a cmake options is possible to make it compilable under pure wayland env. Any one interested could fire an PR.

The main changes to make it happen are:

1. Remove usage of imgui_impl_opengl3_loader.h since GLES2 imgui did not use that file.
2. Replace hardcoded opengl things with glfwWindowHint(GLFW_CONTEXT_CREATION_API, GLFW_EGL_CONTEXT_API)
3. define IMGUI_IMPL_OPENGL_ES2 or IMGUI_IMPL_OPENGL_ES3, and choose a proper GL backend by OpenGL::XXX. For me, it is OpenGL::OpenGL, which is libglvnd.

[WerWolv]

@xhebox Does GLES2 make other things worse compared to OpenGL3? If not, I'm up to switching to that instead if it means Wayland works fine.

[xhebox]

@xhebox Does GLES2 make other things worse compared to OpenGL3? If not, I'm up to switching to that instead if it means Wayland works fine.

I don't think it makes much difference for imhex, since imhex is not really a heavy graphic load. But I like to give some points:

1. GLES2 is basically WebGL1, which means you can only use #version 100 gles shader. This is the primary disadvantage compared to modern desktop GL, because of its limited shader functionality. But almost all wayland apps are using GLES2/3 to render and you could see all kinds of WEBGL1 demo on the web. So I would say there is no performance concern, at least for the current ImHex. (BTW, GLES3 is comparable with OPENGL3, but It is not that widely supported)
2. There are some problems even with my patch: I mean it is not working perfectly under pure wayland. For example the splash screen looks wrong. And window sizing is clearly wrong, since settings windows are extremely large and it covers all other things. Of course, all these things are likely a problem of GLFW, which did not adapt wayland well even on the master.
3. Talking about the portability of GLES2, it is shipped with mesa, which means every linux distro should have it. I don't know much about the support on windows.

[WerWolv]

If you want to make a PR, I'll make sure to test it out, fix potential issues and merge it if it works fine.

[ctrlcctrlv]

Oh so is that why I can't edit settings lol