Prefer Wayland over X11 if Available about silk.net HOT 4 CLOSED

Currently, it seems like with linux on wayland, Silk.NET will still prefer using x11 with xwayland. I'm not too familiar with the library so I'm not sure which backend is being used, I think it's GLFW, and this code seems to try x11 before wayland first? I think it'll really improve the experience for linux users, for example SDL already switched to wayland by default a while ago.

This should be discussed upstream at GLFW, we dont decide what backend gets used by default, the linked code is only called after the window is created

from silk.net.

I looked into it and GLFW has a wayland backend and support for choosing a backend at runtime but it's currently not the default as it's less complete. There is a way to hint to GLFW to prefer wayland, this shouldn't be enabled by default as it'll be unexpected for users, are you interested in exposing it somehow to the api/environment variable? If not I'll patch the library downstream, thanks for your help!

from silk.net.

id prefer this be handled upstream, given the still prevalent issues with GLFW on Wayland (ive had a enough of them where i use the x11 version through xwayland exclusively for my own projects), i would not really want to expose a simple way on our end to force the GLFW backend, since that should be handled upstream, GLFW is also an implementation detail of our windowing, as it may choose use to use SDL in some scenarios

from silk.net.

We have discussed exposing backend specific hints in the past, even making it as far as a proposal here, but it was rejected by the working group on the following counts:

• We should properly expose functionality that should be common by designing a proper API around it. Given that the abstraction itself does not know about the backend itself having multiple backends, we haven’t pursued this in this case.
• We should empower the user to obtain the native handle so they can do this themselves. This led to a chain of further work like the native contexts proposal to make it easier to evade our APIs to handle it yourself, and native handles being exposed in #411.

A workaround could be using GlfwProvider.GLFW.Value.WindowHint but this limits your code’s portability - you’d need to somehow make sure that the backend is GLFW ahead of time which I believe can be done using the APIs we expose on Window, but it’s far easier not to care and our position is that we delegate decisions here to our upstream libraries like GLFW.

from silk.net.