Skip to content
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

How to run Ecode natively on Wayland #404

Open
artist-artix opened this issue Mar 18, 2025 · 10 comments
Open

How to run Ecode natively on Wayland #404

artist-artix opened this issue Mar 18, 2025 · 10 comments
Assignees
Labels
enhancement New feature or request

Comments

@artist-artix
Copy link

Issue #344 shows that on Linux, Ecode runs natively on Wayland. But when checked using xeyes, which is often used to check if an application is using X11 or not, this shows Ecode is not running on Wayland but using X11.

When the X11 specific DISPLAY variable is unset, Ecode will segfault at startup.

I tried this with Ecode built from source, and with an Ecode binary package downloaded from sourceforge; both show X11 is being used.

In another attempt I did first build SDL2 with X11 support disabled, and then tried to build Ecode against it which resulted in error:

../../src/eepp/window/backend/SDL2/wminfo.cpp: In member function ‘_XDisplay* EE::Window::Backend::SDL2::WMInfo::getWindowHandler() const’:
../../src/eepp/window/backend/SDL2/wminfo.cpp:52:27: error: ‘union SDL_SysWMinfo::<unnamed>’ has no member named ‘x11’
     52 |         return info->info.x11.display;

File eepp/window/backend/SDL2/wminfo.cpp shows there is a check for these platforms:
EE_PLATFORM_WIN EE_PLATFORM_MACOS EE_X11_PLATFORM EE_PLATFORM_IOS EE_PLATFORM_ANDROID

So there does not seem to be Wayland platform support for SDL2, but maybe I'm missing something.

If Ecode can run natively on Wayland, what is required to make this work?

@SpartanJ SpartanJ self-assigned this Mar 19, 2025
@SpartanJ
Copy link
Owner

Hi! I think I made some mistakes and it's not currently working properly. But I cannot verify it this week due to no having access to Linux systems.

I did change the way ecode is build for distribution, now it's being automatically built with GitHub Actions, and I don't remember testing pure Wayland with those builds, so it's probable that something is not correct (SDL2 is being build during the process, it has X11 and Wayland activated but something might be wrong).

Regarding the manual build it still requires X11 headers to build, although the error is happening due to SDL2 headers being different in your distribution: it does not have any mention to X11 and I guess it make sense but it's not expected by eepp/ecode context.

I just pushed a few changes that should help you build ecode with no issues, could you pull the latest changes a try again, please? Thanks

@artist-artix
Copy link
Author

Hi,

Thank you for looking into this.

Here's what I did:

  • Created a package for SDL2 without X11 support.
  • Installed this SDL2 package.
  • Built an Ecode package from the latest EEPP commits against the above SDL2 package, which succeeded.
  • Installed this Ecode package.

After this, Ecode starts and works fine also when the X11 DISPLAY variable has been unset.
And the xeyes test confirms that this Ecode uses Wayland and not X11.

So this is a good workaround to run the current Ecode on Wayland.
The ultimate fix should be that Ecode uses Wayland when this is available.

artist

@SpartanJ
Copy link
Owner

Great it worked. Yes, I need to check how to enable Wayland and X11 and use Wayland by default when available. That was supposed to be the SDL2 default behaviour but maybe I missed something or the version used is bugged, so first I'll update to the latest SDL2 version just in case.

@artist-artix
Copy link
Author

I did some investigating and found the change that happened is not in Ecode, but is in SDL; a while ago the SDL devs changed the default for SDL2 from 'wayland' to 'x11'. For SDL3 the default should still be 'wayland'.

As a workaround it is possible to export SDL_VIDEODRIVER=wayland before starting Ecode.

Setting this inside Ecode itself can possibly be done using SDL_SetHint as per https://wiki.libsdl.org/SDL2/SDL_SetHint

@SpartanJ
Copy link
Owner

Oh I was sure they reverted it back to Wayland by default in SDL2 too! Thanks I'll take a look.

@SpartanJ
Copy link
Owner

@artist-artix Could you do me a favour? Could you test running ecode from the default distribution (maybe use the nightly) with SDL_VIDEODRIVER=wayland environment flag and describe what happens? Thanks

@artist-artix
Copy link
Author

I downloaded https://github.com/SpartanJ/eepp/releases/download/nightly/ecode-linux-nightly-x86_64.tar.gz and untarred it.
Then ran:
cd ecode
SDL_VIDEODRIVER=wayland ./ecode

This makes ecode start up correcty, and using wayland.

@SpartanJ
Copy link
Owner

I made a few tests. Setting SDL_VIDEODRIVER=wayland on a pure X11 environment will not find any display so it will fail (currently it will crash ecode but i'll push a patch to avoid the crash and display the error). Using it on something like Ubuntu 24.10, that runs on Wayland, will work but Window decorations won't be visible (I'm not sure what's going on, libdecor is installed and should handle that), even trying SDL_VIDEODRIVER=wayland,x11 which selects the first available video driver won't be enough because it will use wayland by default. So forcing the video driver to Wayland does not seem a good idea at least in the current state. I don't see any possible improvement from my side for the moment so I might just add some comment in the documentation that if you want to run ecode in pure Wayland you must set this environment variable. Although I'll update to the latest SDL2 version and see if that changes anything, but that's everything I can think of.

@SpartanJ SpartanJ added the enhancement New feature or request label Mar 25, 2025
@artist-artix
Copy link
Author

Thanks for you help and the upcoming patch.
I'm sorry to hear that in your case the window decorations are not visible. As for integration with other software Wayland still is an inconsistent mess. I use Labwc as the WM on our Artix Linux platform and the decorations are present. I have added a local patch to ecode to hint SDL to use Wayland and this seems to work OK.

@SpartanJ
Copy link
Owner

I have added a local patch to ecode to hint SDL to use Wayland and this seems to work OK.

Cool!
I'll investigate a little bit further why decoration isn't working on Ubuntu 24.10, before activating anything I want to be sure that works properly for everyone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants