Porting X11Libre to FreeBSD.

kpedersen · Dec 26, 2025

baaz said:
seatd support is enabled by default, but I have added it as a port OPTION (SEATD) and you can disable it during builds if you want to. So yes it will take in sysutils/seatd by default.

Out of interest, what is seatd needed for in this X11 stack?

fmc000 · Dec 26, 2025

baaz said:
Most importantly, when ran as a normal user, it will use the ~/.local/share/xorg/Xorg.log folder for its logs.

That doesn't match my experience. When launched via a login manager such as dtlogin it runs as user nobody while still trying to write its logs in /var/logs, failing miserably of course unless I change the permissions to 777.

baaz · Dec 26, 2025

fmc000 said:
That doesn't match my experience. When launched via a login manager such as dtlogin it runs as user nobody while still trying to write its logs in /var/logs, failing miserably of course unless I change the permissions to 777.

Well that's because nobody's ~/ is /nonexistent hence no ~/.local/share/xorg/Xorg.log.

Try running X as your own user / another user that has a writable home. (You can create a user named _x11 )

A value of "local_uid" indicates that an Xserver should be
started for this entry under a specific user id. A user name
such as "root" must follow in next field. In the following
example, by placing "root" here, Xserver starts under the
user id of "root".

:0 Local local_uid@console root /usr/openwin/bin/Xsun :0

From dtlogin(1).

baaz · Dec 26, 2025

kpedersen said:
Out of interest, what is seatd needed for in this X11 stack?

Speaking in OpenBSD terms, it helps the X server fully drop its root privileges and stick to the principle of least privilege, like Xenocara.

Speaking in Linux terms, it basically does the task that systemd-logind and elogind do in relation to the X server without bringing in the gorilla and the jungle it is sitting in. (It can even user (e)logind as a backend)

In more technical terms, seatd, running as root, opens up DRM and input devices on behalf of its clients, the clients, now not needing to be root to do these tasks, can run as a normal, less privileged users.
Wayland wlroots based compositors have been the primary clients of seatd until now.

Additionally, seatd is a tiny C99 only deamon; its creator clearly states:

A seat management daemon, that does everything it needs to do. Nothing more, nothing less. Depends only on libc.

And just to be clear using seatd is fully optional, you can still run XLibre normally without seatd.

I think this mailing list thread between the creator and a user discussing the nature of seatd could also be helpful: https://lists.sr.ht/~kennylevinsen/seatd-devel/<3561460.kQq0lBPeGt@tycho>

fmc000 · Dec 26, 2025

baaz said:
Well that's because nobody's ~/ is /nonexistent hence no ~/.local/share/xorg/Xorg.log.

Try running X as your own user / another user that has a writable home. (You can create a user named _x11 )

From dtlogin(1).

Still doesn't work. I set the home directory for the user nobody to /home/nobody, created the structure /home/nobody/.local/share/xorg/Xorg.log/
(I tried also /home/nobody/.local/share/xorg/ )with the proper permissions and the server still tries to write the log in /var/log.

BTW, I am sure that the user nobody recognized its new home directory because it set up its cache there.

fmc000 · Dec 26, 2025

Solution:

Code:

[23:51][fmc000@dabrafenib ]$ tail -1 /usr/local/dt/config/Xservers                                                                                                                                              ~
   :0   Local local_uid@console nobody /usr/local/bin/X :0 -logfile /home/nobody/.local/share/xorg/Xorg.0.log -keeptty
[23:51][fmc000@dabrafenib ]$

baaz · Dec 27, 2025

fmc000 said:
Still doesn't work. I set the home directory for the user nobody to /home/nobody, created the structure /home/nobody/.local/share/xorg/Xorg.log/
(I tried also /home/nobody/.local/share/xorg/ )with the proper permissions and the server still tries to write the log in /var/log.

BTW, I am sure that the user nobody recognized its new home directory because he set up its cache there.

I do not think that it is a good idea to modify the nobody's default configuration, it is not supposed to have a home folder.
Just set the user in dtlogin to your own user, or create a dedicated X11 user named "_x11" like how OpenBSD does it. I have tested it in this way and there has not been any issues.

You don't need to create the folders. It will automatically create them if the permissions are correct.

baaz · Dec 27, 2025

Updates:

The XLibre ports in the main FreeBSD ports tree have also been updated to 25.1.0 thanks to AlonsoBSD!

We have three new ports!
x11-drivers/xlibre-xf86-video-scfb
x11-drivers/xlibre-xf86-input-egalax
x11/xlibre-minimal

