Following the advice of drm-kmod pkg leads to unbootable system

I would tentatively agree that the kld_list syntax in /etc/rc.conf is probably not the real issue, but rather, a symptom of the real problem. It definitely seems to be a problem which involves the timing and sequencing of graphics-related events, at least, on my particular system.

It could be very helpful if more people who report the black-screen problem were more willing to share their own graphics processor identification strings, and message logs. Logs of great size can still be easily accommodated on this forum by running commands such as dmesg -a | nc termbin.com 9999 and cat /var/log/messages | nc termbin.com 9999, and then copying the output links into their posts. For example:
Code:
root@mate:~ # cat /var/log/messages | nc termbin.com 9999
https://termbin.com/slfwl
root@mate:~ #
And here is the link to provide access to my log. Note that the data of interest here will be prefixed with "Oct 9". These termbin.com links will reportedly persist for only about one month:


In my previous post I used a text editor to isolate what I considered to be the more pertinent portions of my dmesg logs, but your mileage may vary.

Also perhaps worth noting is the observation that, in my case at least, lightdm and sddm both seem to do a better job of starting graphics on my system than what I observe when using startx. Again, YMMV.
 
Probed two minutes ago: <https://bsd-hardware.info/?probe=1b48acadd5>

At a glance, nothing of interest in /var/log/dmesg.yesterday or <https://bsd-hardware.info/?probe=1b48acadd5&log=dmesg>.

Things of interest (to me) occurred two days earlier:

IMG_20211007_072603_007.jpg IMG_20211007_072751.jpg

– Thursday 2021-10-07 07:26 BST

At the time of writing (not normally):

Code:
% date ; uptime
Sat  9 Oct 2021 22:28:36 BST
10:28p.m.  up  6:27, 5 users, load averages: 0.28, 0.48, 0.52
% sysrc kld_list
kld_list: fusefs usbhid radeonkms acpi_video
% pkg info xf86-video-ati
pkg: No package(s) matching xf86-video-ati
%

The workaround that I normally use was suspended, for test purposes, a little more than a few days ago, in relation to the issue that I raised around a month ago:

The system may fail to start properly – a blackout – if kld_list includes radeonkms (workaround: instead, load drm) · Issue #108 · freebsd/drm-kmod

… Notes, from before I learnt the drm workaround, suggest that the issue was observable as far back as September 2018 (FreeBSD 12.0-ALPHA7 at the time). I never bothered to report the issue because I assumed a peculiarity with my setup.

Now I'm better prepared to make the issue reproducible, if I can …

I have a gut feeling about what will trigger the next blackout in my case. To not sow seeds of confusion (each person's case may differ): I'll not share details until after the time comes.

Postscript

Photographs added.
 
Last edited:
Very interesting. Using the absolute path does work,
FYI: When you specify an absolute path (with the .ko extension), only that file is tried. When you just specify the module name (without the .ko) extension (for example, "foo"), kldload tries the following paths in order: /boot/kernel/foo, /boot/kernel/foo.ko, /boot/modules/foo, /boot/modules.ko and even paths such as a /boot/dtb{,/overlays}/foo{,ko} (on amd64)! So thing to check for is whether another module of the same name exists in /boot/kernel. Unlikely, but just in case.

If you loaded a kernel from a directory other than /boot/kernel, presumably it will first look for modules in that directory.
 
So I did give it a try, but it didn't work... for me. (I'm also running 13.0-RELEASE.)

Let's summarize. We have uncovered at least 2 non-standard and undocumented workarounds to the problem of when and how to load the Radeon kernel mode-setting driver.


Most people who've reported success at loading radeonkms.ko on this forum modify kld_list as follows:

kld_list="radeonkms"


Both astyle and donallen find that doesn't work, and are using this syntax instead:

kld_list="/boot/modules/radeonkms.ko"

