FreeBSD 13.0 - Intel Haswell DT-GT 1.5 Integrated Graphics GPU

you don't create "video" group with that command.
"video" group must already exists when you execute that command.
That command just adds user (user name) to the already existing "video" group.

For creating groups, you use the command pw groupadd
I don't remember creating the "video" group thou, I think it already exists on default FreeBSD installation.
you can look if the video group already exists (and its GID and members) with pw group show video

Code:
~> pw group show video
video:*:44:matt_k,goatse
~> pw group show wheel
wheel:*:0:root,matt_k
You got this mixed up... just check the pw(8) manpage, and the Handbook for proper usage.
 
From my tutorial, during the Base System installation process, after you set your root password it gives you the chance to create a usr account. And here we go:

Now's your chance to add a User account. Less privileged than root, it's what you'll be running in 99.9% of the time.

When asked if you want to invite the user to other groups make them members of:

Code:
wheel operator

Typed just like that.

Enter a password for that account, for the rest of the options choose the default option it recommends and just hit Enter to proceed from one to the next.

One account should be enough. When asked if you want to make another user account type no and hit Enter.
Now we're at the desktop, way down the page:

You should still be in your root account in urxvt, so enter:

leafpad

To bring up that text editor as root. Copy this text into leafpad:

Code:
[devfsrules_common=7]
add path 'ad*' mode 0666 group operator
add path 'da*' mode 0666 group operator
add path 'acd*' mode 0666 group operator
add path 'cd*' mode 0666 group operator
add path 'mmcsd*' mode 0666 group operator
add path 'pass*' mode 0666 group operator
add path 'xpt*' mode 0666 group operator
add path 'ugen*' mode 0666 group operator
add path 'usbctl' mode 0666 group operator
add path 'usb*' mode 0666 group operator
add path 'lpt*' mode 0666 group operator
add path 'ulpt*' mode 0666 group operator
add path 'unlpt*' mode 0666 group operator
add path 'fd*' mode 0666 group operator
add path 'uscan*' mode 0666 group operator
add path 'video*' mode 0666 group operator
add path 'dvb/*' mode 0666 group operator

And save as /etc/devfs.rules.

Now you are a member of the video group.

If you don't have editors/leafpad installed, now is a good time to do it. Or use a text editor you know. vi comes with the Base System.
 
yeah, I just add video to the list of groups (that I should be part of) during the install process. Takes some planning and studying documentation.
 
add path 'video*' mode 0666 group operator

groups wheel and operator but not video.

Groups, not paths.

On a test machine, for example:

Code:
root@mowa219-gjp4-vm-freebsd-13-zfs:~ # pw groupmod video -d grahamperrin
root@mowa219-gjp4-vm-freebsd-13-zfs:~ # cat /etc/devfs.rules
[devfsrules_common=7]
add path 'ad*' mode 0666 group operator
add path 'da*' mode 0666 group operator
add path 'acd*' mode 0666 group operator
add path 'cd*' mode 0666 group operator
add path 'mmcsd*' mode 0666 group operator
add path 'pass*' mode 0666 group operator
add path 'xpt*' mode 0666 group operator
add path 'ugen*' mode 0666 group operator
add path 'usbctl' mode 0666 group operator
add path 'usb*' mode 0666 group operator
add path 'lpt*' mode 0666 group operator
add path 'ulpt*' mode 0666 group operator
add path 'unlpt*' mode 0666 group operator
add path 'fd*' mode 0666 group operator
add path 'uscan*' mode 0666 group operator
add path 'video*' mode 0666 group operator
add path 'dvb/*' mode 0666 group operator
root@mowa219-gjp4-vm-freebsd-13-zfs:~ # grep grahamperrin /etc/group
wheel:*:0:root,grahamperrin,percy,test
operator:*:5:root,grahamperrin
grahamperrin:*:1001:
root@mowa219-gjp4-vm-freebsd-13-zfs:~ # exit
logout
grahamperrin@mowa219-gjp4-vm-freebsd-13-zfs:~ % sudo shutdown -r now
Password:

grahamperrin is not (no longer) a member of the video group.
 
...
Code:
[devfsrules_common=7]
add path 'ad*' mode 0666 group operator
add path 'da*' mode 0666 group operator
add path 'acd*' mode 0666 group operator
add path 'cd*' mode 0666 group operator
add path 'mmcsd*' mode 0666 group operator
add path 'pass*' mode 0666 group operator
add path 'xpt*' mode 0666 group operator
add path 'ugen*' mode 0666 group operator
add path 'usbctl' mode 0666 group operator
add path 'usb*' mode 0666 group operator
add path 'lpt*' mode 0666 group operator
add path 'ulpt*' mode 0666 group operator
add path 'unlpt*' mode 0666 group operator
add path 'fd*' mode 0666 group operator
add path 'uscan*' mode 0666 group operator
add path 'video*' mode 0666 group operator
add path 'dvb/*' mode 0666 group operator

And save as /etc/devfs.rules.

I don't understand why you give all this access to the operator group, you can easily delete an entire drive by using the raw access to the sata drives (and usb). I don't know for you, but when I am at my normal user I don't expect it to be able to delete everything.

Same for video, there is a group that is created specifically for this task why not just add the user to the correct group ?
 
… why not just add the user to the correct group ?

… operator will have the required effect in this case, …

If I recall correctly: membership of operator effectively negates the requirement to be a member of video.

As an operator, a member can (also) benefit from things such as a broader range of options in a log out dialogue, for example:

1632982280275.png
  • hint – don't click that button
– all of which might be pleasantly but :-/ wildly off-topic from the opening post, however this is FreeBSD Forums.
 
If I recall correctly: membership of operator effectively negates the requirement to be a member of video.
No, of course not. video and operator are not some magical entities with superpowers, those are just groups to which some nodes in /dev belong by default. And in Unix files can only have one group.
 
I'm not sure what answer do you want. In order to be able to use 3d acceleration Mesa libs open things like /dev/dri/card0 (to communicate with the kernel driver). These nodes should have ownership user=root, group=video and 0660 permissions by default.
 
I see wrongness in package messages such as <https://www.freshports.org/graphics/drm-current-kmod/#message> and <https://www.freshports.org/graphics/drm-fbsd13-kmod/#message>. If no-one else reports a bug, I will.

If I recall correctly: membership of operator effectively negates the requirement to be a member of video.

Probably some muddled recollection. Sorry.

From the 2019 FreeBSD Journal article, A Guide To Getting Started With FreeBSD:

… Add the user account to the groups wheel, operator, video

– however pages such as <https://people.freebsd.org/~murray/handbook/x-config.html#x-config-user-group> suggest that membership of wheel (not operator) negates the requirement to be a member of video. Much the same at <https://docs.freebsd.org/en/books/handbook/x11/#x-config-user-group>.

Here, after removing myself from the video group on my everyday computer:

Code:
% grep grahamperrin /etc/group | sort
grahamperrin:*:1002:
operator:*:5:root,grahamperrin,bbsadmin-l
vboxusers:*:920:grahamperrin,bbsadmin-l
webcamd:*:145:grahamperrin
wheel:*:0:root,grahamperrin,bbsadmin-l
% cat /etc/devfs.rules
[system=10]
add path 'usb/*' mode 0660 group operator
add path 'acd*' mode 0666
add path 'cd*' mode 0666
add path 'pass*' mode 0666
add path 'xpt*' mode 0666

% ls -hl /dev/dri
total 0
lrwxr-xr-x  1 root  wheel     8B  1 Oct 02:39 card0 -> ../drm/0
lrwxr-xr-x  1 root  wheel    10B  1 Oct 02:39 renderD128 -> ../drm/128
% uname -KU
1400033 1400033
% freebsd-version -kru
14.0-CURRENT
14.0-CURRENT
14.0-CURRENT
%
 