The SCFB and eGalax drivers have been forked in the XLibre upstream so we have added new, dedicated, driver ports for them.

And now that we have x11-drivers/xlibre-xf86-video-scfb we were able to add the x11/xlibre-minimal meta port too.

Overall this means that we need 2 less FLAVORs, and with the changes I presupposed for the SLiM and Plasma Desktop ports, the only remaining ports requiring FLAVORization are the xorgxrdp* drivers (Still not acepted) and the NVIDIA drivers (acepted by the port's commiter).

fmc000 · Dec 27, 2025

baaz said:
I do not think that it is a good idea to modify the nobody's default configuration, it is not supposed to have a home folder.
Just set the user in dtlogin to your own user, or create a dedicated X11 user named "_x11" like how OpenBSD does it. I have tested it in this way and there has not been any issues.

You don't need to create the folders. It will automatically create them if the permissions are correct.

I agree about the user nobody default configuration, I rolled back the homedir to /nonexistent already. With that said, as I wrote before my experience WRT the logs is different from yours as unless I specify the -logfile switch XLibre always tries to write to /var/log, regardless of the user (i.e both nobody and my own user show the same problem).

Anyways, I solved my problem and that's good enough for me (I write the logs to /var/tmp instead of /var/log keeping the default user nobody - I don't see the point to create a new user just for this). Now I'm waiting for the updated packages to show up in the official ports to update and check again but I don't foresee any further issues.

kpedersen · Dec 27, 2025

baaz said:
it helps the X server fully drop its root privileges and stick to the principle of least privilege

Nice, I am a little out-of-date with FreeBSD's stack and didn't realize this was in place yet (or rather still used the Xorg.wrapper approach).

If this is Xlibre specific (i.e not in Xorg), then this is actually a good reason to switch.

fmc000 · Dec 27, 2025

kpedersen said:
Nice, I am a little out-of-date with FreeBSD's stack and didn't realize this was in place yet (or rather still used the Xorg.wrapper approach).

If this is Xlibre specific (i.e not in Xorg), then this is actually a good reason to switch.

FWIW, I switched because of this and of tearfree.

baaz · Dec 27, 2025

fmc000 said:
I agree about the user nobody default configuration, I rolled back the homedir to /nonexistent already. With that said, as I wrote before my experience WRT the logs is different from yours as unless I specify the -logfile switch XLibre always tries to write to /var/log, regardless of the user (i.e both nobody and my own user show the same problem).

Anyways, I solved my problem and that's good enough for me (I write the logs to /var/tmp instead of /var/log keeping the default user nobody - I don't see the point to create a new user just for this). Now I'm waiting for the updated packages to show up in the official ports to update and check again but I don't foresee any further issues.

I found out why this happens...

When dtlogin starts the X server, it starts it in a clear environment, and so the HOME variable is not set. The X server fails to find ~/ and resorts to /var/log which fails again due to insufficient privileges.

One may fix this by writing a tiny wrapper script that sets HOME before starting the X server, and pass that to dtlogins Xservers file.
But your solution also works.

baaz · Dec 27, 2025

kpedersen said:
Nice, I am a little out-of-date with FreeBSD's stack and didn't realize this was in place yet (or rather still used the Xorg.wrapper approach).

If this is Xlibre specific (i.e not in Xorg), then this is actually a good reason to switch.

Yes seatd support is exclusive to XLibre and Devuan's modified version of X.Org (That's where XLibre got the patches for this change).

rbranco · Dec 27, 2025

I tested MATE with XLibre + seatd and it works!

LenR · Sunday at 7:23 AM

I am seeing a crash on several apps (Firefox, ungoogled-chromium, xscreensaver) regularly. I think the common thread is that they have x11-toolkits/gtk3 but ultimately the crash is in graphics/mesa-libs with the 25.1.0 Xlibre-Server. Falling back to 25.0.0 for just the server will stop the crash. Occasionally, my system will panic or the display will go black when I start XLibre.
mesa-libs is version 24.1.7_1
Has anyone else seen this?

fmc000 · Sunday at 7:48 AM

I see absolutely no crashes at all, to me XLibre 25.1 is perfectly stable. I also have a bunch of apps that depends on gtk3:

gimp3
librewolf
xarchiver

and all work just fine. I suspect more a video driver issue as a system panic is something more "exotic" than just a crash. Which video card are you using and which video driver? In my case I have an integrated Intel Xe running i915kms as the kernel driver and modesetting as the XLibre userspace counterpart.

jmos · Sunday at 8:25 AM

