Page MenuHomeFreeBSD

Add section for Wayland in the x11 chapter
Needs ReviewPublic

Authored by trhodes on Sun, Oct 10, 5:40 AM.



This change:

  • Adds a section about installing Wayland to FreeBSD;
  • Adds subsequent sections covering three compositors (Wayfire, Sway, and Hikari);
  • Works like a quick start guide covering major configurations and getting a screen lock working;
  • Adds a small section on Wayland utilities that might be useful.

Would like feedback on:

  • Anything else to add;
  • Check the flow of the information;
  • Validate I'm using the new tools properly;
  • Added Glen in case I can push this in before release. :P
Test Plan

This patch fully builds, has been proofread, and tested.

Diff Detail

R9 FreeBSD doc repository
Lint Skipped
Unit Tests Skipped

Event Timeline

trhodes created this revision.

Small suggestions.


s/replacement is known as wayfire /replacement, known as Wayfire, /


s/=/ = / (as used in later blocks)


s/work the/work with the/ requested changes to this revision.EditedSun, Oct 10, 11:53 AM

Thanks for documenting Wayland on FreeBSD. I added some notes to places that may need change. Not sure about Plasma or nvidia parts, I neither use Plasma nor own and nvidia GPU.


Seems confusing (local AF_UNIX vs remote AF_INET6) X11 connection.
Maybe mention XWayland? Maybe mention net/waypipe as a network proxy
for native clients?


Maybe change "fully utilize the feature set (...) ." to "run natively without XWayland.".


Is it true for DRM backend (not nested sessions)? AFAIK, x11/nvidia-driver doesn't have DRM and GBM support.


seatd is not a requirement for Wayland, see commit ports 095885577 and bug 258042.


Maybe mention sysutils/pam_xdg (see pkg-message) ?


Maybe mention that libseat is needed to get DRM master and input devices for non-root users, and that "video" group membership is needed to use setuid bit in seatd-launch(1) or connect to seatd(1) socket?


xf86-video-nv is a very basic driver providing limited hardware support and 2D acceleration. Isn't x11/nvidia-driver the current driver for nvidia?

This revision now requires changes to proceed.Sun, Oct 10, 11:53 AM added inline comments.

What is "composite communications" exactly?


To be completely clear, nothing about the protocol requires evdev, but practically all compositors use evdev for input via libinput.


Yeah, nvidia doesn't have GBM yet (they're working on it).

Also "an Intel graphics card" (just one?) :/ better to say that it works "with drm-kmod open source drivers".


pam_ck_connector from ConsoleKit2 also manages XDG_RUNTIME_DIR. Though CK2 is maybe not worth mentioning due to it being abandoned in favor of its direct successor systemd-logind. The InitWare project includes a port of logind (but I'm not sure anyone has tried using it), and I might work on a custom logind implementation "soon" (lol).

Anyway ~/.config is a VERY odd choice for a manually configured runtime dir. It's not configuration, it's temporary stuff.


Really you should have tmpfs mounted on /var/run too, and then /var/run/user/$UID will be on a tmpfs.

This comment was removed by trhodes.

Me, thinking too many things at one time while typing and not fleshing out a sentence later.


I'm not sure why I didn't think of adding XWayland into the document. I remember thinking about it, and I probably thought I did a section and kept moving on with the other sections. I added a section for XWayland.


It seems more of a requirement for compositors. I know that if I disable it without a suitable replacement, everything goes boom. I tried to change it in the document as less of a Wayland requirement and more as a help to give access for users utility.


I was thinking the same thing, with the oddity on the runtime directory setting. When I was originally writing this, I just based the idea off of manual pages. Since I'm not the only one who thinks this, I've changed the run directory location and recommended to start the compositors with "-c configfile" to avoid issues.


I read the pkg-descr file, I'm not sure about the added configuration since we already have some stuff on using tmpfs and my recent changes should avoid this confusion.


I made a similar change, but didn't get too into the specifics.

trhodes marked 5 inline comments as done.

Updated diff (after pasting it in a follow up of course - duh).

Thanks for improving this diff. I'm not good at reviews, so please wait
for someone else to approve, but I added some nitpicks:


Maybe drop the last "access".


This may be improved by clarifying that they work with "Wayland on X11" nesting, so the reader would not get confused that there is a chance that cards using x11/nvidia-driver can work when a compositor was started via vt.


not -> no ?

One thing I would suggest is considering breaking the long lines into one sentence per line, as asciidoc recommended:

I almost forgot, this was not added in the newest revision: just starting seatd is not enough, a user is required to be a member of "video" group.

One thing I would suggest is considering breaking the long lines into one sentence per line, as asciidoc recommended:

This is good advice, I just finished cleaning this up and will post a new diff soon after this reply!

I almost forgot, this was not added in the newest revision: just starting seatd is not enough, a user is required to be a member of "video" group.

Hi! This is my fault, I keep forgetting about it because my test users are both in the video group for other projects. I've made this change before the seatd configuration in my new diff. I'm going to upload the diff in a minute, thank you for reminding me!

Tom, I see no problem with getting this in before the release, as the documentation distribution set is no longer included on the installer.

is the latest diff covering long line breaks (one sentence per line following the style), adding a user to the video group, and some extra stuff about Xwayland and debugging Xwayland based on my experience. There was also a change to lavalauncher to specify the method of launching to be the mouse instead of touch screen.