Solved Wayland on FreeBSD

I found that I can compile a wayland client.


The example above requires:

# pkg install ImageMagick7
# pkg install wayland-protocols

The usual edits to the Makefile apply - add "-I/usr/local/include" and "-L/usr/local/lib" to CFLAGS. Throw in a "-lwayland-client" for good measure.

Well - it compiles and links.

When I run it, I get two errors:
error: XDG_RUNTIME_DIR not set in the environment.
failed to create display.

I confess my total ignorance of how wayland works. "apropos wayland" offers no help. How do I get a wayland compositor up and running?
 
This wasn't so bad after all. With X already running ...

Sorry, but now I am bit astonished. I only loosely tracked the Wayland advancements in FreeBSD, however, I thought, Wayland has been designed as a X11 replacement, at least as far as the display server and the window manager are concerned. Now, how does X fit into this picture, and if I need X for what do I need Wayland then?
 
It is very confusing because Wayland was designed to be so flexible. You can have an X server that is a Wayland client. See xwayland. Wayland supports multiple backends - including x.org. In the example above, sway is an X client that accepts Wayland clients.
 
The SOLVED label next to your title "Wayland on FreeBSD" is most confusing if not deceiving. Please correct me, but this is a Wayland-App without Wayland.

Wayland can be confusing. To be clear - wayland really isn't a program - it is a protocol - much like X11 is a protocol. You don't need weston if you have some other program as your wayland server. sway(1) is built on wlroots which looks to be weston-like library. I'm using sway(1) as the wayland server. cage(1) might also work - I've not tried it. I don't know enough about sway(1) to swap out backends. It should be possible to use DRM (real hardware) or RDP (network accessible frame buffer). Clearly the X11 backend works.

So this was a test to see if I could run a wayland app on a wayland server. It also neatly coexists with X11. I can now experiment with writing wayland clients. For anyone wanting to play around with wayland - this is looking quite good to me.

If you expect wayland to mean - "no X Windows" - don't. I see now that would be too painful. Run an X server backed by wayland or a wayland server backed by an x.org server. Either way I can keeping using all my X apps. I don't have to shut down one server to run apps under the other.

As you and I both found - there is much missing documentation. I posted a wayback archive link to the now missing "bobulate" blog entry that was featured in BSD Now Episode 204 (two years ago) because knowing to set that environment variable was key.

All this is new to me so bear with me. Anyone is welcome to fill in the gaps.
 
Wayland can be confusing. To be clear - wayland really isn't a program - it is a protocol - much like X11 is a protocol. You don't need weston if you have some other program as your wayland server. sway(1) is built on wlroots which looks to be weston-like library. I'm using sway(1) as the wayland server. cage(1) might also work - I've not tried it. I don't know enough about sway(1) to swap out backends. It should be possible to use DRM (real hardware) or RDP (network accessible frame buffer). Clearly the X11 backend works.

So this was a test to see if I could run a wayland app on a wayland server. It also neatly coexists with X11. I can now experiment with writing wayland clients. For anyone wanting to play around with wayland - this is looking quite good to me.

If you expect wayland to mean - "no X Windows" - don't. I see now that would be too painful. Run an X server backed by wayland or a wayland server backed by an x.org server. Either way I can keeping using all my X apps. I don't have to shut down one server to run apps under the other.

As you and I both found - there is much missing documentation. I posted a wayback archive link to the now missing "bobulate" blog entry that was featured in BSD Now Episode 204 (two years ago) because knowing to set that environment variable was key.

All this is new to me so bear with me. Anyone is welcome to fill in the gaps.

Do you know why in any FreeBSD installation with Xorg on it, there is always this Wayland stuffs. Can freebsd live without it?
Seems like pulseaudio audio anywhere on any KDE, Gnome,... soon Wayland.
 
Can freebsd live without it?
I do not know how to remove any Wayland dependencies. However, I see no harm. I do have other concerns - my very shallow understanding is this:

Wayland is just a protocol - just like X11.
Wayland claims to solve may deficiencies of X11 - however it is still a client / server protocol, just like X11.

Look at the two diagrams on the Wayland architecture page that compare X11 to Wayland:


It shows the X server as two boxes - an X server and a compositor whereas the Wayland diagram only needs one. This distinction is dubious. The two boxes are an implementation detail. The x.org implementation of X11 isn't the only one and is not forever doomed to work a certain way. They could be re-implemented to collapse the two into one. Indeed - having them separate with a well defined API may be better.

