Porting X11Libre to FreeBSD.

baaz

baaz

This was a topic that I felt needed it's own thread.
You've probably heard of X11Libre, and its backstory till now.
My position on the topic is that we need a well maintained X11 server with good security features, And That's X11Libre.
I want this thread to be a place dedicated to technicalities of porting this new project, for other discussions we can use the other thread;).

So I have started working on porting X11Libre to FreeBSD few days ago.
Here is my GitHub repository.
The root of this repository is like a mini ports tree. You can do most of the things that you can with make on the main ports tree in here too.

A TL;DR of the progress made:

XLibre had may changes done to it compared to the version of the X.Org that is currently in the ports, most of the changes were in the X server.
That means there are many changes that need to be tested, especially on FreeBSD.

So if you want to contribute I think the best thing that you can do, is to run XLibre and report problems, to me or the related repository on X11Libre, depending on the origin of the issue (After checking for similar cases of course!).
Testing is really needed on "uncommon" hardware and software configurations, things like old NVIDIA hardware, old server onboard GPUs, old Wacom tablets, uncommon configs and workflows and ... .

For installation details, please refer to the README of my repository.
I'm gonna repeat the warnings form the README here too:

Be aware that these packages are still in beta stage, both the ports and the upstream sources.They:
  • may not work as expected
  • may overwrite files
  • make unicorns come out of your nose
  • or anything in between.
So, please make sure that you understand what you are doing.
It is recommended that you have some ports and pkg knowledge before installing.
I also suggest running and building these ports in a jail, VM or test machine not your main box.
Click to expand...
 
I've tried XLibre on different setups on both Linux and FreeBSD, there's light and shadow:
  • Intel GPU like 620 works fine without issues as far as I can tell
  • Nvidia 575 works fine as well
  • Nvidia 470 had issues with a segfault on start, but the cause has been found
  • Nvidia 390 is unusable atm
  • Nvidia has issues when going back to console from X on BSD (though this seems to be linked to one specific PC on my end)
 
Very cool. I look forward to going through the build shortly.

I am guessing that Xorg and Xlibre won't be able to be installed at the same time. Could this potentially be the time to encapsulate / isolate Xlibre into i.e: /usr/local/X11R7 before it becomes too entrenched within the existing ports collection?
 
kpedersen said:
I am guessing that Xorg and Xlibre won't be able to be installed at the same time. Could this potentially be the time to encapsulate / isolate Xlibre into i.e: /usr/local/X11R7 before it becomes too entrenched within the existing ports collection?
Click to expand...
Sorry for my ignorance but which xorg port does install something into x11r7 directory? Xorg-server port doesn't seem to install anything under that directory. Or is it coming from base system? I saw that directory only on openbsd.
 
kpedersen said:
Very cool. I look forward to going through the build shortly.

I am guessing that Xorg and Xlibre won't be able to be installed at the same time. Could this potentially be the time to encapsulate / isolate Xlibre into i.e: /usr/local/X11R7 before it becomes too entrenched within the existing ports collection?
Click to expand...
Yes, you guessed right everything conflicts, including the drivers.
I like how NetBSD and OpenBSD separate the X11 files into their neat folders.
One thing that is different between us and OpenBSD and NetBSD is that they provide the X11 files as a set, here it's a collection of different ports.
Also XLibre only forked the server and the drivers, the other "categories" and their ports are not included here, This can also cause conflicts from different ports expecting stuff to be in different places, and writing things to different places.
I'm gonna try things out with the PREFIX, but I think this will have a lot of "collateral damage" in unexpected ways ... .
But it's worth the try.
 
I'm thinking about if FLAVORs are a good choice for the X server, Xephyr, Xnest and Xvfb or they should be turned into separated ports.

In my experience they make the build process, the CI file and the Makefile messy. And that also makes them harder to test.
Also these programs provide different features, different files, have different dependencies and are used for a different tasks.

But on the other hand, all of them compile form a single code-base, and share some flags in common.

What do you think?
 
UPDATE:
XLibre Xserver minor release 25.0.0.4, is now in the ports (sending this from it!).
Bumped the drivers to their latest commits, and everything complies.

On separating the flavors into ports:
I've looked at how it was done before (2022Q3), when they were separate ports, thought a bunch on it and I think the best solution is to add to xlibre-cat.mk (previously xorg-cat.mk), a "server" category and set the common things form there. Then separate each 4 to different ports with each one including xorg-cat:server.
With no SLAVE_PORT complecting things! I'm still happy to hear comments on this.
xlibre-cat already sets the upstream of all of the drivers, now it will do it with the servers too.
 
