allegro5
allegro5 copied to clipboard
liballeg
Wayland backend
Wayland on Linux is advancing well towards completion, it seems, so Allegro on Linux should start getting ready for it as well and support it as a back end.
Edit: This will require OpenGL ES support on the Linux desktop as well.
It's harder than I thought, no thanks to the Wayland API. In many cases, seven steps are needed to do something simple. For example the amount of code need to set the mouse cursor is ridiculous. Looks like they simplified the "insides" of Wayland versus X by pushing part of the complexity towards the client.
I don't understand what complexity you're referring to. Here's a very basic example that listens to pointer events: https://github.com/emersion/hello-wayland/blob/master/main.c
Let me know if you have any questions regarding Wayland.
Edit: sorry for bringing this up after 4 years, I just noticed the original post's timestamp.
No. I attempted a port a few years ago but it didn't amount to much. We are currently severely understaffed, and Allegro 5 development is now mostly in maintenance mode. Though if you are interested your contribution would be most welcome.
Op ma 1 jun. 2020 22:14 schreef ZweiEuro [email protected]:
does allegro officially support wayland ?
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/liballeg/allegro5/issues/501#issuecomment-637078368, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAARM6LP4TQM57XFTMB44XLRUQD3NANCNFSM4BPRJDRQ .
I think we now support GLES on desktop, so some progress has been made. Wayland was never really a priority though. If you for some reason absolutely must use Wayland, you can use the experimental SDL backend by configuring Allegro with cmake ALLEGRO_SDL=on.
Ah thanks for the reply. Sadly I don't think I am advanced enough (yet) to be of much help. Though I would be interested in getting the wiki fully ported... I am having issues finding stuff and have problems for which I would want to ask the wiki before posting an issue...
If Wayland support is added it should be for a use case other than the Linux desktop (e.g. if a handheld device comes out that uses it).
If desktop Linux Wayland support was implemented at the time this bug was filed (2015), apparently when it was "advancing well towards completion"... It would be entirely broken (i.e. in a way that it might not even attempt to fall-back to X11) unless the code planned in advance for a core protocol to be ripped out of implementations (wl_shell) to make way for something that fits the GNOME worldview (xdg_shell).
There's a blatant disregard for backwards compatibility in Wayland compositor implementations. Pre-2018 Wayland is effectively incompatible with present-day compositors, and any applications built before then will no longer function on all desktops. Not really acceptable for a library where people probably want to build a binary that will still run in 10+ years from now.
Also, GNOME does not support server-side decorations, so Allegro would either have to use GTK even for basic window creation, or something like "libdecor" which draws knock-off titlebars (which would surely just drift out of sync with the monthly stylistic changes in GTK). With the "move fast break everything" attitude, a GTK back-end is a more sane proposal than a Wayland back-end, so that the GTK shared library can bridge the ever-moving incompatibility gap between Wayland app and Wayland compositor. That is to say: sticking to exclusively using X11 for the Linux desktop in Allegro is the way to go.
Any concerns about performance on Wayland powered desktop environments would be better invested making sure that Xwayland has the fastest possible implementation for pushing pixels via X11's SHM / DRI extensions, and that Allegro is making use of them for the best performance where possible.
The more time goes by the more clear it becomes that Wayland is a disaster. We should have taken a hint from plan9's 8 1/2 windowing system in stead. For now X11 is still the most reliable API.