(Note: astyle might be using amdgpu.ko instead of radeonkms.ko with this syntax, I'm not sure.)


Both grahamperrin and I are leaving the kms driver out of kld_list altogether.

astyle's graphics card ID: Asus Radeon RX 550 4GB

donallen's graphics card ID: AMD A8-3850 APU with Radeon(tm) HD Graphics (2900.29-MHz K8-class CPU)

My graphics card ID: AMD A6-6310 APU with AMD Radeon R4 Graphics (on a Lenovo G50-45 model laptop)


More about my particular results:
If I pre-load the graphics driver via kld_list using either of the above noted syntaxes, my system will begin thrashing and show a black screen. This will happen regardless of whether or not I attempt to start X. If I act quickly enough, I might be able to switch to a virtual terminal using the CTRL-ALT function keys, but if I wait more than a few seconds, the system will freeze up and quickly become unresponsive to any key combination. It will also become inaccessible to ssh, requiring a power off (system halt) and reboot to recover.
I was able to capture output from dmesg -a showing sequences of drm messages for both normal and abnormal loading of the radeonkms.ko driver. Here is the relevant section showing a normal load sequence; this sequence is essentially the same whether I start X using startx or x11/lightdm:


... and here is the section showing the abnormal load sequence:


Both sequences look essentially the same, up to the line which reads as follows in the normal sequence:
Oct 9 02:14:40 mate kernel: Successfully added WC MTRR for [0xe0000000-0xefffff
ff]: 0;


... that line is not included in the abnormal sequence. The sequences continue to match up to a point where it starts showing timeout errors, which look like this:
Code:
[drm ERROR :uvd_v1_0_ib_test] radeon: fence wait timed out.
[drm ERROR :radeon_ib_ring_tests] radeon: failed testing IB on ring 5 (-60).
[drm ERROR :radeon_vce_ib_test] radeon: fence wait timed out.
[drm ERROR :radeon_ib_ring_tests] radeon: failed testing IB on ring 6 (-60).
[drm ERROR :radeon_vce_ib_test] radeon: fence wait timed out.
[drm ERROR :radeon_ib_ring_tests] radeon: failed testing IB on ring 7 (-60).
Later in the sequence, it starts repeating "stalled" and "GPU lockup" messages like these:
Code:
drmn0: ring 3 stalled for more than 10000msec
drmn0: GPU lockup (current fence id 0x0000000000000001 last fence id 0x000000000
0000003 on ring 3)
drmn0: ring 3 stalled for more than 10801msec
drmn0: GPU lockup (current fence id 0x0000000000000001 last fence id 0x000000000
0000003 on ring 3)
The number of milliseconds in the "stalled" messages continues growing until the system eventually locks up.
Nice analysis... Yeah, I am using amdgpu.ko that is installed in /boot/modules/ by ports. That's what my card (Correctly identified as Asus Radeon RX 550 4GB) requires. But I'm seeing that:
  1. My suggestion for donallen worked the first time (he said so himself). My suggestion is based on the wiki I linked to earlier.
  2. The When Vull tries it on his hardware - it messes things up, and the kernel panic gets confirmed by grahamperrin ...
  3. Argentum commented that it shouldn't matter where in /etc/rc.conf the line of code loading the driver is - last, not last, in the middle...
I guess I'm gonna watch this from the sidelines.
 
Re: kernel panic

I didn't see a kernel panic or a system halt. It was I who eventually forced a system halt by holding down the power button, or a system reboot, which, if I was fast enough, I could trigger by keying CTRL-ALT-DEL.

What I did see was the system thrashing in an endless loop between a "ring 3 stall" (or a "ring 0 stall", for a growing number of milliseconds on each iteration of the loop) and a "GPU lockup" event reported at "current fence id 0x0000000000000001 last fence id 0x0000000000000003 on ring 3" (or reported at some other fence ids on ring 0). Sometimes, early on, I might get a "GPU softreset" that looked like this:
Code:
Oct  9 01:42:17 mate kernel: drmn0: GPU softreset: 0x00000108
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS=0xA0003028
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS2=0x30000008
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE0=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE1=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE2=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE3=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   SRBM_STATUS=0x20020640
Oct  9 01:42:17 mate kernel: drmn0:   SRBM_STATUS2=0x00000080
Oct  9 01:42:17 mate kernel: drmn0:   SDMA0_STATUS_REG   = 0x46CEE557
Oct  9 01:42:17 mate kernel: drmn0:   SDMA1_STATUS_REG   = 0x46CEE557
Oct  9 01:42:17 mate kernel: drmn0:   CP_STAT = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_STALLED_STAT1 = 0x00000c00
Oct  9 01:42:17 mate kernel: drmn0:   CP_STALLED_STAT2 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_STALLED_STAT3 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPF_BUSY_STAT = 0x584c0282
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPF_STALLED_STAT1 = 0x00000001
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPF_STATUS = 0x80008007
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPC_BUSY_STAT = 0x00000408
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPC_STALLED_STAT1 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPC_STATUS = 0xa0000041
Oct  9 01:42:17 mate kernel: drmn0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000
Oct  9 01:42:17 mate kernel: drmn0: Wait for MC idle timedout !
Oct  9 01:42:17 mate kernel: drmn0: GRBM_SOFT_RESET=0x00010001
Oct  9 01:42:17 mate kernel: drmn0: SRBM_SOFT_RESET=0x00000500
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS=0xA0003028
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS2=0x30000008
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE0=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE1=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE2=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE3=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   SRBM_STATUS=0x20000640
Oct  9 01:42:17 mate kernel: drmn0:   SRBM_STATUS2=0x00000080
Oct  9 01:42:17 mate kernel: drmn0:   SDMA0_STATUS_REG   = 0x46CEE557
Oct  9 01:42:17 mate kernel: drmn0:   SDMA1_STATUS_REG   = 0x46CEE557
Oct  9 01:42:17 mate kernel: drmn0:   CP_STAT = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_STALLED_STAT1 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_STALLED_STAT2 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_STALLED_STAT3 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPF_BUSY_STAT = 0x584c0000
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPF_STALLED_STAT1 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPF_STATUS = 0x80008003
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPC_BUSY_STAT = 0x00000408
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPC_STALLED_STAT1 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPC_STATUS = 0xa0000041
Oct  9 01:42:17 mate kernel: drmn0: GPU reset succeeded, trying to resume
Oct  9 01:42:17 mate kernel: drmn0: Wait for MC idle timedout !
Oct  9 01:42:17 mate syslogd: last message repeated 1 times
Oct  9 01:42:17 mate kernel: [drm] PCIE GART of 2048M enabled (table at 0x000000000030E000).
Oct  9 01:42:17 mate kernel: drmn0: WB enabled
But that would only lead right back to a repeat of the same kind of endless thrashing loop:
Code:
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0x0xfffff80007082c00
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 1 use gpu addr 0x0000000040000c04 and cpu addr 0x0xfffff80007082c04
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 2 use gpu addr 0x0000000040000c08 and cpu addr 0x0xfffff80007082c08
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0x0xfffff80007082c0c
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 4 use gpu addr 0x0000000040000c10 and cpu addr 0x0xfffff80007082c10
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 5 use gpu addr 0x0000000000078d30 and cpu addr 0x0xfffff800e0078d30
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 6 use gpu addr 0x0000000040000c18 and cpu addr 0x0xfffff80007082c18
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 7 use gpu addr 0x0000000040000c1c and cpu addr 0x0xfffff80007082c1c
Oct  9 01:42:17 mate kernel: [drm ERROR :cik_ring_test] radeon: ring 0 test failed (scratch(0x3010C)=0xCAFEDEAD)
Oct  9 01:42:17 mate kernel: [drm ERROR :cik_resume] cik startup failed on resume
Oct  9 01:42:18 mate kernel: [drm ERROR :radeon_dp_link_train_cr] displayport link status failed
Oct  9 01:42:18 mate kernel: [drm ERROR :radeon_dp_link_train_cr] clock recovery failed
Oct  9 01:42:39 mate kernel: drmn0: ring 0 stalled for more than 10473msec
Oct  9 01:42:39 mate kernel: drmn0: GPU lockup (current fence id 0x0000000000000001 last fence id 0x0000000000000002 on ring 0)
Oct  9 01:42:39 mate kernel: drmn0: ring 0 stalled for more than 10973msec
Oct  9 01:42:39 mate kernel: drmn0: GPU lockup (current fence id 0x0000000000000001 last fence id 0x0000000000000002 on ring 0)
 
root@mate:~ # cat /var/log/messages | nc termbin.com 9999
root@mate:~ #
[/code]
And here is the link to provide access to my log. Note that the data of interest here will be prefixed with "Oct 9". These termbin.com links will reportedly persist for only about one month:


In my previous post I used a text editor to isolate what I considered to be the more pertinent portions of my dmesg logs, but your mileage may vary.
Little off-topic, but Termbin is cool!
 
Since installing xf86-video-ati at the suggestion of Vull and GrahamPerrin, I have rebooted my system several times without incident and with correct resolution in X. The radeonkms kernel module is also installed, loaded by kld_list="radeonkms" in rc.conf.

In an early post to this thread, I responded to a question about whether I'd installed xf86-video-ati and said "no help". What I meant was that the X driver by itself did not result in proper resolution when X comes up. At that point, I had not tried installing both that X driver and the radeonkms kernel driver. Unfortunately, I removed the X driver, since it appeared to serve no purpose, which appears to have been a mistake.

Given the crash free performance of my system through multiple reboots, it's beginning to look like you must have xf86-video-ati installed in order to use the radeonkms kernel driver. If true, then the bug is that installation of drm-kmod, either as a port or a package, does not depend upon the corresponding X drivers (xf86-video-intel, -ati, -amd) and should.
 
Please note i don't have any xf86-... package installed.
And my radeon card works 100% fine under Wayland.
kldstat | grep -i radeon
Code:
15    1 0xffffffff8233b000   14ec70 radeonkms.ko
17    1 0xffffffff81ddf000     3258 radeon_CAICOS_pfp_bin.ko
18    1 0xffffffff81de3000     3658 radeon_CAICOS_me_bin.ko
19    1 0xffffffff81de7000     2cd8 radeon_BTC_rlc_bin.ko
20    1 0xffffffff81dea000     7ef8 radeon_CAICOS_mc_bin.ko
21    1 0xffffffff81df2000     8098 radeon_CAICOS_smc_bin.ko
22    1 0xffffffff8248a000    341f0 radeon_SUMO_uvd_bin.ko
Offcourse different hardware can have different results.
 
… it's beginning to look like you must have xf86-video-ati installed in order to use the radeonkms kernel driver. …

Above, for test purposes (ongoing), the radeonkms kernel module (from graphics/drm-current-kmod) without the x11-drivers/xf86-video-ati driver.

donallen with things now apparently stable for you, you might experimentally delete xf86-video-ati, restart the OS then – for a few days – refrain from any use of pkg, freebsd-update, bectl or beadm (i.e. avoid changing your boot environment). Refraining will be easier said than done :)
 
