Using Xlibre with MHWD - Error

Support AUR
1

I recently resurrected my son’s old Gateway QWTN156-2BK, with an NVIDIA GeForceGTX 1650. This an AMD Ryzen 5 4600H with on board Graphics as well.

Windows 11 had become unusable, so he said to throw Linux on it and see how well it works. Since, It is the only Nvidia machine we have, it was perfect.

I of course installed DeLinuxCo and it all worked perfectly, sans the keyboard RGB lights, but I believe this can be addressed at some point.

The issue is with installing the Nvidia drivers, when I tried to run manjaro-settings-manager, I get the following errror:

Starting
> Using config 'video-hybrid-amd-nvidia-prime' for device: 0000:01:00.0 (0300:10de:1f99) Display controller nVidia Corporation TU117M [GeForce GTX 1650 Mobile / Max-Q]
> Using config 'video-hybrid-amd-nvidia-prime' for device: 0000:06:00.0 (0300:1002:1636) Display controller ATI Technologies Inc Renoir [Radeon Vega Series / Radeon Vega Mobile Series]
> Dependencies to install:  video-linux
> Installing dependency video-linux...
Sourcing /etc/mhwd-x86_64.conf
Has lib32 support: true
Sourcing /var/lib/mhwd/db/pci/graphic_drivers/video-linux/MHWDCONFIG
Processing classid: 0300
Sourcing /var/lib/mhwd/scripts/include/0300
Processing classid: 0380
Processing classid: 0302
:: Synchronizing package databases...
 core downloading...
 extra downloading...
 multilib downloading...
 delinuxco downloading...
 xlibre downloading...
warning: vulkan-intel-1:26.2.2-1 is up to date -- skipping
warning: vulkan-nouveau-1:26.2.2-1 is up to date -- skipping
warning: vulkan-radeon-1:26.2.2-1 is up to date -- skipping
warning: lib32-vulkan-intel-1:26.2.2-1 is up to date -- skipping
warning: lib32-vulkan-nouveau-1:26.2.2-1 is up to date -- skipping
warning: lib32-vulkan-radeon-1:26.2.2-1 is up to date -- skipping
resolving dependencies...
looking for conflicting packages...
:: xf86-video-ati-1:22.0.0-3 and xlibre-xserver-25.1.8-3 are in conflict (X-ABI-VIDEODRV_VERSION). Remove xlibre-xserver? [y/N] error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)

:: xf86-video-ati-1:22.0.0-3 and xlibre-xserver-25.1.8-3 are in conflict (X-ABI-VIDEODRV_VERSION>=26)
Error: pacman failed!
Error: script failed!

Clearly it is because Xlibre is installed instead of X.org, so I am trying to understand if this is something that I need to report to Xlibre and have them add “xf86-video-ati” as a “provides” entry in the package build, or is there some other alternative?

Now, I did get the driver installed and it works well, even OBS as an AppImage, picked up the hvec driver by default. My son tried SteamOS and it ran some driving game at 40FPS and he said it was smoother than Windows.

To get the card working, I installed the following.

Install your kernel headers for each kernel installed ( linux72-headers linux618-headers etc)
Install nvidia-dkms
Install nvidia & nvidia-prime
Install switcheroo-control

Then enable and start the switcheroo-control service by running sudo systemctl enable --now switcheroo-control In Cinnamon, this will enable the right click on an app and “Run with dedicated GPU”.

Reboot.

2

xf86-video-ati conflicts with X-ABI-VIDEODRV_VERSION>=26 which apparently xlibre-server provides a matching newer version. xorg-server provides X-ABI-VIDEODRV_VERSION=25.2, so there are no issues.

The video-linux MHWD profile depends on xf86-video-ati, but unless you have a very old card, it’s not needed. Radeon RX Vega 6 graphics would use amdgpu and wouldn’t need it. I’m not sure why it’s installing all of the packages in the profile.

3

There is a is an xlibre-video-ati in xlibre repo.

4

Hi @robin0800 Yes, that is why I wondered if I should look into having Xlibre update their package build, but Mark is wondering why it is even a dependency to begin with.

5

Just a note… The topic is not relevant to Manjaro developement - xlibre is unsupported… (topic moved to Support > AUR)

