Support for WASI

[skyne98]

Hey there, everyone!

I have seen some discussion here related to support of WebAssembly through wasm32-unknown-unknown target. @tomaka has mentioned, that we cannot make assumptions about the environment, which was true.

However, now we have a wasm32-wasi target for both rustc and clang. Is it possible to create a working backend for winit to run as a wasi webassembly binary?

Thanks!

[elinorbgr]

Is there some possibility of unification with the works of #845 and #797 ?

[skyne98]

@vberger, I guess it will make sense. However, as far as I understand, WASI version of Winit should work more or less the same way the Linux one does, except for some minor limitations (no locks, no threads)?

[elinorbgr]

I was just trying to bring up things that might or might not be relevant. I know pretty much nothing about WASI.

Does WASI exposes its own system windowing API, or would a WASI client have to connect to a regular x11 / wayland socket? In the latter case, does that mean that the system libraries (libwayland / libx11 / mesa / ...) would need to be compiled to the wasm32-wasi target as well?

[skyne98]

It is definitely the latter. Also, yes, it means the all of those libraries will have to be compiled to this target as well.

It sounds like an awful lot of compatibility issues if libraries won't play well with this new target. Also, as far as I understand, current wasi's libc is based on musl, therefore, I can assume they should also available for static compilation & compilation with musl libc.

[elinorbgr]

In that case, Wayland support would be pretty easy to get (thanks to the pure-rust implementation in wayland-rs), but I cannot speak at all for the other platforms, nor about opengl / vulkan.

It'd be great to have some idea of what the general plans are for windowing / opengl / vulkan with WASI in general, unrelatedly of winit.

[skyne98]

In the end it should still come down to making system calls, right? In that case, it's just a matter of extending the set of supported system calls to encompass required functionality.

I guess this is an example of supported syscalls.
Or this official document which is even better.

[elinorbgr]

What I mean is: winit supporting this is dependent on the required system libs being ported to WASI. This is not a small feat, and winit cannot really do anything until it is done.

[skyne98]

But I think that, in theory, this can be done in a more gradual manner. Maybe starting with Wayland, because of already existing wayland-rs? This way we should be able to get some way of GUI up and running while learning on its experiences to extend the functionality.

[elinorbgr]

Yes, absolutely. I guess the first step would then to get wayland-rs and then SCTK to compile to wasm32-wasi.

[skyne98]

@vberger, I guess that it won't yet be possible without proper IPC support, right?

[elinorbgr]

Oh good point, the wayland protocol requires being able to send and receive file descriptors though an unix socket.

[daxpedda]

I'm not following exactly how this would be achieved by Winit.
This can only work based on a custom host environment that supports the necessary API required by Winit.

I believe #2430 would be the appropriate solution for something like this, unless a popular WASI extension crystallizes itself.

In any case, this isn't a Winit issue until any sort of host bindings exist.

Feel free to reopen if there are any news, I'm certainly interested and would support the integration!