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

if you having issues try setting the group to wheel

Code:
sudo chmod 700 user/"$(id -u)"
sudo chown -R "${USER}":wheel /var/run/user/"$(id -u)"
sudo chmod 700 /var/run/user/"$(id -u)"
 
I'm getting these errors :

failed to open /dev/dri/card0 : permission denied
failed to open /dev/dri/renderD128 : permission denied

The wayland developers suggested that I might need to add my username to the group associated with these files. So,I did :

Code:
# pw groupmod video -m marietto
# pw groupmod wheel -m marietto

but I get the same error. Have I issued the wrong commands ?
 
So another possibility.
I've, silly enough, did another operation when I've changed kld_list.
As some noted that /var/run/ on ZFS could cause problem (because of, if I recall correctly, the lack of posix_fallocate(2)() functionality).
First, formerly to this changes, I've tried /var/run/user/ as tmfs but didn't help and instantly dropped to single user mode when rc scripts tries to create the tmpfs and needed late mount option, maybe because it happenes before dataset for /var is mounted.

The change indirectly helped could be the next trial.
To test making /var/run as tmpfs, I've created /var/run2 and mv(1)'ed everything under /var/run/ there in single user mode, thus, cleared /var/run/.
.Of course, as I've overlooked the fact why tmpfs on /var/run/user failed without late option, it failed without late option and caused some files to be masked by tmpfs, caused crash or hang.

So I reverted the changes, but not restored the backed up contents formerly existed in /var/run/ (restore only when something stopped working, maybe because directory under /var/run/ which are created on install time).

