Show Posts
1
SFML development / Wayland backend implementation
« on: October 09, 2020, 05:44:32 am »
Hi everyone!
I'm rather new to this forum (and to SFML), so please let me know if this is the wrong place for this...
I've recently started a branch of the main SFML repository which aims to add Wayland backend support in parallel to the existing X11 backend support. It looks like this is a feature people would like to have[0,1]. However, fully completing a Wayland backend is a lot of work, and my time and attention is limited, so it might be a full year (if ever) before the backend is good enough to be worth using by default. Even then, features like sf::Mouse::setPosition will not be available due to Wayland's different mouse model.
The approach that I took is to get the core working as quickly as possible and avoid changing stuff outside Window/Unix. The existing code for X11 I moved to a new folder, and renamed all classes to end with "X11", i.e., "InputImplX11". In a folder for Wayland, I created new classes (e.g., WindowImplWayland), and similarly to the X11 structure I created a DisplayWayland.cpp file to handle the global things. Then in place of the original classes in Window/Unix/, I wrote stub classes that, depending on whether we've connected to Wayland or X11, forward to the corresponding real implementation.
Current status:
* I can run simple applications that use basic keyboard and mouse input, and a normal events-render loop. Only a few events (key press, button press, mouse motion) are implemented.
* Only one window works, at a fixed windowed resolution. No fullscreen, vsync control, resizing, window events, video modes, etc.
* I've neglected code style entirely.
* I didn't figure out how to get pixel buffers to work -- I couldn't find a compatible EGLConfig. I'm not using glad for the Wayland backend, but instead linking directly to libEGL. Trying to reuse the EGLcontext.cpp did not work.
* The code often crashes on exit.
* To enable Wayland, the environment variable SFML_BACKEND must be set to "wayland". Otherwise, X11 is still used by default.
None of the remaining work is risky or technically complicated; it just takes time to fully understand the Wayland protocol specifications, implement various events and input handling features, fix bugs, etc.
My question for you all, is what to do with this work.
* Should I make a pull request now containing just what I have (with code style fixed, error handling and cleanup logic written), try to get it merged, and then whenever I have a new feature, make a new request?
* Or should I slowly work on my branch, allow others to make PRs to it, and when it is good enough, submit a massive pull request?
* Or start a pull request now, and keep responding to review and updating it with new features?
I'd prefer the first option, because it minimizes my responsibilities :-).
An additional question:
* What do you think about the architecture? The "splitter" classes are ugly, but ultimately some form of dynamic dispatch is necessary (unless you abuse dynamic linking...)
0. https://en.sfml-dev.org/forums/index.php?topic=25246.msg168531
1. https://en.sfml-dev.org/forums/index.php?topic=26268.msg170956
2. branch "wayland-dual" at https://github.com/mstoeckl/SFML-wayland.
I'm rather new to this forum (and to SFML), so please let me know if this is the wrong place for this...
I've recently started a branch of the main SFML repository which aims to add Wayland backend support in parallel to the existing X11 backend support. It looks like this is a feature people would like to have[0,1]. However, fully completing a Wayland backend is a lot of work, and my time and attention is limited, so it might be a full year (if ever) before the backend is good enough to be worth using by default. Even then, features like sf::Mouse::setPosition will not be available due to Wayland's different mouse model.
The approach that I took is to get the core working as quickly as possible and avoid changing stuff outside Window/Unix. The existing code for X11 I moved to a new folder, and renamed all classes to end with "X11", i.e., "InputImplX11". In a folder for Wayland, I created new classes (e.g., WindowImplWayland), and similarly to the X11 structure I created a DisplayWayland.cpp file to handle the global things. Then in place of the original classes in Window/Unix/, I wrote stub classes that, depending on whether we've connected to Wayland or X11, forward to the corresponding real implementation.
Current status:
* I can run simple applications that use basic keyboard and mouse input, and a normal events-render loop. Only a few events (key press, button press, mouse motion) are implemented.
* Only one window works, at a fixed windowed resolution. No fullscreen, vsync control, resizing, window events, video modes, etc.
* I've neglected code style entirely.
* I didn't figure out how to get pixel buffers to work -- I couldn't find a compatible EGLConfig. I'm not using glad for the Wayland backend, but instead linking directly to libEGL. Trying to reuse the EGLcontext.cpp did not work.
* The code often crashes on exit.
* To enable Wayland, the environment variable SFML_BACKEND must be set to "wayland". Otherwise, X11 is still used by default.
None of the remaining work is risky or technically complicated; it just takes time to fully understand the Wayland protocol specifications, implement various events and input handling features, fix bugs, etc.
My question for you all, is what to do with this work.
* Should I make a pull request now containing just what I have (with code style fixed, error handling and cleanup logic written), try to get it merged, and then whenever I have a new feature, make a new request?
* Or should I slowly work on my branch, allow others to make PRs to it, and when it is good enough, submit a massive pull request?
* Or start a pull request now, and keep responding to review and updating it with new features?
I'd prefer the first option, because it minimizes my responsibilities :-).
An additional question:
* What do you think about the architecture? The "splitter" classes are ugly, but ultimately some form of dynamic dispatch is necessary (unless you abuse dynamic linking...)
0. https://en.sfml-dev.org/forums/index.php?topic=25246.msg168531
1. https://en.sfml-dev.org/forums/index.php?topic=26268.msg170956
2. branch "wayland-dual" at https://github.com/mstoeckl/SFML-wayland.