-
-
Notifications
You must be signed in to change notification settings - Fork 33
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
XWayland support #12
Comments
Investigate if we can use https://github.com/sidorares/node-x11 in the browser, maybe fork & patch it so it can use websockets and doesn't need node dependencies. https://github.com/udevbe/browser-x11 |
The lack of XWayland support seems to be the number one blocker to adopting greenfield. Do you have plans to address this feature in the near term? |
I wasn't really aware this was the number one priority for users. I'm currently doing a rather large refactor of the core middleware using redux-saga + typescript which is almost done. Once finished (hopefully somewhere this week), I could start the XWayland support. |
I'm making the claim it's "number one" given the majority of Linux graphical applications require X11 to function, thereby the majority of users require X11 support in greenfield to use their daily applications. Starting work on XWayland would be most exciting. Thanks for taking up the challenge :) |
TODO
|
Hello! Just wanted to check in to see how progress on this was going 😃 |
DONE:
TODO:
|
DONE:
TODO:
|
So great to see this supported! Thank you!! |
c/p is now fully implemented for both xwayland and browser fullscreen supported will be added later on |
Adding XWayland support would allow running large number of applications that do not have a Wayland port. For this we need to implement an X window manager in the Greenfield compositor. It will be required to compile a modified XCB/Xlib to WebAssembly in order to maximize code reuse.
The text was updated successfully, but these errors were encountered: