Solved Wayland on FreeBSD

unitrunker

Active Member

Reaction score: 63
Messages: 175

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?
 

drhowarddrfine

Son of Beastie

Reaction score: 1,217
Messages: 3,238

Are you using a Nvidia card? Wayland is such a mess even on Linux where it's being force fed.
 
OP
OP
U

unitrunker

Active Member

Reaction score: 63
Messages: 175

This wasn't so bad after all. With X already running ...

# mkdir /tmp/xdg
# pkg install sway
# XDG_RUNTIME_DIR=/tmp/xdg
# sway &
# ./hello-wayland

That was enough to run the tiny "hello world" wayland app.
 

obsigna

Aspiring Daemon

Reaction score: 558
Messages: 956

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?
 
OP
OP
U

unitrunker

Active Member

Reaction score: 63
Messages: 175

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.
 
OP
OP
U

unitrunker

Active Member

Reaction score: 63
Messages: 175

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.
 

Spartrekus

Daemon

Reaction score: 153
Messages: 1,150

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.
 
OP
OP
U

unitrunker

Active Member

Reaction score: 63
Messages: 175

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.
 

Spartrekus

Daemon

Reaction score: 153
Messages: 1,150

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.
 
Top