Please note i don't have any xf86-... package installed.
And my radeon card works 100% fine under Wayland.
kldstat | grep -i radeon
Code:
15    1 0xffffffff8233b000   14ec70 radeonkms.ko
17    1 0xffffffff81ddf000     3258 radeon_CAICOS_pfp_bin.ko
18    1 0xffffffff81de3000     3658 radeon_CAICOS_me_bin.ko
19    1 0xffffffff81de7000     2cd8 radeon_BTC_rlc_bin.ko
20    1 0xffffffff81dea000     7ef8 radeon_CAICOS_mc_bin.ko
21    1 0xffffffff81df2000     8098 radeon_CAICOS_smc_bin.ko
22    1 0xffffffff8248a000    341f0 radeon_SUMO_uvd_bin.ko
Offcourse different hardware can have different results.
Exactly.
 
Yes, or he can use vesa() as a temporary fallback to have a minimal desktop at least.
I'm no expert on all this, but I remember some time back, on another thread, you might have mentioned some other kind of mode-setting driver, which I, perhaps incorrectly, speculated was also a video driver, as opposed to a kernel mode-setting driver.

I have only a pieced-together understanding of how all this works, gleaned mostly from reading related threads on this forum, and their associated links, so please don't hesitate to correct me, when and if I'm wrong in my partially-informed speculations.

