Porting X11Libre to FreeBSD.

Going a bit off-topic and daydreaming here:

I've been thinking about the possibility of adding some capsicum(4) to XLibre's ingredient list.

It is a hard task to do, and I'm currently busy enough with the ports and other stuff, but it is certainly a possibility, and if actualized would be tremendous for the security of X.
Moreover, with seatd in place there is now a whole new set of possibilities open for capsicum and it's file descriptor limits in there too.

So if a capsicum wizard is out there with some knowledge about the X server internals, and is willing to help the project it would be great.
First step that needs to be done is to centralize the open()(1) calls in DDX into the server with a exported wrapper function to then control in a more fine grain manor...
 
Hello world :-) Just switched to XLibre on FreeBSD :-) All works fine, maybe more responsive, big thank you for the port! :-)

I tested some games and they fail to start as opposed to xorg, I have reported it to theupstream https://github.com/X11Libre/xserver/issues/1922.

Aside from that all works fine and stable with nvidia-driver-devel - enlightenment wm, firefox, gimp (menu does not flicker as in xorg), inkscape, kicad, freecad, virtualbox, bambustudio under linuxlator with nvidia gpu acceleration, etc :-)
 
cederom said:
Hello world :-) Just switched to XLibre on FreeBSD :-) All works fine, maybe more responsive, big thank you for the port! :-)

I tested some games and they fail to start as opposed to xorg, I have reported it to theupstream https://github.com/X11Libre/xserver/issues/1922.

Aside from that all works fine and stable with nvidia-driver-devel - enlightenment wm, firefox, gimp (menu does not flicker as in xorg), inkscape, kicad, freecad, virtualbox, bambustudio under linuxlator with nvidia gpu acceleration, etc :-)
Click to expand...
I'm interested in switching too. Can you drop your two cents about what you had to do? I haven't started to look into it, so any hint will be appreciated.
 
AlfredoLlaquet said:
I'm interested in switching too. Can you drop your two cents about what you had to do? I haven't started to look into it, so any hint will be appreciated.
Click to expand...

Just #pkg install xlibre (it will deinstall xorg parts for you) and then reinstall nvidia-driver-devel with xlibre flavor :) This is the only part that seems to change:

Code: 
xlibre-0.1
xlibre-drivers-1.0
xlibre-nvidia-driver-devel-590.48.01
xlibre-server-25.1.0
xlibre-slim-1.3.6_26
xlibre-xf86-input-keyboard-25.0.0
xlibre-xf86-input-libinput-25.0.0
xlibre-xf86-input-mouse-25.0.0
xlibre-xf86-video-scfb-25.0.0
xlibre-xf86-video-vesa-25.0.0

If you are using SLIM as login manager the update seems on the way but you can easily update it to have xlibre flavor https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291597 :-)
 
Another Xlibre success story, by new forum user mickypoo.

mickypoo

Post in thread 'Introduce yourself, tell us who you are and why you chose FreeBSD'

AlfredoLlaquet said:
I encourage you to use the forum. It's usually good help.
Click to expand...
Thanks for the encouragement! Definitely will shortly. Ditched the Ryzen system - keeping for Windows/gaming only. But repurposed an old HP Elitedesk 800 G2 today as my TV's more energy efficient HTPC/sofa PC, with a second monitor going to the nearby desk for daily driver use. Wireless kb/m, I can take to the sofa or desk! Has worked out so well. Managed to install Xlibre with a MATE desktop.

One issue with sound over HDMI/DP adapter, but that will be on the forum soon. I'm generally finding FreeBSD so much easier to...
  • Like
 
I have a partial success story. While XLibre works fine for desktop work, browsing and what not, I have segmentation faults and issues creating dri3 contexts while launching linux native games and from the compat/linux container glxinfo only lists llvmpipe (which works fine for older titles but obviously fails for newer stuff).
So I had to revert back to Xorg.
 
Didn't try it yet. Where does it conflict with any Xorg installation if they aren't running at the same time? Does a kernel module has to be unloaded? Or does it go beyond a point of no return because a part of the loading can't be undone? If it needs different libraries, isn't that just a matter of separating program directories?