Another advantage boasted by Wayland is the API is completely asynchronous. This was a deficiency of the original X libraries where every operation was a blocking call. This was fixed by switching to the XCB implementation of X11 on the client where everything as asynchronous. So far XCB works well for me.

I have no idea when a Weston server will appear in ports. Several of the sample Wayland client "hello world" apps I have looked at directly include Linux kernel GPL2 header files into client code. That will need to be cleaned up at some point.

I do like the fact they made a conscious effort to not force DBUS as a dependency (from the FAQ):

Why wasn't D-Bus used instead of the Wayland IPC mechanism?
I wanted to preserve some important properties from the X protocol: the ability to queue up an event or request by just memcpy'ing into the protocol out-buffer. That's what wl_connection_write does. Furthermore, it lets us memcpy several messages into the buffer and only write it all before we go back to blocking in the main loop. Second, everything is explicitly asynchronous, which is a really powerful feature in a protocol.

So ...

TL;DR if x.org plus XCB gives me most of what Wayland has to offer - I'm in less of a hurry to migrate over. On top of that there are ways for X11 and Wayland to coexist so it when it does happen, my old(er) code still works. I still want to keep tabs on Wayland to see where it goes.
 
I do not know how to remove any Wayland dependencies. However, I see no harm. I do have other concerns - my very shallow understanding is this:

Wayland is just a protocol - just like X11.
Wayland claims to solve may deficiencies of X11 - however it is still a client / server protocol, just like X11.

Look at the two diagrams on the Wayland architecture page that compare X11 to Wayland:


It shows the X server as two boxes - an X server and a compositor whereas the Wayland diagram only needs one. This distinction is dubious. The two boxes are an implementation detail. The x.org implementation of X11 isn't the only one and is not forever doomed to work a certain way. They could be re-implemented to collapse the two into one. Indeed - having them separate with a well defined API may be better.

Another advantage boasted by Wayland is the API is completely asynchronous. This was a deficiency of the original X libraries where every operation was a blocking call. This was fixed by switching to the XCB implementation of X11 on the client where everything as asynchronous. So far XCB works well for me.

I have no idea when a Weston server will appear in ports. Several of the sample Wayland client "hello world" apps I have looked at directly include Linux kernel GPL2 header files into client code. That will need to be cleaned up at some point.

I do like the fact they made a conscious effort to not force DBUS as a dependency (from the FAQ):



So ...

TL;DR if x.org plus XCB gives me most of what Wayland has to offer - I'm in less of a hurry to migrate over. On top of that there are ways for X11 and Wayland to coexist so it when it does happen, my old(er) code still works. I still want to keep tabs on Wayland to see where it goes.
it comes from Linux planet, infiltrating Unix.
 
toward

> if X11 gives what Wayland has to offer

i would remark that what Wayland offers is _not X11_. unix planet X11 still understands how to display according to radians while we live in a pixel world. it's like xterm to access terminal hardware that for seriously all practical intents (i.e. my own) doesn't exist anymore.
i'm sure wayland compositors [servers] have a lot of problems of their own, yet X11 isn't getting overhauled and pared down. the project isn't getting any "new blood" because Wayland exists. that in and of itself might be a problem. like, why do we have to rewrite rather than maintain by perfect concensus? moreover, why do we need more than rio -- although this is a total digression, i'm sure.

----

what i'm writing to ask is whether it'd be worthwhile to update the wiki with some information along these lines? i'd be interested in duplicating the setup here and helping to document it on the wiki -- and even more interested in setting up RDP (whatever that may stand for?) to allow using a Linux box to serve as a display while continuing to use the terminal (well, a terminal multiplexer) in preference to X11 such are my hopes for that program ever converging on something fork-able without significant incidental complexity.

is the wiki page i'm referring to
 
...and even more interested in setting up RDP (whatever that may stand for?) to allow using a Linux box to serve as a display while continuing to use the terminal (well, a terminal multiplexer) in preference to X11 such are my hopes for that program ever converging on something fork-able without significant incidental complexity...
Is this the RDP you're looking for?

Anyone give Arcan a try?
 
Arcan is neat .. suspect nuklear meets most needs, yet the "engine" metaphor of arcan is appealing.

Anyway, I suspect this gtk-ish lib is out of scope for initial setup? Like, if bsd has arcane and can serve it via Wayland, great. It's the non-X Wayland server / client setup that I'm thinking this thread is about?
 
Back
Top