Solved How to correctly handle the problem of obsolete drm-kmod versions?

[Snurg]

I was not really aware of this problem until I read that:

Your GPU is 10th Gen Intel graphics and according to the FreeBSD wiki: " FreeBSD 12, using drm-kmod, support is the same as on Linux 4.16". Linux 4.16 has only support till Coffe Lake (8 Gen). Your CPU/GPU is Comet Lake (Gen 10) so you need a drm-kmod based on Linux 5.4 and that module can only be founded in FreeBSD 13.0.

Atm this means that any GPU hardware less than 3 years old cannot be used with the FreeBSD RELEASE version.
Apparently there is no way around using -current-kmod and -devel-kmod, if one uses Intel or AMD GPUs that are not sufficiently dated.

This is a BIG issue for autodetecting and autoconfiguring postinstallers, and desktop usage in general.
It does not help improve the FreeBSD reputation for desktop users. In contrary, personally I guess for every one who we see going to Linux because of these easily-avoidable issue, more than ten will try and quietly abandon FreeBSD because of that.

So I need your advice and recommendations:

• Is there a text describing the correct usage case for each of the many drm-kmod variants available?
• How big is the risk that bad things happen if one builds+installs -current-kmod or -devel-kmod when on the release version (e.g. 12.2) the graphics hardware is not yet supported?
• Does somebody know where I can find the PCI IDs of the Intel devices supported by the particular drm-kmod variants? I'd prefer to have the exact IDs, as the alternative would be to just rough-cut and partition the data from freedesktop.org to associate what drm-kmod is the correct to use,
• In case it is necessary to build a newer drm-kmod, is that generally possible on the official RELEASE version (currently 12.2)?

 

[zirias@]

This just won't work, too much in the kernel changed. Move to 13 (13.0-RC2 atm) for this kind of hardware. There's already graphics/drm-fbsd13-kmod, so no need for -devel/-current.

Oh and, why is this an issue? You can't just plug drm code from Linux 5.4 in Linux 4.16 and expect that to work either. The new release is almost there, probably in 2-3 weeks. And anyone who wants autodetection/autoconfiguration better shouldn't use FreeBSD anyways.

Is there a text describing the correct usage case for each of the many drm-kmod variants available?

It's pretty simple:

drm-fbsd<xy>-kmod is for the respective -RELEASE version, drm-current-kmod for -CURRENT (now 14-CURRENT), drm-kmod is the metapackage that will automatically select the correct one for the FreeBSD version you're running.

drm-devel-kmod is the most bleeding-edge version that will only work on -CURRENT and has to be selected manually.

 

[Snurg]

Well, if 13-RELEASE is out, then you no longer are restricted to maximum Generation 8 hardware, in a time where Generation 12 dominates the market.
Please also consider the embarrasment factor this causes for people using/advocating FreeBSD.
I hope in the future such long lagging behind will not repeat.
Regarding the postinstaller, I will just have it support only 13-RELEASE then to avoid that messy stuff.

For now, the confusion remains, why is it necessary to have six different drm-kmod versions, what are their use, which is the correct one to use for which hardware and OS version combination?
And when using 13-RELEASE soon, if the practice continues that current GPU support is not backported, is there a rule-of-thumb which drm-kmod to use if one uses new hardware?

 

[zirias@]

Please also consider the embarrasment factor this causes for people using/advocating FreeBSD.

Why? FreeBSD is focused on stable (rock-solid!) base releases. The release cycle is long. This is what people want and like. If you absolutely want a FreeBSD desktop install on bleeding-edge hardware, you can always run -CURRENT. Newer drm drivers were available there for quite a while.

My first desktop install on the machine I'm writing from right now was 11-CURRENT, for exactly the reason that 10-RELEASE didn't offer the required graphics drivers at that time.

For now, the confusion remains, why is it necessary to have six different drm-kmod versions, what are their use, which is the correct one to use for which hardware and OS version combination?

There are 5, drm-kmod is just the meta-package, and as explained above, it's all you need.
The others are for every supported FreeBSD release plus for -CURRENT (auto-selected by drm-kmod), AND one "-devel" flavor for going bleeding-edge with -CURRENT.

 