Would I be correct in assuming that xf86-video-ati, xf86-video-amdgpu, xf86-video-intel, and vesa are all "video drivers" which sort of act as intermediary, or "go-between" drivers, between X and the kernel mode-setting drivers provided by drm-kmod? Namely, the radeonkms.ko, amdgpu.ko, and i915kms.ko drivers, which are packaged with drm-kmod? And would I be correct in also guessing that these three kernel mode-setting drivers are not "stand-alone" drivers, but rather, that they require some sort of video driver in order to function correctly?

Further I've speculated, from reading through my "Xorg.0.log" logs, that X, when starting up on the first time after the boot-up sequence, detects the video devices available, then looks for the correct video driver, or collection of video drivers, which correspond to the video hardware. Then, the video driver interfaces with the appropriate k.m.s. driver, if it's already loaded, or, alternatively, loads the appropriate k.m.s. driver if it's not already loaded.

What seems to be happening on my system is this: if the k.m.s. driver is specified by kld_list, it loads too early in the boot-up sequence, and it loads at a time when the video hardware is rapidly displaying unrelated message strings, which are being output by unrelated boot-up processes. This rapid sequence of unrelated events, in turn, "confuses" the k.m.s. driver, and/or the video hardware, and/or the graphics hardware. Some step or steps in the initialization process then fail, and this leads to the thrashing condition I've tried to describe in my previous posts.

