starting wayland (wayfire) fails using nvidia card [Found 0 GPUS]

Firefox uses this so it runs as a native wayland application

Code: 
export MOZ_ENABLE_WAYLAND=1

none of the other options are needed

my ~/.zshenv

Code: 
# ~/.zshenv

# Path
typeset -U PATH path
path=("$HOME/bin" "/usr/local/bin" "$path[@]")
export PATH

# xdg directories
export XDG_CONFIG_HOME="$HOME/.config"
export XDG_CACHE_HOME="$HOME/.cache"
export XDG_DATA_HOME="$HOME/.local/share"
export XDG_RUNTIME_DIR="/var/run/user/`id -u`"

# firefox
export MOZ_ENABLE_WAYLAND=1

# qt5
export QT_QPA_PLATFORMTHEME=qt5ct

# ssh-add
export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"

# less
export LESSHISTFILE="${XDG_CONFIG_HOME}/less/history"
export LESSKEY="${XDG_CONFIG_HOME}/less/keys"

# vi mode
export KEYTIMEOUT=1

# mpd host variable for mpc
export MPD_HOST="/home/djwilcox/.config/mpd/socket"
 
no = ? what it means ? there are a lot of variables involved. Please don't be generic,because it's hard to understand which parameter should go to the right place. In this kind of multi variables scenario,shorts and generic answers makes a lot of confusion instead of helping.

thanks for your .zshenv but since I want to use .cshrc,it generates only confusion because the syntax is different.
A different story is if you want to help me to create a working .cshrc (or someone else wants). Otherwise I will be frozen here forever.
 
ohhhh ok. So,this should be the correct ones :

setenv MOZ_WAYLAND_ENABLE 1
setenv GDK_BACKEND wayland
setenv QT_QPA_PLATFORM wayland
setenv TERMINAL alacritty
setenv XDG_DEFAULT_RULES evdev
setenv SDL_VIDEODRIVER wayland
setenv CLUTTER_BACKEND wayland
setenv QT_WAYLAND_DISABLE_WINDOWDECORATION 1
 
There are some additional parameter to set up :

Code: 
#setenv XDG_RUNTIME_DIR=~/.cache/run
setenv XDG_RUNTIME_DIR /var/run/user/`id -u`
setenv GTK_THEME Nordic-v40
setenv QT_QPA_PLATFORMTHEME qt5ct
setenv LC_ALL it_IT.UTF-8
setenv LANG it_IT.UTF-8
 
nvidia updated Production Branch of their driver to 550.54.14 and patches for updating ports for it are proposed as below.
Note that the latter requires the former. If you aren't using DRM support, the former alone is sufficient (for anyone who don't want graphics/drm-*-kmod to be installed like me).

Does anyone tried them? I'm not using Wayland so unsure any of your problems are fixed or not.
 
Is this the right procedure to try it ?

Code: 
--> Clean Up Existing Drivers
 
# sudo kldunload nvidia-modeset
# sudo kldunload nvidia
# sudo pkg remove -y nvidia-driver nvidia-settings nvidia-xconfig


--> Upgrading nvidia-driver and linux-nvidia-libs to 550.54.14 directly from ports


# cd /usr/ports/x11/nvidia-driver
# mv Makefile Makefile.orig
# cp Makefile.orig Makefile
# mv distinfo distinfo.orig


# nano Makefile

DISTVERSION?=   550.54.14

# make makesum
# make 
# make install

# cd /usr/ports/x11/linux-nvidia-libs
# mv Makefile Makefile.orig
# cp Makefile.orig Makefile
# mv distinfo distinfo.orig

# nano Makefile

DISTVERSION?=   550.54.14

# make makesum
# make reinstall clean

# Remove nvidia stuff from /boot/loader.conf
sudo sed -i '/nvidia/d' /boot/loader.conf

# Load nvidia modules via /etc/rc.conf
echo 'kld_list+=" nvidia-modeset nvidia "' | sudo tee /etc/rc.conf