[kpedersen]

For now, the confusion remains, why is it necessary to have six different drm-kmod versions, what are their use, which is the correct one to use for which hardware and OS version combination?

This code is contributed from Linux, so it is only natural that it is a bit of an inelegant mess.
I have also wondered why it is distributed in this way.
Is the only reason it is in ports due to licensing? Can we not treat it like firmware and kind of still provide it with the OS?

 

[zirias@]

This code is contributed from Linux, so it is only natural that it is a bit of an inelegant mess.
Is the only reason it is in ports due to licensing? Can we not treat it like firmware and kind of still provide it with the OS?

drm drivers WERE part of the base kernel and were moved out, probably because it's more flexible to maintain them outside, and they're optional anyways, only needed for (some) desktop installations.

The reason for the many packages is not the Linux origin but the fact that they typically only work with one specific version of the FreeBSD kernel.

 

[Snurg]

Now I am thinking that it will probably be simplest to have the autodetect/autoconfigure code of the postinstaller for 13-RELEASE just check whether the particular Intel hardware is already known, e.g Gen <= 12.

If it is more modern, probably it's best to just install graphics/kmod-devel-drm.
Later on when the lag-behind of -release to -current becomes big, then there could be more checking whether graphics/kmod-current-drm or graphics/kmod-devel-drm is appropriate.

What I still do not understand is this line in the graphics/kmod-drm port descriptions "amdgpu and radeonkms are known to fail with EFI boot."
Do you know a link where this is being explained, so that people without UEFI experience can understand what they have to be prepared for, if they have to UEFI computers?

 

[Snurg]

Guys, thank you for the clarifications!

I consider the main issue solved for now.
Adding a table of currently ~ 230 Intel GPU PCI IDs to find whether a particular Intel GPU is supported with a particular FreeBSD RELEASE is sufficient.

Regarding the question what "are known to fail", I'll try to search further, and if I don't find answers, I'll post a separate question.

 

[Argentum]

What I still do not understand is this line in the graphics/kmod-drm port descriptions "amdgpu and radeonkms are known to fail with EFI boot."
Do you know a link where this is being explained, so that people without UEFI experience can understand what they have to be prepared for, if they have to UEFI computers?

And there is a well documented workaround - just to put hw.syscons.disable=1 into /boot/loader.conf and it works!

Personally, I am using AMD GPU with FreeBSD and EFI boot on 2 separate machines. Not the latest models of course. Works very well.

 

[kpedersen]

drm drivers WERE part of the base kernel and were moved out, probably because it's more flexible to maintain them outside, and they're optional anyways, only needed for (some) desktop installations.

Yep, in the earlier days there was an inteldrm as a kernel module that came with FreeBSD. Whilst at the same time we also had inteldrm and inteldrm-legacy kernel modules in ports. Very little documentation about how they all related. Each one was different and worked with varying success with different generations of intel cards.

As far as I know, they are needed for any types of X11 (other than vesa) or "high res" modesetting console.

The reason for the many packages is not the Linux origin but the fact that they typically only work with one specific version of the FreeBSD kernel.

Exactly. Is this not a perfect reason that they should be provided with each specific release of FreeBSD? I.e the one they match?

I hope more drivers (i.e Wireless) don't get moved into ports. It is feeling a little messy. It is also creating a slight modular monolith because they really can't function on their own or with alternative versions of the kernel so they aren't conceptually candidates to modularize.

 

[Snurg]

And there is a well documented workaround - just to put hw.syscons.disable=1 into /boot/loader.conf and it works!

How well this crucial information can be found, this depends on the individual search skill.
Yours is definitely way better than mine! Thank you for helping out!

... Very little documentation about how they all related. Each one was different and worked with varying success with different generations of intel cards.

This is still the case. Super-confusing if one is a retard, like me.

When I used a search engine to find where hw.syscons.disable=1 was documented, I found it only in the package notes of graphics/drm-devel-kmod.

Regarding what is supported by the "default" respective "standard" drm-kmod, I am still not sure. The graphics/drm-devel-kmod description basically says