However, if I leave the k.m.s. drivers unloaded until X starts up, there will be no boot-up messages being displayed during the time that the k.m.s. driver is being loaded, so the loading process is able to proceed unhindered, and so it succeeds in being correctly loaded.
 
I'm no expert on all this, but I remember some time back, on another thread, you might have mentioned some other kind of mode-setting driver, which I, perhaps incorrectly, speculated was also a video driver, as opposed to a kernel mode-setting driver.

I have only a pieced-together understanding of how all this works, gleaned mostly from reading related threads on this forum, and their associated links, so please don't hesitate to correct me, when and if I'm wrong in my partially-informed speculations.

Would I be correct in assuming that xf86-video-ati, xf86-video-amdgpu, xf86-video-intel, and vesa are all "video drivers" which sort of act as intermediary, or "go-between" drivers, between X and the kernel mode-setting drivers provided by drm-kmod? Namely, the radeonkms.ko, amdgpu.ko, and i915kms.ko drivers, which are packaged with drm-kmod? And would I be correct in also guessing that these three kernel mode-setting drivers are not "stand-alone" drivers, but rather, that they require some sort of video driver in order to function correctly?
I would say that basically DRM is modesetting. In my boot messages:
Code:
Sep 20 16:30:53 Tuna2 kernel: [drm] amdgpu kernel modesetting enabled.
Sep 20 16:30:53 Tuna2 kernel: drmn0: <drmn> on vgapci0
Sep 20 16:30:53 Tuna2 kernel: VT: Replacing driver "efifb" with new "dummy".
Sep 20 16:30:53 Tuna2 kernel: vgapci0: child drmn0 requested pci_enable_io
Sep 20 16:30:53 Tuna2 syslogd: last message repeated 1 times
Sep 20 16:30:53 Tuna2 kernel: sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
Sep 20 16:30:53 Tuna2 kernel: [drm] initializing kernel modesetting (POLARIS10 0x1002:0x67DF 0x1043:0x051D 0xEF).