Code:
% ls -hl /dev/dri
total 0
lrwxr-xr-x  1 root  wheel     8B  1 Oct 02:39 card0 -> ../drm/0
lrwxr-xr-x  1 root  wheel    10B  1 Oct 02:39 renderD128 -> ../drm/128
Probably just symlink permissions. Those usually do not matter. Check the actual symlink targets. (Although this is somewhat curious, considering the code: https://github.com/freebsd/freebsd-...a51307f9f2e/sys/dev/drm2/drm_stub.c#L369-L387, https://github.com/freebsd/freebsd-...b4a51307f9f2e/sys/dev/drm2/drmP.h#L1596-L1598.)
 
Code:
% ls -hl /dev/drm/0
crw-rw----  1 root  video   0xe5  1 Oct 03:38 /dev/drm/0
% ls -hl /dev/drm/128
crw-rw----  1 root  video  0x165  1 Oct 03:38 /dev/drm/128
%
 
I don't understand why you give all this access to the operator group, you can easily delete an entire drive by using the raw access to the sata drives (and usb). I don't know for you, but when I am at my normal user I don't expect it to be able to delete everything.
What makes you think you can delete anything outside the home directory from the usr account with that file level of Satanic permission?

That same file with the name [devfsrules_common=7] at top which I carried over from my PC-BSD days as a beta tester in 2005 when I switched to FreeBSD in 2011 and been using since.

I can tell you. Because you have never ran a system that way and don't know what you can and cannot delete. Why don't I just delete that file from my user account if I can delete a whole drive. Right here, right now.
no_writes01.png
Whoopsie. You can't.

Well, then I'll delete the usb drive, since you said you can. Shoot the works!
no_writes01.png
Snake eyes! You lose again
no_mount4U.png

I can't even mount a drive from my user account.
Same for video, there is a group that is created specifically for this task why not just add the user to the correct group ?
I got my start with BSD in 205 with PC-BSD, taught myself to use FreeBSD and ports and have been building my own desktops just like I laid out since coming here. I wrote that down as notes to myself so I wouldn't forget while offline and off-world.

I posted it here in 2017, it has been featured twice in freebsdnews.com, DutchDaemon[ and SirDice both approved with my style of presentation found pleasing by DutchDaemon, what I remember and valued most as a writer.

It has been gone through with microscopic detail by untold squads of snipers who would love to find an error in point to be able to take me down with, but to no avail. I have taken suggestions offered to better it, have kept it updated, made an adaptation of the pf ruleseet for CUPS users in the same night requested going without sleep.

And just for teo who had to have some pretty icons on the fluxbox menu, added that. But busted himself as trolling when he admitted to not knowing frijoles from beans about it in the screenshot thread just the other day.

We know how it played out from there.
 
I can't even mount a drive from my user account.
Funny you should say that, Trihexagonal ... I've been doing that in 13-RELEASE since day 1. It's quite workable in KDE on my machine. Not completely ironed out ( a USB stick shows up as /media-5843276584275985987/, or /media/6549827698543769/, but still very usable, no need to su root to mount a USB stick. I actually did not even do anything special with /etc/fstab or anything like that...
 
Funny you should say that, Trihexagonal ... I've been doing that in 13-RELEASE since day 1. It's quite workable in KDE on my machine. Not completely ironed out ( a USB stick shows up as /media-5843276584275985987/, or /media/6549827698543769/, but still very usable, no need to su root to mount a USB stick. I actually did not even do anything special with /etc/fstab or anything like that...
Just remembered - I did have to install sysutils/fusefs-ntfs and to add fusefs_load=YES to /boot/loader.conf for my USB sticks to work. But nothing done beyond that.
 
Ok now can you do a dd if=/dev/zero of=/dev/da0 with a drive that you don't have a backup of the data (assuming it is an usb external that is named da0, rename with what you have), of course do not mount it. I am not interesting to test it myself since I care about my data. Your answer make no sense since I was talking about accessing the raw devices not the filesystem.
 
Back
Top