With IvyBridge GPU I am still using the driver (drm2) contained in the kernel sources. I know it is considered obsolete, and it will go away in Rel.13, but I just copied the config from 11.4 to 12.2, and it still works as before.
It's probably the price for running a server OS on a desktop.
HiRes graphics may be considered not an integral part of the system, but a specialized hardware add-on, which needs to be treated specially.[/QUOTE]
Me too. And indeed I am quite happy that it is a server OS - because that way one can perceive the various parts as nicely separate (and tackle them individually, in case of need). If you go the other way and try to create a well integrated desktop experience, then you get a vast heap of all interdependent pieces, which may work right from the beginning - but if they happen to do not, then you don't get a clue on why. Anyway, Apple did this already, Linux tried to do it and found systemd. Whatever it hurts - there's upsides and downsides on either way.
The problem there is that FreeBSD has stable kernel ABI policy for minor releases, which is being repeatedly violated. The next non-.0 release will have exactly the same issue. I'll especially note here that the reason FreeBSD 12 doesn't receive any DRM driver backports is the fear of breaking said stable ABI policy, this is downright embarrassing.
I just googled https://lists.freebsd.org/pipermail/freebsd-current/2015-July/056625.html for you.
It's this or tell everyone they'll have to wait for 13.0 before they can use the Intel/AMD graphics drivers. Neither situation is ideal.
This is addressed right after the next sentence (of the post you are replying to).
I'm not so sure about that. I think it's mostly bias and wishful thinking.
This for one is an execellent point, and also I see the current package build process as problematic. How can you release a new OS version without packages being built for this particular version and expect anything other than a less than optimal outcome? Packages should be built for the most recent release version starting from the very day it is released, with the (compatibility) packages for the older version fading away as soon as it becomes EoL, not the other way around. It's just sad to get bitten by issues like this one, just because you happen to be one of those people who likes to keep their stuff up-to-date, always.
There is only one repository for a major version. As 12.1 is still supported the packages are being built for the lowest, still supported, version. It's not a problem to install 12.1 packages on 12.2 except for a small number of kernel modules. And the only reason it's a problem for those kernel modules is because the ABI changed. If the ABI didn't change there would be no problem at all. But if the ABI wasn't changed then you wouldn't get a working Intel/AMD driver at all until the next major release.
This is a completely bizarre statement. None of those breakages are actually intentional. They are unrelated to DRM work.
Yes, you are correct. Not DRM but device driver. It costed me a new graphics card, display port cable and a wasted week. Yet, I can't but be grateful to the developers and community for the great OS.
I surely can respect that. Still, if the number of incompatible binary packages is limited to only a few kernel modules as you say, creating a separate repository for the new OS version that only contains those few problematic modules built for this particular OS/ABI version with everything non-problematic symlinked to the previous versions would also be an option. This would still be a lot better than having users either wait three months before they can upgrade their systems to the latest release, or somehow manually fiddle around the breakage. Problems like this one reduce the overall usefulness of binary packages to a certain degree. When I decide that a particular system is to use binary updates for the OS and packages, then it will neither have a source tree nor ports tree installed, both of which are rather massive and also will require updating by other means, not necessary otherwise.
#make install clean BATCH=yes/usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-fa1387d/linuxkpi/gplv2/include/linux/i2c.h:236:2: note: previous implicit declaration is here
device_unregister(&client->dev);
^
--- linux_irq.o ---
11 errors generated.
*** [linux_irq.o] Error code 1
make[2]: stopped in /usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-fa1387d/linuxkpi
--- linux_i2c.o ---
11 errors generated.
*** [linux_i2c.o] Error code 1
make[2]: stopped in /usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-fa1387d/linuxkpi
2 errors
make[2]: stopped in /usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-fa1387d/linuxkpi
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
Stop.
make: stopped in /usr/ports/graphics/drm-fbsd12.0-kmod
And your snippet doesn't include any of the ACTUAL build errors. But anyways, check whether you are indeed on 12.2-RELEASE and whether you have anything in /etc/make.conf.
There's nothing THEY could do about it. The problem is that ABI *inside* the kernel changes, so a kernel module built for 12.1 will not work on 12.2. Still there's only one (userspace) ABI for FreeBSD-12 and therefore only one package repository.
I think the fact that people have to go to forums and ask for help from more experienced users is pretty good evidence they are overtaxed. I know the solution was pretty simple, but as always: "It's easy when you know how."
I agree with all you guys. Instead of downplaying the problem (small as it is for those who know how), ignoring it, dismissing users because they use FreeBSD on the desktop, etc., or even asking for new repos and build processes, it's obvious that all that was needed was a line or two in one of the official communication documents.
Really? I think that's the other way around.
With a bomb sign.