# No need to reboot, just load the new drivers
sudo kldload nvidia-modeset
 
ziomario said:
Is this the right procedure to try it ?

Code: 
--> Clean Up Existing Drivers
 
# sudo kldunload nvidia-modeset
# sudo kldunload nvidia
# sudo pkg remove -y nvidia-driver nvidia-settings nvidia-xconfig


--> Upgrading nvidia-driver and linux-nvidia-libs to 550.54.14 directly from ports


# cd /usr/ports/x11/nvidia-driver
# mv Makefile Makefile.orig
# cp Makefile.orig Makefile
# mv distinfo distinfo.orig


# nano Makefile

DISTVERSION?=   550.54.14

# make makesum
# make
# make install

# cd /usr/ports/x11/linux-nvidia-libs
# mv Makefile Makefile.orig
# cp Makefile.orig Makefile
# mv distinfo distinfo.orig

# nano Makefile

DISTVERSION?=   550.54.14

# make makesum
# make reinstall clean

# Remove nvidia stuff from /boot/loader.conf
sudo sed -i '/nvidia/d' /boot/loader.conf

# Load nvidia modules via /etc/rc.conf
echo 'kld_list+=" nvidia-modeset nvidia "' | sudo tee /etc/rc.conf

# No need to reboot, just load the new drivers
sudo kldload nvidia-modeset
Click to expand...
The assumed correct way is as follows.
  1. Download patches uploaded at PR 277028 on FreeBSD Bugzilla and D44073 on FreeBSD Phablicator to whereever you want.
  2. Apply both patches at the top of the ports tree YOU ACTUALLY USE FOR BUILD. The patch at Bugzilla assumes -p1 option while the patch at Phablicator assumes -p0 option. Dry-run using -C option is encouraged before actually applying to be sure.
  3. Rebuild/reinstall x11/nvidia-driver and graphics/nvidia-drm-*-kmod as usual you're doing with ports (not using official pkg). "*" above depends on which you currently installing. 510, 515 or 61. If you have x11/linux-nvidia-libs installed, rebuild/reinstall it, too to keep in sync with x11/nvidia-driver. The patch at Bugzilla has hunks for it, too.
  4. If you don't want patches staying applied there after updating, revert them.
  5. Restart your computer. As I'm not 100% sure unloading/reloading of kmods are really safe or not.
If you don't use DRM modules, ignore graphics/nvidia-drm-*-kmod above.
As you may know, downloading patches doesn't require logging in. But if you want to leave comments, you must have accounts (need registering each of them).

For Bugzilla, you can download any patch you want by clicking the title of the patch in "Attachments" table and save displayed diff from browser.

For Phablicator, click "Actions" button, click "Download Raw Diff" menu item displayed and save displayed diff from browser.
 
Thanks for the explanations,but (for me) they are too vague. I'm not sure at all to be able to follow the procedure exactly as it should be. So the risk to damage my system is high. I will not do that,unless further and more detailed instructions.
 
NapoleonWils0n said:
Wayfire is working i just tested it

if its not working for you then its your set up thats the issue
Click to expand...
Yeah, I just tried again with my latest nvidia-driver on latest packages with FreeBSD 14 p5 and it gives a no gpus found error on launch. Not sure if I missed a step in the handbook. But this has been an issue with Nvidia on 14 for me.
 
im running 14 p5 and both wayfire and dwl work

heres my config so you can compare it to yours and see if there's anything your missing

freebsd root dotfiles

github.com

GitHub - NapoleonWils0n/freebsd-root-xps: freebsd root dotfiles for dell xps 15 2019

freebsd root dotfiles for dell xps 15 2019. Contribute to NapoleonWils0n/freebsd-root-xps development by creating an account on GitHub.
github.com github.com

freebsd dotfiles

github.com

GitHub - NapoleonWils0n/freebsd-dotfiles-xps: freebsd dotfiles dell xps 15 2019