I have been following but remained quiet so far because I think my bias is quite obvious. xlibre-server, xorg-apps, xorg-fonts, xlibre-drivers, xorg-utils should just be one monolithic package.

But.... I appreciate that is not how the port is going to be best received by the project ;)

I think your choice is fair. I guess if people do want the full Xlibre distribution then an xlibre meta-port could then pull them all in (servers and auxiliary) just like the existing xorg port.

Have there been any groans from the maintainers of the existing Xorg port? Perhaps this is an opportunity to simplify and sidestep any issues that would have caused breaking changes with xorg.
 
kpedersen said:
I have been following but remained quiet so far because I think my bias is quite obvious. xlibre-server, xorg-apps, xorg-fonts, xlibre-drivers, xorg-utils should just be one monolithic package.

But.... I appreciate that is not how the port is going to be best received by the project ;)

I think your choice is fair. I guess if people do want the full Xlibre distribution then an xlibre meta-port could then pull them all in (servers and auxiliary) just like the existing xorg port.

Have there been any groans from the maintainers of the existing Xorg port? Perhaps this is an opportunity to simplify and sidestep any issues that would have caused breaking changes with xorg.
Click to expand...
TBH, I have the same bias, I would love "X11 suff" as a set as in the other BSDs.
But again it is not how things are currently structured in FreeBSD, and I chose to keep things as close to the way they were to ease adoption.
But there can be work done on making the current ports have a toggle, maybe with PREFIX, maybe with a new toggle like X11_PREFIX, to then make them get installed to a separate neat location.
There are a few design choices to it, like: would the X11R*/ include the share/ files like in OpenBSD or not like in NetBSD? Would there be a X11R*/libexec just for a single binary Xorg?
It needs some discussion.

I haven't contacted the x11 maintainers and I haven't heard form them, but if they are on the forums they can feel free to join in!
 
Well, as you're in a very early stage I believe you can still change things and make everything monolithic. Maybe it can be done, maybe not but I think it may be worth trying before it eventually becomes too widespread.
 