LenR said:
Occasionally, my system will panic or the display will go black when I start XLibre.

I've compiled the ports yesterday and gave it a try. I'm getting a black screen, too. Something like a non-blinking white command line block cursor remains on the top left, and nothing responds: no mouse, no keystrokes. The only exit: The hardware power button. As this is no fun to debug I've switched back to x11/xorg-minimal. On my test environment (bhyve) everything worked (but there I didn't found x11-drivers/xlibre-xf86-video-scfb (yet?), so I've build a custom version of x11-drivers/xf86-video-scfb which does its job).

Side note: Palit GeForce RTX 3050 KalmX - I've got to use Nvidias 550.163.01 driver instead of the actual shipped with the ports/packages, otherwise I get a black screen with no response on X.org, too… So there might be a problem with the firmware modifications Palit does to get a RTX 3050 fanless.

LenR · Sunday at 6:36 PM

I have an ATI Radeon 6400 and I am using the amdgpu driver from the graphics/drm-kmod

Here is the output from pciconf -lv | grep -B4 VGA

Code:

vgapci0@pci0:7:0:0:     class=0x030000 rev=0xc7 hdr=0x00 vendor=0x1002 device=0x743f subvendor=0x1da2 subdevice=0xe458
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Navi 24 [Radeon RX 6400/6500 XT/6500M]'
    class      = display
    subclass   = VGA

Here is a snip from /var/log/Xorg.0.log

Code:

[2025-12-27 22:08:46] (II) xfree86: Adding drm device (/dev/dri/card0)
[2025-12-27 22:08:46] (II) Platform probe for /dev/dri/card0
[2025-12-27 22:08:46] (**) OutputClass "AMDgpu" ModulePath for driver amdgpu reset to default
[2025-12-27 22:08:46] (--) PCI:*(7@0:0:0) 1002:743f:1da2:e458 rev 199, Mem @ 0xd0000000/268435456, 0xe0000000/2097152, 0xfca00000/1048576, I/O @ 0xe000/256, BIOS @ 0x????????/65536
[2025-12-27 22:08:46] (II) LoadModule: "glx"
[2025-12-27 22:08:46] (II) Loading /usr/local/lib/xorg/modules/xlibre-25/extensions/libglx.so
[2025-12-27 22:08:46] (II) Module glx: vendor="X.Org Foundation"
[2025-12-27 22:08:46]   compiled for 1.25.1, module version = 1.0.0
[2025-12-27 22:08:46]   ABI class: X.Org Server Extension, version 11.0
[2025-12-27 22:08:46] (II) Applying OutputClass "AMDgpu" to /dev/dri/card0
[2025-12-27 22:08:46]   loading driver: amdgpu
[2025-12-27 22:08:46] (==) Matched amdgpu as autoconfigured driver 0
[2025-12-27 22:08:46] (==) Matched ati as autoconfigured driver 1
[2025-12-27 22:08:46] (==) Matched modesetting as autoconfigured driver 2
[2025-12-27 22:08:46] (==) Matched scfb as autoconfigured driver 3
[2025-12-27 22:08:46] (==) Matched vesa as autoconfigured driver 4
[2025-12-27 22:08:46] (==) Assigned the driver to the xf86ConfigLayout
[2025-12-27 22:08:46] (II) LoadModule: "amdgpu"
[2025-12-27 22:08:46] (II) Loading /usr/local/lib/xorg/modules/xlibre-25/drivers/amdgpu_drv.so
[2025-12-27 22:08:46] (II) Module amdgpu: vendor="X.Org Foundation"
[2025-12-27 22:08:46]   compiled for 1.25.1, module version = 25.0.1
[2025-12-27 22:08:46]   Module class: X.Org Video Driver
[2025-12-27 22:08:46]   ABI class: X.Org Video Driver, version 28.1
[2025-12-27 22:08:46] (II) LoadModule: "ati"
[2025-12-27 22:08:46] (WW) Warning, couldn't open module ati
[2025-12-27 22:08:46] (EE) Failed to load module "ati" (module does not exist, 0)
[2025-12-27 22:08:46] (II) LoadModule: "modesetting"
[2025-12-27 22:08:46] (II) Loading /usr/local/lib/xorg/modules/xlibre-25/drivers/modesetting_drv.so
[2025-12-27 22:08:46] (II) Module modesetting: vendor="X.Org Foundation"
[2025-12-27 22:08:46]   compiled for 1.25.1, module version = 1.25.1
[2025-12-27 22:08:46]   Module class: X.Org Video Driver
[2025-12-27 22:08:46]   ABI class: X.Org Video Driver, version 28.1
[2025-12-27 22:08:46] (II) LoadModule: "scfb"
[2025-12-27 22:08:46] (II) Loading /usr/local/lib/xorg/modules/xlibre-25/drivers/scfb_drv.so
[2025-12-27 22:08:46] (II) Module scfb: vendor="X.Org Foundation"
[2025-12-27 22:08:46]   compiled for 1.25.1, module version = 0.0.5
[2025-12-27 22:08:46]   ABI class: X.Org Video Driver, version 28.1
[2025-12-27 22:08:46] (II) LoadModule: "vesa"
[2025-12-27 22:08:46] (II) Loading /usr/local/lib/xorg/modules/xlibre-25/drivers/vesa_drv.so
[2025-12-27 22:08:46] (II) Module vesa: vendor="X.Org Foundation"
[2025-12-27 22:08:46]   compiled for 1.25.1, module version = 25.0.0
[2025-12-27 22:08:46]   Module class: X.Org Video Driver
[2025-12-27 22:08:46]   ABI class: X.Org Video Driver, version 28.1
[2025-12-27 22:08:46] (II) AMDGPU: Driver for AMD Radeon:
        All GPUs supported by the amdgpu kernel driver
