drm-fbsd13-kmod is gone (in favor of drm-510-kmod)

zirias@

zirias@

Developer
Good News Everyone!

drm-fbsd13-kmod died today, because with EoL of 13.0, there's no reason for it any more. graphics/drm-510-kmod is the recommended port for 13.1 now, and it contains newer drivers!

The recommended way to install Linux KMS graphics drivers is still to just install graphics/drm-kmod which will automatically select the correct version for your FreeBSD version and pull in all the firmwares. If you did that previously, a simple package upgrade will take care of the change.

If you installed manually (e.g. to only install the firmwares you actually need) and you're on FreeBSD 13.1, just install graphics/drm-510-kmod package now, this will automatically remove the deleted drm-fbsd13-kmod. For users of 12.x, nothing changes, the correct package is still drm-fbsd12.0-kmod.

This change was done on both main/latest and 2022Q3/quarterly. It might take a few days until the binary packages are available.

although I am already in my pyjamas *grumble*...
 
Cool. Is there an easily accessible list of hardware supported by the drm-510-kmod package? Perhaps not a big deal since drm-XYZ-kmod is for Intel and AMD, but I know the nvidia kmod stuff wound up catching a few people. "nvidia-driver" moved ahead versions and broke because the latest version stopped supporting the version of hardware.

But regardless, thanks for this update.
 
Not that I know of... but the new naming scheme directly hints at the Linux version the code is taken from, so you could try to find the info about Linux 5.10 🙈
mer said:
But regardless, thanks for this update.
Click to expand...
I'm just bringing the message, cause I think people who installed manually might be confused by the removal of drm-fbsd13-kmod. All actual work done by others ;) (well, I just fixed a little nasty dependency bug in drm-kmod).
 
I know that folks were bit by something similar to the nvidia drivers. "nvidia-driver" was "nvidia-driver-470.xxxxxx" for the longest time, but then became nvidia-driver-510.xxxxx so a simple pkg upgrade would roll you from 470 to 510 and the 510 version dropped support for some hardware supported by 470. It was only a "big deal" if you ignored package messages.
Upgrading, Dante's 11 level of "fun"
 
mer, for nvidia, these are the upstream version numbers of the proprietary Nvidia driver. Nvidia always dropped support for older GPUs from time to time, so packagers will typically provide older versions as well (like is done in FreeBSD ports).

The opensource KMS drivers from Linux are different. While I'm pretty sure they're sometimes dropping "ancient" stuff as well, we're talking about much longer periods of time. For example, I'm using radeonkms.ko on some AMD APU with integrated GPU from 2011, and i915kms.ko on an old i386 Asus EeePC 🙈
 
zirias@ said:
Nvidia always dropped support for older GPUs from time to time
Click to expand...
Yep, I know, I understand all that. Was merely pointing out that the package named nvida-driver at one time used 470 code from upstream, and eventually wound up using 510 code from upstream. If a person did pkg install nvidia-driver when it used 470 code, then pkg upgrade nvidia-driver after it had moved to 510 code. If their GPU was not supported by 510 code, then they wound up inadvertantly "upgrading".

I had that actually happen to me but not a big deal because the message from pkg upgrade nvidia-driver clearly stated "Your GPU is not supported by this version, so pkg delete nvidia-driver followed by pkg install nvidia-driver-470".

And yep, I understand the whole linuxkms support thing.
:)
 
Alain De Vos said:
I was hoping now i could use amdgpu instead of radeonkms but it seems the chipset is not yet supported.
Click to expand...
This heavily depends on actual hardware you have... Some older GPU's still require radeonkms.

My hope is that Navi 21 is supported in this update.
 
Graphics stuff is a good example of why I've always tried to get "one or two generations back from latest and greatest" for my BSD systems.
CPUs are generally safe enough, but modern CPUs are not really just CPUs, they are SoC, so integrated graphics may not be supported.
Rule of thumb, I keep video cards on hand.
 