freebsd dotfiles dell xps 15 2019. Contribute to NapoleonWils0n/freebsd-dotfiles-xps development by creating an account on GitHub.
github.com github.com
 
ziomario said:
Is this the right procedure to try it ?

Code: 
--> Clean Up Existing Drivers
 
# Remove nvidia stuff from /boot/loader.conf
sudo sed -i '/nvidia/d' /boot/loader.conf

# Load nvidia modules via /etc/rc.conf
echo 'kld_list+=" nvidia-modeset nvidia "' | sudo tee /etc/rc.conf
Click to expand...
I don't understand how you need a step by step guide when you are using some advanced tools to edit your config files.
How long is your /boot/loader.conf ?
You could just open it, find the line that contain nvidia in them, and remove them.

Same for /etc/rc.conf, why the use of tee ? There is a tools for that : sysrc.
If you don't want to use sysrc, then just open the file and find the kld_list line.

On the subject, a good way to test this kind of change is to use poudriere to build (and use testport) to make sure that the generated pkg will register where the files will be installed. Which means that you can then latter remove it and there should not be any leftover.

I am not sure that the nvidia driver can be unloaded and reloaded with a new version without any trouble, a reboot is encouraged.
 
I don't understand how you need a step by step guide when you are using some advanced tools to edit your config files.
How long is your /boot/loader.conf ?
You could just open it, find the line that contain nvidia in them, and remove them.

Same for /etc/rc.conf, why the use of tee ? There is a tools for that : sysrc.
If you don't want to use sysrc, then just open the file and find the kld_list line.
Click to expand...

Those instructions come from an old post. Yeah,usually I remove the offending lines by hand on rc.conf and on loader.conf. But I left those commands there for educational purpose.

On the subject, a good way to test this kind of change is to use poudriere to build (and use testport) to make sure that the generated pkg will register where the files will be installed. Which means that you can then latter remove it and there should not be any leftover.
Click to expand...

I'm not yet ready to complicate my life with poudriere and testport at this stage of my educational path.
I would like to understand what's wrong with the procedure that I have posted. Another one has been suggested in its place.
Why ? What's wrong with "mine" ?
 
NapoleonWils0n said:
im running 14 p5 and both wayfire and dwl work

heres my config so you can compare it to yours and see if there's anything your missing

freebsd root dotfiles

github.com

GitHub - NapoleonWils0n/freebsd-root-xps: freebsd root dotfiles for dell xps 15 2019

freebsd root dotfiles for dell xps 15 2019. Contribute to NapoleonWils0n/freebsd-root-xps development by creating an account on GitHub.
github.com github.com

freebsd dotfiles

github.com

GitHub - NapoleonWils0n/freebsd-dotfiles-xps: freebsd dotfiles dell xps 15 2019

freebsd dotfiles dell xps 15 2019. Contribute to NapoleonWils0n/freebsd-dotfiles-xps development by creating an account on GitHub.
github.com github.com
Click to expand...

I hope that you realize that there are sooo many variables involved. It's impossible to understand whats wrong only by comparing some config files. That's because this issue does not belong only to my system,but it belongs to more users and systems in different circumstances and conditions. I think that to fix it there is the needing to make a very detailed troubleshooting. Or maybe its enough to install the new nvidia drivers. Unfortunately I don't understand how to do that. Can someone elaborate more ? Sorry if I'm not experienced like you.
 
ziomario said:
Those instructions come from an old post. Yeah,usually I remove the offending lines by hand on rc.conf and on loader.conf. But I left those commands there for educational purpose.



I'm not yet ready to complicate my life with poudriere and testport at this stage of my educational path.
I would like to understand what's wrong with the procedure that I have posted. Another one has been suggested in its place.
Why ? What's wrong with "mine" ?
Click to expand...