[2025-12-27 22:08:46] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[2025-12-27 22:08:46] (II) scfb: driver for wsdisplay framebuffer: scfb
[2025-12-27 22:08:46] (II) VESA: driver for VESA chipsets: vesa
[2025-12-27 22:08:46] (--) Using pcvt driver
[2025-12-27 22:08:47] (II)  Platform device "/dev/dri/card0" at 0@7:0:0 can be claimed.
[2025-12-27 22:08:47] (II)  Platform device "/dev/dri/card0" skipped because
[2025-12-27 22:08:47] (II)   PCI bus id 0@7:0:0 has already been claimed by "Autoconfigured Video Device".
[2025-12-27 22:08:47] (II)  PCI device skipped because
[2025-12-27 22:08:47] (II)   PCI bus id 0@7:0:0 has already been claimed by "Autoconfigured Video Device".
[2025-12-27 22:08:47] (WW) Falling back to old probe method for modesetting
[2025-12-27 22:08:47] (II)  DRI device "/dev/dri/card0" has already been claimed by "Autoconfigured Video Device".
[2025-12-27 22:08:47] (WW) Falling back to old probe method for scfb
[2025-12-27 22:08:47] scfb trace: probe start
[2025-12-27 22:08:47] (II) "Autoconfigured Video Device scfb" can be claimed.
[2025-12-27 22:08:47] (II) scfb(1): using default device
[2025-12-27 22:08:47] scfb trace: probe done
[2025-12-27 22:08:47] (II)  PCI device skipped because
[2025-12-27 22:08:47] (II)   PCI bus id 0@7:0:0 has already been claimed by "Autoconfigured Video Device".
[2025-12-27 22:08:47] (II)  Platform device "/dev/dri/card0" skipped because
[2025-12-27 22:08:47] (II)   PCI bus id 0@7:0:0 has already been claimed by "Autoconfigured Video Device".
[2025-12-27 22:08:47] (II)  Platform device "/dev/dri/card0" skipped because
[2025-12-27 22:08:47] (II)   PCI bus id 0@7:0:0 has already been claimed by "Autoconfigured Video Device".
[2025-12-27 22:08:47] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support

And here is a backtrace from a firefox coredump:

Code:

#0  0x000011387cb81155 in ??? () at /usr/local/lib/libGLX_mesa.so.0
#1  0x000011387cb887ff in ??? () at /usr/local/lib/libGLX_mesa.so.0
#2  0x000011387cb859d4 in ??? () at /usr/local/lib/libGLX_mesa.so.0
#3  0x00001138523a73fe in epoxy_glx_version () at /usr/local/lib/libepoxy.so.0
#4  0x0000113848bb4451 in ??? () at /usr/local/lib/libgdk-3.so.0
#5  0x0000113848bb4777 in ??? () at /usr/local/lib/libgdk-3.so.0
#6  0x0000113848bbefca in ??? () at /usr/local/lib/libgdk-3.so.0
#7  0x0000113848bbab5d in ??? () at /usr/local/lib/libgdk-3.so.0
#8  0x0000113848bab577 in ??? () at /usr/local/lib/libgdk-3.so.0
#9  0x0000113848b77d7c in gdk_display_manager_open_display () at /usr/local/lib/libgdk-3.so.0
#10 0x000011386d421791 in XREMain::XRE_mainStartup(bool*) () at /usr/local/lib/firefox/libxul.so
#11 0x000011386d4264b1 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /usr/local/lib/firefox/libxul.so
#12 0x000011386d426aba in XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /usr/local/lib/firefox/libxul.so
#13 0x000011301dc8314c in main ()

