Wayland support

#1

So this is something that is lurking around the corner. Getting Wayland as a possibility on Linux. I would like to get an idea of how complicated of a task that is from the JUCE side. I'm working @Samsung now in a Tizen team, part of my "yearly target" is porting JUCE to Tizen. I see Tizen moving in the wayland directio (Intel is pushing it hard in it's IVI Tizen builds, but Samsung is using Xorg for now and that's what i'm working on witht the in-house hardware i'm testing Tizen on).

Anyway i got Juce to run on the internal hardware on Tizen 2 and 3 but using Xorg ofcourse, it runs just like on any other Linux distro (to write some utilities i needed i'd rather take JUCE then the very weird SDK provided by Samsung that's based on Enlightenment).

So my question would be, where to start, is the native file for windows in the juce sources the main Xorg specific code or is Xorg in some other places. If i'll know where to start i'll try to get to it, so far i got wayland+weston running on Tizen3 on exynos hardware (it's really just a GALAXY S3 with a Tizen logo that never went public, but that's our target device and that's what wen to other developers). Can you give me any hints on where to start and how to test this, i'm taking the "platform" aspect out of the equasion and will be doing that nativly on x86 with weston to simplify stuff. My goal is to get the Demo and Introjucer running under Weston and move to ARM/Exynos a bit later. I might get some help on that from Intel (we are working close with Intel on this).

Any help you can give me would be great, if someone would like to jump aboard i see no problem, my team does everything publicly so there are no licensing issues. I will start a git repeo and try to do my work there (git and gerrit are the main tools used here).

Porting JUCE on Tizen 3/2 with Xorg was not an issue it's running fine. Wayland uses GL for all it's drawing i was hoping that this will help due to the fact that JUCE has it's owen GL support. But the Software Renderer would be a nice thing too..

 

Anyway i'm counting on you guys and maybe we can do something really cool in the world of Linux.

cheers

#2

Would love to see this! But apart from a vague notion of what it is, I know absolutely nothing about Wayland or how it works.

Is it something where you'd build your app with a compile-time switch to either work on X or Wayland, or could you build it so that it takes advantage of Wayland if it's available, and falls back to X if not?

#3

I think a macro would be best for this (disabled by default for now).

If we're targetting wayland, it would be best to NOT build any X11 stuff. But there might be an issue regarding VST plugins, which need an X11 Window pointer...

Trying to handle Wayland events plus X11 might be tricky, so perhaps the best choice is to use X11 for VSTs and Wayland everywhere else?

(btw, LV2 plugins don't require X11)

 

#4

Yeah wayland replaces Xorg completly.

There is a compatibility layer in wayland for older Xorg applications, there are issues with that now (what i saw input handling is the biggest one). But it's there.

I thought about a replacement for Xorg, that is never to include both in the library. However both are also possible and an application could theoreticly work on Xorg and Wayland i think (that's how GNOME does that now it supports both).

Wayland itself is a library, it's not a server, only the compositor runs as a process there is no "server layer" in wayland. There is a short description of the architecture: http://wayland.freedesktop.org/architecture.html

QT5 supports it GTK3 supports it (and latest GNOME), EFL can now be a compositor (replacaes Weston) and the work seems to be moving forward.

#5

Yeah, wayland is for sure the future on Linux desktops. My only concern right now is how to handle the Mir vs Wayland situation...

For commercial products this is going to get very tricky.

#6

Can't wait to start shipping three different versions of my application + plugin, one targetting X11, one targetting Wayland and a last one for Mir !

(sorry , just grumbling, the wayland version will have to happen anyway -- it would be great, though, if a single binary could work on both wayland and x11)

#7

Hey it's not my fault that Xorg is broken beyond repait and the Mir/Wayland issue is something weird, i don't know why Canonical didn't agree on something with the community.

All i can say is i got wayland to wokr on an ARM target (a galaxy S3) with Tizen (it's linux on a linux kernel 3.10) and it works much faster using a generic driver (there is no real support for MALI/Exynos on that hardware, so wayland is using something called swrast). I got transparency really fluent movement and it starts much faster.

#8

QT5 / GTK3 / SDL2 / cairo support wayland, waiting for JUCE.

#9

VSTs are already using X11 window handles, I don't think that is going to change.

For standalones and LV2 we should use wayland.