kpedersen said:
I noticed about a month back (on i386 if relevant) that pkg install drm-kmod only pulled in firmware and not the actual drm-fbsd13-kmod. If this fix your doing?
Click to expand...
Hm, probably yes. This bug was weird. The meta-port pulled in the correct drm driver only on amd64. And only if it didn't do that, it pulled in the firmware instead. Not sure how that ever happened, but it should be fixed. Well, I hope so 🙈

Edit, right now, there's another strange issue on i386, drm-510-kmod refuses to build. I got around that somehow, but it seems strange that all these patches should be needed, still waiting for feedback from manu...
 
Zirias, some things are hidden in the mailinglists.
So i like it when some information becomes available in the forum like this.
As it allows to foresee problems, and gives more insight into what happens behind the scenes/curtains.
 
kpedersen, I'm currently testing a patch for graphics/drm-510-kmod on i386. As you're using these drivers on i386, maybe you'd like to test as well?

If this works fine, the non-atomic replacement functions for readq()/writeq() should probably go into base linuxkpi first...

Edit: no need to test that any more, the fix is in base (-CURRENT) now and a workaround in drm-510-kmod for older versions on its way 🥳
 
Harry Stone the only guarantee for no breakage would be to never upgrade anything, and even that would "break" eventually for various reasons (security holes, missing support for newer hardware, etc).

That said, graphics/drm-510-kmod works perfectly fine here on two very different machines using i915kms.ko, so your statement obviously isn't true. That doesn't mean it won't break anything on some hardware, but then please open a PR and give the required info for ppl to reproduce and fix it.

Oh. Wait. Did you write 13.0? Then please don't open a PR. 13.0 is EoL. There's no support any more whatsoever. You had (as always) three months for upgrade to avoid breakage. Now, you can still fix it by just upgrading.
 
Yes 13.0 is EOL but that's no reason to break it. Pkg upgrade on 13.0 installs a package that can't possibly work. Nowhere is it stated that at EOL systems will purposely be disabled. But whatever, reduce system reliability and then blame the user.
 
There's only one package repository per major version. And EoL means EoL (which then, for example, enables finally delivering things that didn't work with the old version). You had a transition phase of 3 months, and still you "forget" updating and then blame the project? Well then...
 
  • Like
Reactions: mer
Harry Stone said:
Yes 13.0 is EOL but that's no reason to break it.
Click to expand...
EOL does indeed not translate to "lets intentionally break it". It translates to "no more support for it". This means that any changes (including in ports) are done without any regards to 13.0 (or any other EOL'd version).
 
  • Like
Reactions: mer
It's the only solution. FreeBSD major versions are supported for 5 years, but you are obliged to follow the minor versions. They keep the same ABI, so they will never break existing software. But some newer software just won't work on the older minor. And of course, security issues won't be fixed. EoL means EoL means no support.
 
  • Like
Reactions: mer
zirias@ said:
It's the only solution. FreeBSD major versions are supported for 5 years, but you are obliged to follow the minor versions. They keep the same ABI, so they will never break existing software. But some newer software just won't work on the older minor. And of course, security issues won't be fixed. EoL means EoL means no support.
Click to expand...
Maybe I'm being pedantic here, but according to https://www.freebsd.org/releases/, 13.0 was released just a little over a year ago (April 13, 2021), so isn't it a little early to call 13.0 EoL?

If we follow the logic of supporting major versions for 5 years, then 13.0 would be EoL in 2026???
 
jbodenmann said:
EOL does indeed not translate to "lets intentionally break it". It translates to "no more support for it". This means that any changes (including in ports) are done without any regards to 13.0 (or any other EOL'd version).
Click to expand...
It means no heroic efforts will be made to make things work!
astyle said:
Maybe I'm being pedantic here, but according to https://www.freebsd.org/releases/, 13.0 was released just a little over a year ago (April 13, 2021), so isn't it a little early to call 13.0 EoL?
Click to expand...
See https://www.freebsd.org/security/#sup -- a minor release is supported 3 months past the next minor release.
 
Maybe I'm pendantic here, but i also use gentoo-linux. It's a rolling release, meaning it's always EOL.
Another point is the timeline of major-releases and the timeline of video-driver-releases. And how they interact.
 
You must log in or register to reply here.
Back
Top