Trying to switch from Xorg to Xlibre on FreeBSD 15

V

VulcanRidr

Greetings,

I'm running into a couple of problems here. I cloned my current boot environment, and found that there are nvidia drivers compiled against xlibre. When I tried to install xlibre and the xlibre nvidia drivers, I got:

Code: 
# pkg install xlibre-server xlibre-nvidia-driver-580.126.18
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
Updating FreeBSD-ports-kmods repository catalogue...
FreeBSD-ports-kmods repository is up to date.
All repositories are up to date.
The following 3 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        seatd: 0.9.3 [FreeBSD-ports]
        xlibre-nvidia-driver: 580.126.18 [FreeBSD-ports]
        xlibre-server: 25.1.2_1 [FreeBSD-ports]

Number of packages to be installed: 3

The process will require 293 MiB more space.
79 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching xlibre-nvidia-driver-580.126.18:   0%   207 KiB 212.4 kB/s    06:26 [1/1] Fetching xlibre-nvidia-driver-580.126.18:  17%    14 MiB  14.3 MB/s    00:07 [1/1] Fetching xlibre-nvidia-driver-580.126.18:  57%    45 MiB  32.5 MB/s    00:01 [1/1] Fetching xlibre-nvidia-driver-580.126.18:  92%    73 MiB  29.5 MB/s    00:00 [1/1] Fetching xlibre-nvidia-driver-580.126.18: 100%    79 MiB  20.6 MB/s    00:04   
Checking integrity... done (2 conflicting)
  - xlibre-server-25.1.2_1 [FreeBSD-ports] conflicts with xorg-server-21.1.20,1 [installed] on /usr/local/bin/X
  - xlibre-nvidia-driver-580.126.18 [FreeBSD-ports] conflicts with nvidia-driver-580.126.18 [installed] on /usr/local/bin/nvidia-bug-report.sh
Checking integrity... done (0 conflicting)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
The following 10 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        seatd: 0.9.3 [FreeBSD-ports]
        xlibre-nvidia-driver: 580.126.18 [FreeBSD-ports]
        xlibre-server: 25.1.2_1 [FreeBSD-ports]

Installed packages to be REINSTALLED:
        pkg-2.6.2 [FreeBSD-ports]

Installed packages to be REMOVED:
        nvidia-driver: 580.126.18
        plasma6-plasma: 6.6.2
        plasma6-plasma-desktop: 6.6.2
        xf86-input-evdev: 2.10.6_8
        xf86-input-libinput: 1.3.0_1
        xorg-server: 21.1.20,1

Number of packages to be removed: 6
Number of packages to be installed: 3
Number of packages to be reinstalled: 1

The operation will free 39 MiB.

Proceed with this action? [y/N]: n

So since pkg is wanting to uninstall plasma6-plasma and plasma6-plasma-desktop, is this a "build from ports" problem (though I remember hearing mixing pkgs and ports can become bad juju), or a reinstall the plasma6 packages after xlibre is installed, or a deliberate sabotage by kde (since they are working toward wayland-only in 6.8)? Should I try SonicDE with Xlibre?

Thanks,
--vr
 
not sure why you'd want to switch from an implementation maintained by people who understand that ^ in C is not exponentiation to one whose maintainer has gotten this wrong more than once. do you just like running bad code?
 
atax1a said:
not sure why you'd want to switch from an implementation maintained by people who understand that ^ in C is not exponentiation to one whose maintainer has gotten this wrong more than once. do you just like running bad code?
Click to expand...
Less about that than redhate and the x foundation trying to make xorg go away and not responding to bug reports, in order to ram feature incomplete wayland down our collective throats.
 
VulcanRidr said:
Should I try SonicDE with Xlibre?
Click to expand...
I can vouch for Xfce working (not sure about NVIDIA)

Screenshot_2026-03-06_18-04-36.png
 
still don't see how switching to a codebase maintained by a guy who's confused XOR with pow() accomplishes anything other than increasing your exposure to bad code
 