Nothing wrong on the step for building the nvidia driver (native and linux).
It was just the steps for loader.conf and rc.conf that are more dangerous without knowing what are in those files.
For instance, for sed:
First, your example does not work (in FreeBSD):
sed -i '/nvidia/d' loader.conf
Result on
sed: 1: "loader.conf": extra characters at the end of l command
Click to expand...
Lets experiment with
sed -i -e '/nvidia/d' loader.conf
Given this file:
Code: 
nvidia_load="YES"
zfs_load="YES" # nvidia
geom_load="YES" #intel
The result will be
Code: 
geom_load="YES" #intel
If you use sysrc instead:
sysrc -f loader.conf nvidia_load
With
Code: 
nvidia_load="YES"
zfs_load="YES" # nvidia_load
geom_load="YES" #intel
You get the following:
nvidia_load: YES
Click to expand...
Removing will then be done with
sysrc -f loader.conf -x nvidia_load
Which gives
Code: 
zfs_load="YES" # nvidia_load
geom_load="YES" #intel
 
monwarez said:
Nothing wrong on the step for building the nvidia driver (native and linux).
It was just the steps for loader.conf and rc.conf that are more dangerous without knowing what are in those files.
For instance, for sed:
First, your example does not work (in FreeBSD):
sed -i '/nvidia/d' loader.conf
Result on

Lets experiment with
sed -i -e '/nvidia/d' loader.conf
Given this file:
Code: 
nvidia_load="YES"
zfs_load="YES" # nvidia
geom_load="YES" #intel
The result will be
Code: 
geom_load="YES" #intel
If you use sysrc instead:
sysrc -f loader.conf nvidia_load
With
Code: 
nvidia_load="YES"
zfs_load="YES" # nvidia_load
geom_load="YES" #intel
You get the following:

Removing will then be done with
sysrc -f loader.conf -x nvidia_load
Which gives
Code: 
zfs_load="YES" # nvidia_load
geom_load="YES" #intel
Click to expand...

My question is : have "the patches for the nvidia 550.54.14 driver" been upstreamed ? If they have,I could do :

# nano Makefile

DISTVERSION?= 550.54.14

# make makesum
# make
# make install

otherwise,I would install the nvidia 550.54.14 unpatched driver ?
 
ziomario said:
My question is : have "the patches for the nvidia 550.54.14 driver" been upstreamed ?
Click to expand...
which do you mean? Upstream to nvidia? Or to FreeBSD project?
Some maintainers requires the former the first, and only works on adapting to updated upstream. But as far as I know, the maintainer of x11/nvidia-driver, danfe@, is not such a person.
For the latter, PR 277028 itself is upstreaming. I'm waiting for maintainer approval and commit to the ports tree.

And what I've done for the patch uploaded at PR 277028 is to adapt ports to 550.54.14. NO PORTS CAN AUTOMATICALLY TRACK UPDATES ON UPSTREAM AND ADAPTING WITH IT. What I've done is just the thing.

Only possoble candidate for upstreaming to nvidia is relocation of single man page from under /usr/local/man/ into /usr/local/share/man/.
This is currently ongoing to all ports having manpages under /usr/local/man/. No functuonal chanes.

ziomario said:
If they have,I could do :

# nano Makefile

DISTVERSION?= 550.54.14

# make makesum
# make
# make install
Click to expand...
Now I'm puzzled what you actualy want to do.
Do you want reinventing the wheel?
If you can make better patch for this, feel free to upload it at PR 277028. The maintainers (or committer who want to handle it after 2 weeks or more as MAINTAINER TIMEOUT) would prefer whichever they think better, or request more fixes, or fixing by themselves.
To do so, please read Porter's Handbook before you start the job.

Note that I'm not a maintainer, a committer nor nvidia-insider. Just a volunteer user who want x11/nvidia-driver port to be up-to-date with nvidia's Production Branch Driver and keep the way to try latest Beta and/or New Feature Branch.
 
You must log in or register to reply here.
Back
Top