baaz · Sunday at 6:52 PM

LenR said:
amdgpu

Do you really need some specific feature present in the xlibre-xf86-video-amdgpu driver that is not present on modesetting?

If you just have installed it out of habit from X.Org I suggest you remove that driver and try the default modesetting driver included in XLibre.

A glxinfo log would also be nice.

baaz · Sunday at 7:01 PM

jmos said:
I've compiled the ports yesterday and gave it a try. I'm getting a black screen, too. Something like a non-blinking white command line block cursor remains on the top left, and nothing responds: no mouse, no keystrokes. The only exit: The hardware power button. As this is no fun to debug I've switched back to x11/xorg-minimal. On my test environment (bhyve) everything worked (but there I didn't found x11-drivers/xlibre-xf86-video-scfb (yet?), so I've build a custom version of x11-drivers/xf86-video-scfb which does its job).

Side note: Palit GeForce RTX 3050 KalmX - I've got to use Nvidias 550.163.01 driver instead of the actual shipped with the ports/packages, otherwise I get a black screen with no response on X.org, too… So there might be a problem with the firmware modifications Palit does to get a RTX 3050 fanless.

I suspect you tried out XLibre server with a version less than 20.0.0.18, and forgot to pass in IgnoreABI for the NVIDIA drivers, (This is not required now in the later versions).
x11-drivers/xlibre-xf86-video-scfb has just been added to the ports tree so if your ports are not updated, it would not be available too.

But any further diagnosis requires logs, and the version of the XLibre server + installed drivers.

jmos · Sunday at 7:31 PM

baaz said:
I suspect you tried out XLibre server with a version less than 20.0.0.18

ls /usr/ports/distfiles/xlibre/server/ says it was X11Libre-xserver-25.1.0-xlibre-xserver-25.1.0_GH0.tar.gz.

baaz said:
But any further diagnosis requires logs

Didn't tell me anything - not a single error entry (and since the error logs are difficult to access when the system is no longer responsive - and in my case switching between the working setup and x11libre also requires "a little attention" - I'm not going to spend more time on it for now).

baaz · Sunday at 8:24 PM

jmos said:
and since the error logs are difficult to access when the system is no longer responsive

Just FYI the X server logs are stored in /var/log/ so even if a session crashes they are still available.
I understand that testing again could be difficult

.

Another tip for configuring any X server is to set up a method for killing the X server in case things go south. You can start a timer in a TTY like:

sh:

sleep 30; pkill -9 X

And stop it if things are OK and you can switch back the TTY.
Or you could setup SSH and login into the machine with another device.

LenR · Sunday at 9:55 PM

baaz said:
Do you really need some specific feature present in the xlibre-xf86-video-amdgpu driver that is not present on modesetting?

If you just have installed it out of habit from X.Org I suggest you remove that driver and try the default modesetting driver included in XLibre.

A glxinfo log would also be nice.

No, I didn't have a good reason to include it other than I was running an AMD GPU. I removed it, and everything is working again. I figured I was doing something wrong but had no idea what it was.

Oddly enough, before I removed the xlibre-xf86-video-amdpgu glxinfo would also segfault. But it hardly matters because I'm running.

Thank you very much for everyone's help and attention!

elgrande · Tuesday at 12:57 PM

So as far as I understand it, we need to compile x11/plasma6-plasma-desktop manually, since the X11 option is on per default, right?

baaz · Tuesday at 8:05 PM

elgrande said:
So as far as I understand it, we need to compile x11/plasma6-plasma-desktop manually, since the X11 option is on per default, right?

Sadly yes.
The commit that added that "X11" option referenced the closed XLibre PR, but it failed to actually fix the underlying problem causing the conflict (the default RUN_TIME dependency on xf86- drivers).

I've commented on the thread:

Making sure you're not a bot!

There has not been any response yet.

In the meantime. the modded plasma6-plasma-desktop found in my overlay could be used:

xlibre-ports/x11/plasma6-plasma-desktop at master · b-aaz/xlibre-ports

An effort for porting XLibre to FreeBSD & DragonFlyBSD. - b-aaz/xlibre-ports

github.com

I have fixed its CI build so it is also available in the artifact repository:

XLibre binaries for FreeBSD 15 amd64