The experimental drm-devel-kmod port can be enabled for amdgpu (for AMD GPUs starting with the HD7000 series / Tahiti), radeonkms for older AMD GPUs or i915kms (for Intel APUs starting with HD3000 / Sandy Bridge, possibly even older) through kld_list in /etc/rc.conf.

For amdgpu and radeonkms, there have been reports of issues when using UEFI firmware boot. You might need to disable the console by adding hw.syscons.disable=1 to /boot/loader.conf . Please note that this will disable the console until the graphics driver is loaded.

I really would like to browse the sources of the various drm-*kmod variants to get exact information which one supports what.
Now I wonder where I can find these, as either they are not on the FreeBSD Github repo, or I just didn't find them yet because of my retarded search skills.

 

[kpedersen]

Now I wonder where I can find these, as either they are not on the FreeBSD Github repo, or I just didn't find them yet because of my retarded search skills.

Honestly it is probably because it is a mess. One of the better parts of FreeBSD is that the project and code isn't scattered over the place. Unfortunately they seem to be dropping the ball a little when it comes to certain video drivers. I understand it is difficult trying to manage the chaos that is Linux DRM but hopefully the FreeBSD developers are planning to clean it up a little in the future.

It could well be that OpenBSD's slower but more methodical and boring approach will win out in the end. Luckily with how I use FreeBSD, graphics drivers don't really affect me. I also certainly don't give a damn about always using the very latest and greatest.

 

[zirias@]

Now I wonder where I can find these, as either they are not on the FreeBSD Github repo, or I just didn't find them yet because of my retarded search skills.

The source recently moved, so that everything done by freebsd will be found in the "freebsd" project on github.

You will still find the branches for 11.x (drm-v4.11-fbsd11.2) and 12.x (drm-v4.16-fbsd12.0) on the old repo here: https://github.com/FreeBSDDesktop/kms-drm

The current work is in the new repo here: https://github.com/freebsd/drm-kmod (it is actually linked in the README of the old repo).

 

[Snurg]

Instantly bookmarked! Great thanks, Zirias!

Just found that there might be a good alternative to using possibly unstable versions: just ditch KMS.

 

[Yampress]

I think, for each FreeBSD-Release version a package should be built taking into account the current system sources

 

[ProphetOfDoom]

Just to clarify, FreeBSD didn’t defeat me - it was more of a “tactical retreat”. I love this OS and will be downloading 13!

 

[Snurg]

I think, for each FreeBSD-Release version a package should be built taking into account the current system sources

I agree that this would be good to do for versions that are not EOL.

Is there a text describing the correct usage case for each of the many drm-kmod variants available?

It's pretty simple:

drm-fbsd<xy>-kmod is for the respective -RELEASE version, drm-current-kmod for -CURRENT (now 14-CURRENT), drm-kmod is the metapackage that will automatically select the correct one for the FreeBSD version you're running.

drm-devel-kmod is the most bleeding-edge version that will only work on -CURRENT and has to be selected manually.

Imagine there were an additional package like maybe such...

drm-fbsd<xy>backported-from-current-kmod is for the respective -RELEASE version, backported from -CURRENT, so that new hardware is being supported​

...the lag-behind could be reduced?
3 years are a lot. Many users would appreciate less.

And depending on how long the lag-behind is between -CURRENT and the devel branch, it might be imho worth considering also a package like

drm-fbsd<xy>backported-from-devel-kmod is for the respective -RELEASE version, backported from -CURRENT, so that new hardware is being supported​

Imho there should be ways to use brand-new hardware, even if this means using drivers that are not yet mature and potentially could crash the desktop. This risk is acceptable for many, if not most desktop/laptop users.

 

[zirias@]

Again:

You can't just plug drm code from Linux 5.4 in Linux 4.16 and expect that to work either.

You'll be in the same situation with one of these long-term support Linux dists. Probably, this kind of backporting could be technically possible, but just doubling the work to do. This is time better spent keeping up to date on -CURRENT and fixing all those bugs that surface.

Imho there should be ways to use brand-new hardware, even if this means using drivers that are not yet mature and potentially could crash the desktop.

There is, just run -CURRENT. Most "desktop-oriented dists" of FreeBSD based on -CURRENT so far.