Maybe I should better migrating /var itself to / dataset, keeping datasets under it as independent datasets. And if tmpfs as /var/run goes OK with it even if ZFS-on-Root, adjusting /etc/rc.conf[.local] with current default var_run_enable="YES" and var_run_autosave="YES" on main branch (not MFC'ed) could help.
Note that their comments should be fixed to reflect reality.

your problem can be fixed using the parameter :

LIBSEAT_BACKEND=consolekit2 ; it will prevents the removal of /var/run/user/1001 when xfce4 is closed.
 
you dont need any of the settings you use


Please don't give a whole page as an help,assuming that the user will understand which parameter is the right one for him / her,when on the page there are multiple parameters explained. Try to be precise if you know for sure what's the correct parameter to use. And..."you don't need any of the settings you use" what this mean ? what settings are you talking about ?
 
if you look at that page it tells you how to install wayfire
what groups you need to add your user to

Code:
pw groupmod video -m user

its all on that page
 
if you look at that page it tells you how to install wayfire
what groups you need to add your user to

Code:
pw groupmod video -m user

its all on that page

Istantanea_2024-03-07_12-47-46.jpg
 
maybe I should do :

Code:
chown marietto:marietto /dev/drm0
chown marietto:marietto /dev/drm128

because these devices are owned by root. May this is wrong ?
 
maybe I should do :

Code:
chown marietto:marietto /dev/drm0
chown marietto:marietto /dev/drm128

because these devices are owned by root. May this is wrong ?
See group of the entries. It should be belong to User=root, Group=video.
And have attribute rw for owner and group.
If yes, members of video group can read/write to the character devices.
If not, there shall be problems on creating the entry.

For me,
% ls -l /dev/drm/0
crw-rw---- 1 root video 0x87 3月 7 19:07 /dev/drm/0
% ls -l /dev/drm/128
crw-rw---- 1 root video 0x167 3月 7 19:07 /dev/drm/128
 
I asked that because the developers of wayfire told me that I can't run Wayfire as root. So,I've thought that if those devices are owned by root and I should run wayfire only as normal user,this could be the reason why I get that error.

I have different permissions than you :
Code:
==> ls -l /dev/drm/0
crw-rw-rw-  1 root video 0x10e  7 mar 10:23 /dev/drm/0

==> ls -l /dev/drm/128
crw-rw-rw-  1 root video 0x1c0  7 mar 10:23 /dev/drm/128

that's because I set "others" with rw permissions as a test. Dunno if it is wrong.
 
Anyway,I'm not sure if this is relevant or not,but I found an old page here on the forums that has some interesting informations that can be used to make some experiment :


can you give a look ? it is very interesting. He says :

Modify /etc/devfs.rules as follows:

add path 'dri/*' mode 0666 group video
add path 'drm/*' mode 0666 group video

Be sure to add yourself to group video, reboot your system and see if the libGL permission denied message has gone away.
 
When following the handbook with radeon, Wayfire works. But fails on my 3 Nvidia systems. Is there a clear reason for this yet?
 
I want to inform you that Wayland / Wayfire for me restarted to work again. The previous setup fixed my problem. Never surrender.
 
if you look at that page it tells you how to install wayfire
what groups you need to add your user to

Code:
pw groupmod video -m user

its all on that page

Again for me is very interesting to note as for you everything seems very easy to do,but for me,or maybe with the modern nvidia cards and / or with the later versions of wayland / wayfire ,the procedure became more complicated and maybe less or not documented at all on the handbook. Maybe the handbook could be updated more frequently. Anyway,my opinion is still the same : to don't use only the handbook,but multiple sources. I say this because I see that a lot of users think that the handbook is the holy book. It is good ok,but multiple sources can help to compare different setups that can help for sure to reach the result expected. For me it's not enough to do "pw groupmod video -m marietto" ; I should perform a further procedure. Procedure that I have explained above.
 
I asked that because the developers of wayfire told me that I can't run Wayfire as root. So,I've thought that if those devices are owned by root and I should run wayfire only as normal user,this could be the reason why I get that error.

I have different permissions than you :
Code:
==> ls -l /dev/drm/0
crw-rw-rw-  1 root video 0x10e  7 mar 10:23 /dev/drm/0

==> ls -l /dev/drm/128
crw-rw-rw-  1 root video 0x1c0  7 mar 10:23 /dev/drm/128

that's because I set "others" with rw permissions as a test. Dunno if it is wrong.
Your permissions of the device seems to allow read/write FOR ALL USERS.
Mine allows only root and members of group video.

As you may know, the left-most "c" means it's a character device node.
Following first "rw-" means the owner (here, root) can read/write.
The second "rw-" means the members of the group specified (here, video) can read/write the node.
The last, for me, "---" means users other than root and non-member of group video cannot read/write the node. Your "rw-" means they can read/write.
Device nodes should not be executable (as it is not a program code itself).

You'll find it seems odd as directories under /dev could have executable permission (**x), but it just means that entries under it can have executable permission if it actually is, but for device node, it's dropped on creation by devfs, if I understand correctly, as device nodes are data points to read/write corresponding devices'es internal data and issue ioctl to them.
 
Your permissions of the device seems to allow read/write FOR ALL USERS.
Mine allows only root and members of group video.

As you may know, the left-most "c" means it's a character device node.
Following first "rw-" means the owner (here, root) can read/write.
The second "rw-" means the members of the group specified (here, video) can read/write the node.
The last, for me, "---" means users other than root and non-member of group video cannot read/write the node. Your "rw-" means they can read/write.
Device nodes should not be executable (as it is not a program code itself).

You'll find it seems odd as directories under /dev could have executable permission (**x), but it just means that entries under it can have executable permission if it actually is, but for device node, it's dropped on creation by devfs, if I understand correctly, as device nodes are data points to read/write corresponding devices'es internal data and issue ioctl to them.

that's an old post. I've fixed my problem by modifying /etc/devfs.rules as follows:

Code:
add path 'dri/*' mode 0666 group video
add path 'drm/*' mode 0666 group video

and add myself to group video.
 
I want also suggest to use the script called "wf-install" that installs automatically everything needed to make work wayland / wayfire. Please follow this discussion between me and the developers and you will be able to reach the goal.

 
that's an old post. I've fixed my problem by modifying /etc/devfs.rules as follows:

Code:
add path 'dri/*' mode 0666 group video
add path 'drm/*' mode 0666 group video

and add myself to group video.
I will try this as well. I typically add my user to operator and wheel and video. Do either wheel or operator cause issues with Nvidia?
 
<https://github.com/WayfireWM/wayfire/discussions/2182#discussioncomment-8710643>:



It will be good to understand why it stopped.

I wonder whether nvidia-drm-515-kmod-550.54.14 issues are relevant.

Thanks for asking this. Is relevant the installation of the nvidia driver 550. I've repeated some installation steps of wayland / wayfire on a different installation of FreeBSD 14 with the nvidia driver 535 and I've got the seg. fault. Anyway I want the absolute certainty of this.
 
that's an old post. I've fixed my problem by modifying /etc/devfs.rules as follows:

Code:
add path 'dri/*' mode 0666 group video
add path 'drm/*' mode 0666 group video

and add myself to group video.
I tried it, it doesn't work. Wayfire still won't work on my Nvidia systems.
 
Back
Top