Now trying to get it running in modular approach. Adding the packages that make-run-depends-list shows to an image. See if I need anything else. It should start from vt with no graphics?

update: while trying to complete all lib dependencies:
Xorg log: failed to load /usr/local/lib/xorg/modules/xlibre-25.0/extensions/libGL.so.1: not found, required by libglx.so. This is a file of xorg-server. We still need that too? This happens on a system with Intel HD 530 graphics.
 
Just wanted to share my thoughts about the 'state' of porting XLibre to FreeBSD - for me - worked like a charm.

I tried XLibre recently when I tried to use as less RAM as possible with some still fully functional and nice looking GUI - https://vermaden.wordpress.com/2026/01/18/200-mb-ram-freebsd-desktop/ - and everything installed and worked well from official FreeBSD pkg(8) repositories. No additional hassle. No custom configs. Just worked. Really appreciated.

minimal-ram-desktop.png
 
Espionage724 said:
If people are manipulated to a particular view that's not beneficial for technical code, that seems an issue.

If X11Libre was faster than Xorg, any OS that doesn't have it for reasons other than someone not packaging it yet, it'll be an arms race for me to see what OS is serious enough to use (FreeBSD's the first I've seen semi-interested). I like performance :p

I'm certain every contributor to open-source has something in their past that could be blown-up today to make them seem bad, which makes little sense considering the code done was usable and probably good before the media frenzy. I'm still not convinced code can be discriminatory, so what would other people have against contributing to code? Or, if Wayland was as good as people claimed it to be for at least 8 years, why would this be a discussion now?
Click to expand...
X11Libre isn't about being "faster than Xorg." It is more likely an actively maintained archive of X11 that we are used to and like.

in my understanding

Tango&Cash(1989) said:
Yes, quick and easy is how you make a cake.
Or clean a toilet bowl, or shop...
...by mail.
But quick and easy is not how you run
a multimillion-dollar business such as ours.
Click to expand...
Speed is not necessarily an indicator of quality :P
 
Espionage724 said:
Sure, but XLibre has to match or be faster than current-Xorg or else why bother? :p (Wayland could also be option not considering performance)
Click to expand...
Still waiting for any UI-base that does fast 2d framebuffer scaling. (not like xrandr) GPU manufacturers don't like that accessibility and avoid direct addressing because it makes modern graphics applications run fast enough on outdated hardware. Smartphones are even worse. An app that can't zoom in at all is technically pathetic.
 
MG said:
Still waiting for any UI-base that does fast 2d framebuffer scaling. (not like xrandr) GPU manufacturers don't like that accessibility and avoid direct addressing because it makes modern graphics applications run fast enough on outdated hardware. Smartphones are even worse. An app that can't zoom in at all is technically pathetic.
Click to expand...
Does this, especially the moderator's response, possibly help if you're using nvidia GPU?

If I understand correctly, this method mimics X11 to be using small screen, then, GPU stretches the small screen into actual screen resolution (basically the feature is for quite heavy 3D gamings).

Hope other manufacturers have something alike.
 
Espionage724 said:
Sure, but XLibre has to match or be faster than current-Xorg or else why bother? :p (Wayland could also be option not considering performance)
Click to expand...
For a network aware display system, stability, bandwidth and flexibility could be considered more important than performance. Otherwise 90's DOS-style direct framebuffer access via Wayland compositors is fastest.
 
T-Aoki said:
Does this, especially the moderator's response, possibly help if you're using nvidia GPU?

If I understand correctly, this method mimics X11 to be using small screen, then, GPU stretches the small screen into actual screen resolution (basically the feature is for quite heavy 3D gamings).

Hope other manufacturers have something alike.
Click to expand...
It doesn't make much sense. You can play a fullscreen video or display animated rendered graphics but a 2-dimensional UI zooming in to a part of the screen is a problem. I'm not buying that. I think we have to lose accellerators because they are actually limiting graphics capabilities. ALU-based graphics is probably already ahead of this but it's kept up for MS and Steam.
 