baaz Thanks for undertaking this porting effort. As a FreeBSD user who likes to, "Install ALL the desktops" I see both Wayland and X in my future and would like access to any actively-maintained X server (and don't know which will be better maintained long-term).

How specifically would things need to be arranged for FreeBSD users to have an easy choice of installing XOrg, XLibre, or even better both in parallel as they have different technical visions?

XOrg seems to be attempting to preserve X11 as a static fallback target for when Wayland ports of applications aren't available whereas XLibre believes X can and should be modernized while still mostly preserving backwards compatibility. This means XOrg may be a more stable platform for running legacy code while XLibre will likely be the server of choice for people wanting new security extensions and support for features of newer display hardware.
 
Uityyy said:
baaz Thanks for undertaking this porting effort. As a FreeBSD user who likes to, "Install ALL the desktops" I see both Wayland and X in my future and would like access to any actively-maintained X server (and don't know which will be better maintained long-term).

How specifically would things need to be arranged for FreeBSD users to have an easy choice of installing XOrg, XLibre, or even better both in parallel as they have different technical visions?

XOrg seems to be attempting to preserve X11 as a static fallback target for when Wayland ports of applications aren't available whereas XLibre believes X can and should be modernized while still mostly preserving backwards compatibility. This means XOrg may be a more stable platform for running legacy code while XLibre will likely be the server of choice for people wanting new security extensions and support for features of newer display hardware.
Click to expand...

Welcome!
Depends on what you mean by easy ... .
If by easy you mean just being able to run
Code: 
pkg install xlibre-server
on a new install,
That will take sometime, both this port and the upstream need to get "stabilized" and the rough edges get rounded, then there could be a proposal for merger to the main ports tree and after that process the package will end up in the next build of the ports, whenever that lands. TL;DR it will take a long of time.

And for being able to install them side by side, it is possible to achieve but it needs a lot of effort for little gain, at the cost of making everything messy, except if we go the separated folder/set for "X11 stuff" route.

You can add our CI pkg repos and then install the packages as you normally would with pkg.
Or you can manually build form the mini ports tree in my repo.
Instructions to both are available in the README.
If you want to install them now, please read the warning after the instructions at the end of the README.
 
UPDATE:

on the "X11R*" set/separate folder issue:

I have managed to get my ports building with a different PREFIX (/tmp/X11) and everything actually gets installed.

Bugs and hurdles I've encountered:

* LOCALBASE....
* PKG_CONF_PATH.
* xorg-macros needs to be installed in the PREFIX directory too.
* xorg.mk using LOCALBASE for locating all of the X.Org .pc files which leads to xorg-macros not being found.
* aclocal needs to find the xorg macros in the PREFIX/share/aclocal directory.

The top 3 ones were solved with a bunch of temperory solutions hacks.

I could not fix the last one exept for setting ACLOCAL_PATH in the environment while runnig make, setting it in MAKE_ENV WRK_ENV CONFIGURE_ENV does not work, And there seams to be no way to give it as a arg directly to autoreconf, GNU AutoHells ... . Any help on this is apreciated.

The xserver is the only thing that compiles fine with no change, thanks to meson.

I may create a x11set branch on the repo for testing this thing out more.

In reality to make this actualy work all the other X11/X.Org categories and their ports need to get into the PREFIX location too.
 
baaz said:
UPDATE:

on the "X11R*" set/separate folder issue:

I have managed to get my ports building with a different PREFIX (/tmp/X11) and everything actually gets installed.

Bugs and hurdles I've encountered:

* LOCALBASE....
* PKG_CONF_PATH.
* xorg-macros needs to be installed in the PREFIX directory too.
* xorg.mk using LOCALBASE for locating all of the X.Org .pc files which leads to xorg-macros not being found.
* aclocal needs to find the xorg macros in the PREFIX/share/aclocal directory.

The top 3 ones were solved with a bunch of temperory solutions hacks.

I could not fix the last one exept for setting ACLOCAL_PATH in the environment while runnig make, setting it in MAKE_ENV WRK_ENV CONFIGURE_ENV does not work, And there seams to be no way to give it as a arg directly to autoreconf, GNU AutoHells ... . Any help on this is apreciated.

The xserver is the only thing that compiles fine with no change, thanks to meson.

I may create a x11set branch on the repo for testing this thing out more.

In reality to make this actualy work all the other X11/X.Org categories and their ports need to get into the PREFIX location too.
Click to expand...

Oh and something I forgot is etc/.
The etc/ directory containing the X11 configs ends up in PREFIX/etc, it should be transferred to /etc/X11R*.
 
baaz said:
This was a topic that I felt needed it's own thread.
You've probably heard of X11Libre, and its backstory till now.
My position on the topic is that we need a well maintained X11 server with good security features, And That's X11Libre.
Click to expand...
I do agree about the need for a well maintained X11 server, however I disagree with Xlibre already being that. And since the other thread is gone... stuff like this belongs to here I guess.

For being a well maintained X11 server Xlibre still lacks:

* an active community of good developers behind it. At the moment it's more or less a one man show.
* a plan how the project should be organized, should be governed and what its main goals are
* visibility on the web. Having a Github repository and mailing list is a start, but not enough.
* a certain track record of releasing new versions over time.

It's a potential starting point, nothing more nothing less.
 
hardworkingnewbie said:
* an active community of good developers behind it. At the moment it's more or less a one man show.
Click to expand...
Looking in the commits there is about 4 guys since July:
  • metux
  • stefan1111
  • NathanKidd-Rocket
  • dasha-uwu
Thats more than Xorg and most Wayland compositors.
hardworkingnewbie said:
* a plan how the project should be organized, should be governed and what its main goals are
* visibility on the web. Having a Github repository and mailing list is a start, but not enough.
* a certain track record of releasing new versions over time.
Click to expand...
Remember that Wayland had 12 years to still barely make a dent. Xlibre got 3.1k stars in a couple of weeks and a very active issue tracker. Again, this is more engagement than most Wayland compositors combined.

hardworkingnewbie said:
It's a potential starting point, nothing more nothing less.
Click to expand...
Starting on a display system successor for Linux/UNIX is a big task. Its never really been done before so lets see how it goes. I'm sure there will be hiccups along the way.
 
hardworkingnewbie said:
For being a well maintained X11 server Xlibre still lacks:

* an active community of good developers behind it. At the moment it's more or less a one man show.
* a plan how the project should be organized, should be governed and what its main goals are
* visibility on the web. Having a Github repository and mailing list is a start, but not enough.
* a certain track record of releasing new versions over time.
Click to expand...

Cart before the horse way of thinking. Code is a prerequisite to all of this.

hardworkingnewbie said:
It's a potential starting point, nothing more nothing less.
Click to expand...

This statement alone contradicts the rest your post. Forking a display server is not some mundane task.
 
You must log in or register to reply here.
Back
Top