@DeLinuxCo I think you are forgetting that xlibre is unsupported on Manjaro Linux.

Therefore you cannot rely on mhwd to work correct.

With the reputation of the xlibre project and all the noise it generally generates, I don’t think it has a future for Manjaro Linux.

See https://forum.manjaro.org/t/189833

EDIT:

Clarification

For as long as Xlibre is NOT provided by upstream Arch Linux it is not likely to become a part of the Manjaro Linux repositories.

6

Politics is one thing. X’s main selling point is its stability and that everything just works. Artix Linux dropped Xlibre again and seemingly exactly for this reason.

7

@linux-aarhus Well that is unfortunate. Xlibre has turned out to be a big improvement over Xorg, and I have been running Xlibre for a year with no issues sans the Manjaro packages not being updated in sync with Arch, but that is not a technical issue with Xlibre, that was an oversight/planning issue.

As for the Artix Linux dropping Xlibre, There is no evidence that I can find, where any Xlibre team attacked anyone at Artix Linux. Please, if you can show me that, I would really like to see it. At this point it is nothing more than “he said / she said”.

For those interested, Why did Artix drop XLibre? · X11Libre · Discussion #560 · GitHub

Now, I am going to go into a rant of sorts, and in all things software, we can agree to disagree, but I am going to explain to you why I think it is a big mistake, to the detriment of Manjaro, for not supporting Xlibre.

First, I have been using Linux since 1997, KDE 2.0, still holds a special place in my heart. Since then, I have seen and experienced many things in the Linux world, one that stands out was the Microsoft attempting to sue anyone using Linux using SCO as a proxy.

It is clear now that it was all a ploy to scare people and companies away from Linux, the now famous “Halloween Documents” brought all of that to light. It also showed the modus operandi of Microsoft in dealing with competition.

I also remember the rumor about Ubuntu being bought by Microsoft, the kibosh was put on that one by the community quickly. It was just a few years later, that Windows WSL ships with Ubuntu. Now, Ubuntu is an interesting case, if you look through all of the website and the only time you will see the word “Linux” is in a description of something, example, “VM’s for Windows, macOS and Linux”, Their product is Ubuntu, not Ubuntu Linux. And I understand that Linux is registered, but their whole position is to move towards their own eco system, hence Snaps.

The reason I say all of this is because , Microsoft and their cohorts (ubuntu and the like) seem to have a plan, that plan is to move to the MIT license and that is where the “extinguish” will occur of Linux. Wayland is MIT, Rust is MIT, uutils coreutils is MIT, the kernel is now accepting Rust code, that code is MIT.

For those less initiated, MIT license allows for modifying the code without having to give back to the source unlike GPL. Rust is not the problem, Wayland is not the problem, uutils coreutils is not the problem, the problem is MIT! Once they have used the Community to do most of their work for them, they will turn on the community and lock it down in such a way that it will make Linux, as we know it, useless.

It is interesting to see how blindly the community is pushing so hard for Wayland, not understanding it is to their own demise. The goal should always be choice.

Peace,
João

8

I’m afraid you are mistaken. All code in the kernel tree, regardless of what programming language it was written in, must be licensed under the GNU GPLv2.

The fact that Rust is licensed under MIT only pertains to the source code of Rust itself. As a programming language, it may be used for writing and maintaining software that has a completely different license.

We had a discussion about this among the Staff a while ago, albeit that it wasn’t about Rust, but about bash.

bash is licensed under GPLv3, which is more restrictive than GPLv2, and I contended that bash scripts could be regarded as derivative works of bash, since they need bash to be present on the system in order to be able to run (in native bash mode), and that therefore, bash scripts should also be licensed under GPLv3.

But as it turns out, I was wrong. Even the much more restrictive GPLv3 states that bash is merely a tool, and that whatever is created with bash may be released under whatever license the author sees fit.

9

On this one I will concede.

10

That is great - I don’t mind you using/preferring Xlibre.

I realise that my choice of words may have been confusing, therefore I want to clarify…

What I am referring to and what I intended to convey:

For as long as Xlibre is NOT provided by upstream Arch Linux it is not likely to become a part of the Manjaro Linux repositories.

Please see XLibre - ArchWiki to learn how upstream Arch Linux is viewing the project.