MG said:
It doesn't make much sense. You can play a fullscreen video or display animated rendered graphics but a 2-dimensional UI zooming in to a part of the screen is a problem. I'm not buying that. I think we have to lose accellerators because they are actually limiting graphics capabilities. ALU-based graphics is probably already ahead of this but it's kept up for MS and Steam.
Click to expand...
Do you mean "zooming UI parts like buttons alone" is what you want?
If so, it would be the responsibilities of theme engines / themes, not at all of drivers nor X11 servers / Wayland compositors.

Or do you want something like this huge lupe? (Mag plugin of x11-wm/compiz, which acts as a huge mouse pointer with magnification)
Screenshot_2026-02-05_02-39-57.png
 
What I mean is that graphical user interfaces should be able to resize, scale, move or any other adjustment without it taking time, like any other graphical application.
Try to change the scale of the entire screen of the Xorg-server. You can't miss the problem. It should not exist. We're only looking at 1 application called desktop and 2d graphical processing doesn't take visible time on any reasonable system.
 
Qtwosix said:
Apologies if this is a stupid question, but, what is the advantage of using Xlibre compared to Xorg? What are the functionaltiy differences?
Click to expand...
Basic functionality, probably not much.
But it's a fork of Xorg that is being actively maintained with an eye to advancing the X parts and keeping "X" alive (X tracing back to original X Windows from MIT I believe, then XFree86, then Xorg).
 
cederom said:
Just #pkg install xlibre (it will deinstall xorg parts for you) and then reinstall nvidia-driver-devel with xlibre flavor :) This is the only part that seems to change:

Code: 
xlibre-0.1
xlibre-drivers-1.0
xlibre-nvidia-driver-devel-590.48.01
xlibre-server-25.1.0
xlibre-slim-1.3.6_26
xlibre-xf86-input-keyboard-25.0.0
xlibre-xf86-input-libinput-25.0.0
xlibre-xf86-input-mouse-25.0.0
xlibre-xf86-video-scfb-25.0.0
xlibre-xf86-video-vesa-25.0.0

If you are using SLIM as login manager the update seems on the way but you can easily update it to have xlibre flavor https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291597 :-)
Click to expand...
Have you managed or heard of someone who managed to get xlibre going on VirtualBox?
I tried pkg install. I tried ports overlay method and the CI artifacts method. I tried million things Gemini suggested. And it seems the vbox driver (fairly new from last week) does not stick. Hopefully it just needs some special tinkering with VirtualBox HW settings and some magic in .conf files but the combinations for a noob like me are too many.
Please and Thank You
 
DanielBowman said:
Have you managed or heard of someone who managed to get xlibre going on VirtualBox?
I tried pkg install. I tried ports overlay method and the CI artifacts method. I tried million things Gemini suggested. And it seems the vbox driver (fairly new from last week) does not stick. Hopefully it just needs some special tinkering with VirtualBox HW settings and some magic in .conf files but the combinations for a noob like me are too many.
Please and Thank You
Click to expand...
I have been working on the issue.

The problem is that the virtualbox-ose-additions-72 port had went completely over my radar when first porting XLibre. (I have rarely used VBox. BHyve has been sufficient for me)

This port provides 2 drivers for the X server and they are compiled against the X.Org X server instead of XLibre, this causes it to have the X.Org SDK's ABI number and not load on XLIbre.

I'm currently working on the port and trying to add a XLibre flavor to it. I have actually managed to add the XLibre flavor, but the port refuses to build when put in a overlay (but works fine in the main ports tree), it is a weird bug and the port uses a wierd build system. TLDR is that I haven't managed to make the port behave yet. (Help is appreiated from anyone who knows "kBuild")

Till that is fixed there are two options for making XLibre work in VBox:

A. Use the SCFB video deriver and the libinput input driver instead of the VBox drivers.
B. Make XLibre ignore driver ABIs by adding a file containing this to your X configuration directory:


Code: 
Section "ServerFlags"
    Option         "IgnoreABI" "True"
EndSection
 
You must log in or register to reply here.
Back
Top