atax1a said:
still don't see how switching to a codebase maintained by a guy who's confused XOR with pow() accomplishes anything other than increasing your exposure to bad code
Click to expand...
Both codebases have Enrico's code in. He has been a contributor for many, many years and his understanding of the architecture is probably better than anyone else. If there were more skilled developers around, he would step back from the code a little and focus on architecture. The lack of skilled developers in this field is also the reason why Wayland is failing on UNIX-like platforms.

And he can learn that XOR/pow are different. If we didn't care about people getting better at a skill, we would just have offloaded the work to AI.

But most importantly, Xlibre now has more active developers working on it than Xorg, Weston and wl_roots put together. If that isn't impressive in such a short time, I don't know what is.
 
shrug, our understanding from listening to other xorg devs is that enrico would consistently force-push broken code to the main branch, and, also, there's only one other place we hear the phrase "ramming [something] down our throats", so we're suspecting there might be something more here than technical merit
 
atax1a said:
shrug, our understanding from listening to other xorg devs is that enrico would consistently force-push broken code to the main branch, and, also, there's only one other place we hear the phrase "ramming [something] down our throats", so we're suspecting there might be something more here than technical merit
Click to expand...
I think they wanted to freeze Xorg whilst working on Linux Wayland. Enrico pushing new code obviously worked against their interests. Xlibre fork needed to happen for a well maintained and forward moving UNIX display system.

Open-source communities rarely understand the term "maintenance mode".
 
kpedersen said:
Open-source communities rarely understands the term "maintenance mode".
Click to expand...
The unsung heros of keeping the lights on. My opinion, maintenance is often more difficult than "new development". One needs to root cause a problem and then figure out a fix without breaking any existing uses. I've run into cases where bad behavior was used as a trigger and fixing the root cause would break that.
 
For x11/nvidia-driver:
pkg is attempting to install xlibre flavored one instead.
(I dislike the flavorization with it, though.)

For plasma6*:
The XLibre porters wanted to flavorize x11/plasma6-plasma-desktop for XLibre, but it was rejected by KDE porters (see PR 291602 for details). Would need waiting until forked version (maybe x11/xlibre-plasma6-plasma-desktop) is created and lands. Not sure there's any plan for it or not.

For evdev and libinput:
There are corresponding forked versions as x11-drivers/xlibre-xf86-input-evdev and x11-drivers/xlibre-xf86-input-libinput, but pkg doesn't pick them as alternatives for x11-drivers/xf86-input-evdev and x11-drivers/xf86-input-libinput automatically.

As seen above, there's quite important things to know before switching from Xorg to XLibre (on fresh install, situations would be better but not perfect like in plasma6 case). This is the reason I dislike current FLAVOR'ed implementation. Users who want to try XLibre should know what they're doing clearly. So using DEFAULT_VERSIONS way and force anyone who want to give XLibre a try to build things locally is far better solution. And once finished, need discussions, though, the default could be switched to XLibre.
 
Summarizing my previous post:
Do missed switches manually and switch from KDE / Plasma to anything others that doesn't need special fixing for Xlibre.

If you prefer KDE / Plasma, don't attempt to try XLibre until required things are done and lands (or do it yourself!) and stay with Xorg.
 
T-Aoki said:
Summarizing my previous post:
Do missed switches manually and switch from KDE / Plasma to anything others that doesn't need special fixing for Xlibre.

If you prefer KDE / Plasma, don't attempt to try XLibre until required things are done and lands (or do it yourself!) and stay with Xorg.
Click to expand...
This is exactly what I was looking for. I'm fine with waiting. Hell, last time I checked, the nvidia-xlibre drivers were not available...
 
atax1a said:
shrug, our understanding from listening to other xorg devs is that enrico would consistently force-push broken code to the main branch, and, also, there's only one other place we hear the phrase "ramming [something] down our throats", so we're suspecting there might be something more here than technical merit
Click to expand...
No, there is in fact not, and I resent your implication. Wayland is not even at feature parity with xorg, as far as I have read. Yet, the linux community is attempting to make it the default, mainly by attrition.

Please stop trying to turn my innocent question (and what I do with it on my own systems) into a political discussion. It is about freedom of choice. If I choose to go a different direction than you do on my own installations, I think that is my right and my choice to make...

And who is this "we" that suspects my untoward motives?
 
You must log in or register to reply here.
Back
Top