With DRM there is no need for Xorg video drivers. DRM can load the correct kernel modules, given an architecture and Xorg automatically recognizes it . Works on Intel, AMD and Radeon chips. The driver can also be used, but is not mandatory. Using driver may speed up a little, but for example in my case with AMD RX-570 using driver vs modesetting gives perhaps 1...2% of better performance. That is in the range of measurement error. So, no visible difference. I am talking only about AMD RX-500 series chips.
 
Would I be correct in assuming that …

My limited understanding is that graphics/drm-kmod is intended to cover as many use cases as possible (excluding, for example, NVIDIA-only cases).

It's worth quoting from the current description <https://www.freshports.org/graphics/drm-kmod/#description> (with added emphasis):

amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS components on amd64, i915 and radeonkms DRM modules from the former base DRM component on other architectures.

Metaport for different versions of Linux DRM based on the FreeBSD version in use. This port encompasses the recommendations of the FreeBSDDesktop team of DRM versions for FreeBSD versions based on the last update to the LinuxKPI in that code base. In general, the most recent supported stable DRM for a give FreeBSD version will be installed. CURRENT receives the most recent development DRM.

This port does not however hinder the expert user to make other decisions and continue to install DRM ports directly.

The WWW line within the description is probably outdated. Instead: <https://github.com/freebsd/drm-kmod/>

<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253524#c1> ▶ <https://gitter.im/FreeBSDDesktop/Lobby/archives/2021/04/15?at=6078d22e55d78266a6496bd5>:

Rule of thumb, do developers in drm-kmod areas prefer bugs to be raised in GitHub i.e. https://github.com/freebsd/drm-kmod, or in FreeBSD Bugzilla?



My broader understanding of things is somewhat limited by the sparseness of, for example, the package description <https://www.freshports.org/x11-drivers/xf86-video-ati/#description> for x11-drivers/xf86-video-ati:

This package contains the X.Org xf86-video-ati driver.

No mention of xf86-video-ati in the FreeBSD Handbook, which is partly why I tire of people being casually directed to the book as if it might the fount of all wisdom. I mean, read an entire effing chapter about something as technically challenging as X.Org and be left with unanswered questions about drivers and a black screen or whatever.

Cue: some hole declaring that FreeBSD is not for people like me.
 

Vull

You need a xorg driver to be able to display anything with X. Those are called DDX (device dependent x) drivers, nowadays there is the generic modesetting driver included in the x server that works for modern GPUs.

Xorg drivers like xf86-video-amdgpu offers some additional features over modesetting. For example: FreeSync (VRR)

If you don't miss those features or dont have any other problems, you are fine with modesetting.

Only x11: DRM Driver -> xf86-video-amd/intel/ati or modesetting --> Xorg --> X11 Application

OpenGL: DRM Driver -> OpenGL DRI driver like mesa -> Xorg --> Game (as example)

If the first one is not the case then there is nothing accelerated at all.
 
… With DRM there is no need for Xorg video drivers. …

… Xorg drivers like xf86-video-amdgpu offers some additional features over modesetting. …

If you don't miss those features or dont have any other problems, you are fine with modesetting.

Not recent, but recalling a problem:

<https://gitter.im/FreeBSDDesktop/Lobby/archives/2020/09/21?at=5f688e2fb468994d0d41ef44> ◀ Thames [Radeon HD 7550M/7570M/7650M]: drm.ko in lieu of radeonkms, with xf86-video-ati (was: need some advice for video output) (2020-11-29) ◀ kld_list="drm" (was: i915kms kernel module causing freezes on FreeBSD 13.0-RELEASE) (2021-05-08)

– in partial response:

1633883967155.png


(Ignore the amdgpu stuff. Suffice to say, I was clutching at straws.)
 
Well in my 2 use cases, Lenovo laptop G50-45 and HP Stream, pkg install xorg drm-kmod has not been enough and I need another driver. Oddly, both have similar problems with putting kms drivers in kld_list but work okay without it. I've been using xf86-video-ati for Lenovo/Radeon, and xf86-video-intel for HP Stream/i915 but am open to alternatives.
 
Back
Top